-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Deprecate Tick.{gridOn,tick1On,label1On,...} in favor of set_visible. #10088
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
Conversation
46dfba6
to
d13ade3
Compare
I have mixed feelings about this, so far. The 'tick1On' etc. attributes are ugly but fairly deeply embedded. Is this the time to make such an invasive change? Or would it be just as well to defer it for a more thorough overhaul of the overly complex and sluggish Tick/Axis/Spine system? Maybe we will never get to that, though. |
I don't think the system is that deeply embedded (but it has been around for a while, for sure). The deprecation is basically just replacing the attributes by calls to set_visible throughout; the only complication is with code that proxies these attributes using properties (i.e., the skew axes example), but this kind of code is always going to interact in a tricky manner with deprecations (because we arguably can't cover all possible ways in which our attributes have been proxied...). |
I do not disagree it simplifies things, but I am not sure it is worth the disruption in this case. attn @astrofrog Does this cause issues for WCSAxes? |
795de46
to
4102b75
Compare
4102b75
to
f0fb604
Compare
f0fb604
to
bee5871
Compare
The changes for Would this work today if I stole the |
Should work, but haven't tried :) |
I don't think this will cause issues for WCSAxes, though it will require some updates in APLpy (https://github.com/aplpy/aplpy/blob/eb09ec39506db2da91f92a383016d1328df731c3/aplpy/colorbar.py#L133) but I can live with that. |
e9d013d
to
20cb675
Compare
Not going to insist on marking this as RC, but still bumping the suggestion up. |
I am ok with this in principle, needs a rebase and version updates. |
c60605e
to
c31cc44
Compare
done |
There are a number of cases (most notably I agree that updating always is the more correct thing to do (otherwise the value is not correct when enabling visibility later on.). On the other hand, I'm a bit concerned of the performance impact. Have you evaluated this? |
I haven't, but I also think that it is the correct thing to do. Obviously it would be possible to hide them back again under a check for get_visible() but the semantics would be so-slightly different (if someone was really relying on that) and I don't think it's a good feature to keep anyways... |
c31cc44
to
ed0a056
Compare
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.
Seems fine, except for the ExitStack context stuff, which I don't follow, and hence is maybe a bit obtuse for a user example.
Does this have a slight behaviour change. Before if we set things while the label was not on it didn't have an affect. Now the label is not visible, but you do change the properties. So if the user turns the labels on again, they will get different results I think with this PR than before. OTOH I think the results they will get w/ this PR are more correct, so I'm OK w/ the change.
def label2On(self, value): | ||
self._label2On = value | ||
def draw(self, renderer): | ||
with ExitStack() as stack: |
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.
This is kind of mysterious for an example w/o a comment why you need it.
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.
added an explanation, I hope it helps
f14da5b
to
cefae87
Compare
CI failures unrelated... @efiring, you expressed misgivings. Are you placated, or ?? If so, I'll merge... |
OK to merge once it passes the tests. |
@anntzer after a rebase feel free to merge once it passes tests.... |
Visibility attributes should just be set on the underlying artists (`tick.gridline.set_visible`, etc.) rather than maintaining yet another layer of control.
cefae87
to
c61d71d
Compare
Done (modulo appveyor which is queued, but there's no reason for it to fail :p). |
This will hit every call to |
will it be a problem for seaborn to replace by |
I mean it used to be a simple alias, |
Good point. We shouldn't do that. |
The Tick.label property will be deprecated and begin warning in a future version of Matplotlib. Explicitly using the correct property will avoid this. See matplotlib/matplotlib#10088 and matplotlib/matplotlib#13631
Visibility attributes should just be set on the underlying artists
(
tick.gridline.set_visible
, etc.) rather than maintaining yet anotherlayer of control.
Note that this technically breaks code that overrode the
gridOn
etc. attributes using properties (such as the old implementation of skewed axes) but I can't think of a reasonable way to emit a warning for these...PR Summary
PR Checklist