Skip to content

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

Merged
merged 2 commits into from
Oct 4, 2018

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Dec 26, 2017

Visibility attributes should just be set on the underlying artists
(tick.gridline.set_visible, etc.) rather than maintaining yet another
layer 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

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@anntzer anntzer force-pushed the tick-visibility branch 3 times, most recently from 46dfba6 to d13ade3 Compare December 26, 2017 19:53
@efiring
Copy link
Member

efiring commented Dec 27, 2017

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.

@anntzer
Copy link
Contributor Author

anntzer commented Dec 27, 2017

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...).

@tacaswell
Copy link
Member

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?

@anntzer anntzer force-pushed the tick-visibility branch 2 times, most recently from 795de46 to 4102b75 Compare February 18, 2018 04:31
@anntzer anntzer added this to the v3.0 milestone Feb 19, 2018
@dopplershift
Copy link
Contributor

The changes for SkewT seem sensible to me. I hadn't seen ExitStack before. Certainly I'm a bit 👍 on having one way to handle things (i.e. set_visible) across the library.

Would this work today if I stole the draw() implementation?

@anntzer
Copy link
Contributor Author

anntzer commented Mar 28, 2018

Should work, but haven't tried :)
ExitStack is not really necessary (if you want py2 e.g., although a backport is available too), you can do the same with explicitly storing the original visibility state and restoring it in a finally clause. But I like ExitStacks...

@astrofrog
Copy link
Contributor

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.

@anntzer anntzer force-pushed the tick-visibility branch 2 times, most recently from e9d013d to 20cb675 Compare May 3, 2018 21:16
@anntzer
Copy link
Contributor Author

anntzer commented Jul 7, 2018

Not going to insist on marking this as RC, but still bumping the suggestion up.

@tacaswell
Copy link
Member

I am ok with this in principle, needs a rebase and version updates.

@anntzer
Copy link
Contributor Author

anntzer commented Aug 27, 2018

done

@timhoffm
Copy link
Member

There are a number of cases (most notably update_position() and draw()) that were previously only executed conditionally on the visibility.

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?

@anntzer
Copy link
Contributor Author

anntzer commented Aug 27, 2018

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...
Can probably do a proper benchmark at some point, if you feel it's necessary.

@jklymak jklymak self-requested a review September 24, 2018 19:38
Copy link
Member

@jklymak jklymak left a 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:
Copy link
Member

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.

Copy link
Contributor Author

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

@jklymak
Copy link
Member

jklymak commented Oct 4, 2018

CI failures unrelated...

@efiring, you expressed misgivings. Are you placated, or ?? If so, I'll merge...

@efiring
Copy link
Member

efiring commented Oct 4, 2018

OK to merge once it passes the tests.

@jklymak
Copy link
Member

jklymak commented Oct 4, 2018

@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.
@anntzer
Copy link
Contributor Author

anntzer commented Oct 4, 2018

Done (modulo appveyor which is queued, but there's no reason for it to fail :p).

@ImportanceOfBeingErnest
Copy link
Member

The label attribute, which was an alias for label1, has been deprecated.

This will hit every call to seaborn.heatmap, which is a pretty common function inside seaborn.

@jklymak
Copy link
Member

jklymak commented Mar 6, 2019

will it be a problem for seaborn to replace by label1?

@ImportanceOfBeingErnest
Copy link
Member

I mean it used to be a simple alias, self.label = self.label1. So that shouldn't be a problem. I just wanted to make sure we are aware of the implication that once 3.1 is released thousands of seaborn users will get some warning message.

@timhoffm
Copy link
Member

timhoffm commented Mar 7, 2019

Good point. We shouldn't do that.

tacaswell added a commit to tacaswell/seaborn that referenced this pull request Mar 9, 2019
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants