Resizing works as far as I can tell.

Allowing drawing on the secondary axes is mostly just a nice side effect; I'm not suggesting to add a public API there (it would need its own discussion). On the other hand I don't think zorder is that complicated (basically, the children of the secondary axes all get inserted into the main list at the position specified by the secondary axes zorder) -- but again we can discuss this separately.

I would argue that those arrows on top of the spines are closely linked to having the axes through (0,0). Essentially my impression is that there are two kind of graphs around: "Math graphs", that go through zero and have directional symbols on them, and "Engeneers graphs" that look like the default graphs in matplotlib (possibly with or without top and right border). My vote would hence be to keep showcasing zero passing axes with arrows.

It's not really hard to add arrows to "standard" (non-mpltoolkits) matplotlib graphs (it's just a matter to add an annotate() (or arrow()) call in axes coordinates; https://gist.github.com/joferkington/3845684 / https://3diagramsperpage.wordpress.com/2014/05/25/arrowheads-for-axis-in-matplotlib/).
We could certainly think of having a better API for that, but I was hoping to keep that a separate discussion...

The canonical order in such cases is: Provide an alternative, then remove the original, not vice versa.

I think the changes to secondary_xaxis have enough merit by themselves, so the SubplotZero stuff can be cut out?

I'm not removing the old (and currently only) way to do that (I'm no even removing the examples for them!); I'm just discussing that the changes here will later enable further changes.

On the call today we (@anntzer and I) discussed this. One idea is to more thoroughly unify twinned axes with secondary axes so that the user would need to remember less about their (reduced) differences. For example, if secondary axes were not children then the handling of zorder would be identical between twinned axes and secondary axes.

I think you are just suggesting that a secondary axes is just a twinned axes with a special relationship between the parent and the twin. I guess that’s ok but I don’t like the ambiguity. We have lots of ambiguity with twinned axes, shared axes, etc and it all becomes a bit confusing. Currently a secondary axes is just an annotation on the parent axes. You can’t plot on it. That makes it a lot simpler. I’m not sure why we want to move to something more ambiguous just to give the trivial ability to plot in different units. The user already has the forward and inverse functions so it’s not like it’s hard to plot on the parent axes.

@ImportanceOfBeingErnest I guess you handled your own concern re "math-style axes" via the solution at #17170? :-)

I guess my concern is superseeded by my comment in #17170, that is, keep showcasing axisartist functionality, but in the context of that module.

I'm still mildly against this. I think secondary_axis is just an axis, not a full fledged axes you can plot on. Folks should use twin for an axes.

Added this to the weekly call agenda, should hopefully be relatively quick to discuss and reach a decision.

Sure, but can you re-iterate why it should be an axes versus just using twin? I genuinely don't understand...

Because this way you can write something like

fig, ax_celsius = plt.subplots()
ax_farenheit = ax0.secondary_yaxis(
    "top", functions=(celsius_to_farenheit, farenheit_to_celsius))
ax_celsius.plot(celsius_data)
Axes.plot(ax_farenheit, farenheit_data)
plt.show()

and have everything just work?

(Note that I would not argue to add that feature if it had to be implemented from scratch; the point is that all the required machinery basically already there so it seems a pity not to make it available.)

Sure, but isn't that what twinx does? Is it keeping the data limits in sync that you are after?

twinx() doesn't even ensure that the celsius data will be correctly readable on the farenheit axis?

OK, but then should this replace twinx? Should twinx gain this functionality?

My original idea with secondary_axis was for a lightweight annotation artist that didn't confuse people like the existing twin method did; if I could have not had an axes created at all, I'd have done so, but unfortunately an Axis doesn't contain all the artists for some reason.

But if we can make this clean I'm not opposed. We could also come up with another API for the two things.

OK, but then should this replace twinx? Should twinx gain this functionality?

For me, twinx means you're plotting two unrelated datasets, whose only common point is that they share the independent variable (e.g. temperature vs time and pressure vs time). secondary_axis means that you're plotting datasets that are directly comparable, except that they may be expressed in various units (e.g. celsius vs. farenheit).

But if we can make this clean I'm not opposed. We could also come up with another API for the two things.

Agreed I'm not particularly wedded to the API, again my main point was that this is basically already available as is.

OK, I think that makes sense. Does the drawing happen on the parent or the child? If we passed add_artist to self.parent.add_artist, that would maybe take care of a lot of the confusion of having two axes. OTOH it wouldn't allow two sets of grids, which folks have asked for in the past.

Right now it happens on the child, but perhaps forwarding add_artist to the parent may indeed be better.

I think this brings up issues of what the cursor should show, etc, but I think by stating one is the parent, and one is the child, we can just say the cursor follows the parent regardless of which method the artist was added with.

I guess I think this should be a different method. We could even consider soft-deprecating secondary_axis in favour of secondary_axes. Its marked "Experimental" so soft deprecating it is not out of the question. I think if people weren't ever confused about which axes gets the picks, or can have a facecolor etc, then this could work as a nice convenience.

Discussed on call. Agreement was that this would be nice to have, but we need to make sure everything is well lined up. Questions are listed in the summary of the discussion, but among the points I need to look at: 1) does the orthogonal direction get correctly synced? 2) how much implementation can be shared between this and twinx/y? 3) can we pull in parasite_axes functionality, i.e. both axes' artists get z-ordered together, they share the same color cycle? (also legend() works, etc.)

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.

Looks like the agreement from the call 2y ago was to try moving this forward.