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?

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?

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

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.

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.

done

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?

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.

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

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

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.

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

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.

Good point. We shouldn't do that.