-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Lim parameter naming #11293
Lim parameter naming #11293
Conversation
Did anyone ever think this deprecation through? What is |
The deprecation was briefly discussed in #11137 (comment) and the following two comments. |
Its unreleased - we can always back it out if there is a strong reason to not deprecate these names. |
Some deprecation is reasonable. There shouldn't be two keywords with the same functionality. The question is what the good names are. Currently we support the following kwarg names.
There's been a slight preference to keep the directional names in the discussion in #11137 (review). However, it was not discussed to a broad extent and there were only three opinions given. |
On polar axes there's always rmin/rmax; thetamin/thetamax which didn't go away. I think I'm -0 on restoring xmin/xmax for simplicity and for reasons given in the thread at #11137 (comment) (@timhoffm you said yourself that two ways of doing it was a bit silly :-)), but don't feel very strongly about it either, so let's collect some opinions... |
I'm against two kwargs meaning the same thing. Just to be contrarian, I'd have used |
To state my position clearly (and add to the diversity):
|
If I have to chose, I'd choose |
Due to the arguments handled in a more or less positional way, i.e. the left argument denoting the left boundary, I do think that
This means that However what bites me here is with polar plots where there is no left or right. I at least happen to always use Doing this from scratch I would probably favour something like In any case whatever is decided I think it should go through a deprecation period of at least a year or so, to make sure people have time to adapt their codes. |
As a side note, |
FWIW, I kind of like @jklymak's suggestion about the keywords |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is moving in the right direction; additional discussion with @tacaswell is recommended.
Marking as "Release Critical". We must not internally use deprecated APIs. Otherwise the users will see the deprecation warnings we're generating with that. Either this PR has to go in for 3.0 or the deprecation of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thank you.
Hi, It's only pretty recently that I discovered the deprecation of xmin, xmax arguments since I'm working with stable releases of Matlplotlib and I only " So I got rather frustrated by the deprecation, and thus I dig in the PRs. What I read didn't convinced me:
So my conclusion is that the "consequence analysis" (sorry, I don't have the proper word for this) for this deprecation was a bit short and I'm not sure the aesthetical reason (the duplicate keywords which I agree is odd) is worth breaking piles of existing codes (assuming I'm not the only weird addict user of xmin, xmax, ymin, ymax ;-) ). Am I indeed lonely? |
Yeah, I personally think it was a mistake. Can we carry on the conversation in the open issue #11761 though? |
PR Summary
In #11137 the kwargs
*xlim
ofset_*lim
were deprecated. This PR removes their occurrences from the code base and examples.I'm not quite happy with the deprecation, because
xmin, xmax, ymin, ymax
feel more straight forward and are easier to remember thanleft, right, bottom, top
. Anyhow, if we want to go that way, the code itself should be consistent.