API Change: Terminal.move (y, x) => (x, y).

[jquast]

This issue duplicates upstream issue, erikrose#58

Problem

Terminal.location is (x, y) but Terminal.move is (y, x).

This causes issues with composability of positional (y, x) parameters. Also causes programmer mistakes.

Solution

Terminal.move to positional ordering, (y, x) => (x, y).

[jquast]

This issue deferred until grouped by other SEMVER major API breaking changes. Documentation already brings a rather severe note about the use of explicit keyword arguments.

[iderik]

If you're planning to do this major API breaking changes, why not change Terminal.move to (x, y) instead? Isnt the (x, y) order more of a standard then (y, x)?

In source codes I've seen with Curses, people almost always define X first and Y second, but then reverse the order when passing them as parameters because of Curses. What I mean is that people "think" (x, y) and not (y, x). The first time I noticed that in Curses, I immediately went looking for an alternative.
It might confuse the user about order of width and height too.

Here's a quote from Python 3 documentation of Curses: "This breaks the normal convention for handling coordinates where the x coordinate comes first. This is an unfortunate difference from most other computer applications, but it’s been part of curses since it was first written, and it’s too late to change things now."

Pleaseee, dont follow the same road like they did!

[jquast]

I grew up on (x, y) for all my graphics programming too, I generally agree! This oddity is why this bug happened in the first place, I'm sure :)

Just defaulting to match upstream api order, rather than our own. Will consider, thanks!!

[jquast]

i would agree to go (x, y) in any 2.0 release btw

[jquast]

Added term.move_yx and term.move_xy for next release, and we recommend only term.move_xy in the documentation and examples going forward. move still exists for compatibility, sorry, just wasn't enough to break major api!