Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terminal.location is (x, y) but Terminal.move is (y, x). Woops ... #58

Open
jquast opened this issue Mar 20, 2014 · 6 comments
Open

Terminal.location is (x, y) but Terminal.move is (y, x). Woops ... #58

jquast opened this issue Mar 20, 2014 · 6 comments
Labels

Comments

@jquast
Copy link
Collaborator

jquast commented Mar 20, 2014

Probably want to add this to your readme.

*NOTE*: The ``location`` method receives arguments in form of *(x, y)*, where the ``move`` argument receives arguments in form of *(y, x)*.
@fwenzel
Copy link
Collaborator

fwenzel commented Apr 29, 2014

Hi! I'm Fred, and I'm helping Erik a bit with maintaining Blessings.

Good suggestion. Question: docs for this are good, but shouldn't we fix the API instead? That's a breaking change, I understand (thus probably reserved for a major version bump) but unless there's a reason for this discrepancy, we should fix the API.

@TheSilvus
Copy link

Even if it is not possible to fix this as of now, the note in the docs should be more explicit, maybe bold? This would make it more noticeable (and prevent more issues about this topic, I was just about to open one).

A (rather inelegant) solution for the problem would be to have another method that uses the move capability, but switches the arguments:

def set_location(self, x, y):
    self.move(y, x)

and add this to the documentation instead of move.

@erikrose
Copy link
Owner

erikrose commented Jul 9, 2018

Works for me. How about a position(self, y, x) that does the same as location(...) but has the args reversed? Then all move-ish things will be y, x. "position" is currently supported as a sugared equivalent to the cup capability, but I see I have that marked as deprecated, so we can kill it in a tenths-place release. (It's not very useful anyway.) Care to open a PR doing both of these?

In the meantime, you can certainly put the args to location in the right order; you just have to use explicit kwargs: location(y=6, x=8).

@erikrose
Copy link
Owner

erikrose commented Jul 9, 2018

Btw, I neglected to mention that we'd deprecate location() as well.

@erikrose
Copy link
Owner

I'd like to keep this open in case I return my attention to blessings at some point.

@erikrose erikrose reopened this Feb 20, 2019
@jquast
Copy link
Collaborator Author

jquast commented Feb 2, 2020

in blessed, we implemented term.move_yx, term.move_xy, term.move_x, and term.move_y as callables with parameters, and never recommend the built-in and ambiguous move. https://blessed.readthedocs.io/en/latest/location.html#location

blessed is API compatible with blessings. My favorite gem is from curses documentation of python 3,

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants