I'm somewhat hesitant to do this. While it looks feasible at first glance, I've some reservations:

• What is the use case? The examples in the stackoverflow link seem a bit far fetched. Are we really solving a problem with this, or are we just improving on how one can abuse the library?
• twinx/twiny is currently limited toAxes. I'd be happy to simply document that limitation. Twinning is likely confusing or even not feasible on non-rectangular coordinate systems - polar plots are such a case. When opening up to other Axes subclasses, we allude that it works ("does the right thing") there, but I have absolutely no clue whether that'd be the case.

Hi@timhoffm , thank you for the comments.

Twinning is powerful for time serieses with different units

Twinning is likely confusing or even not feasible on non-rectangular coordinate systems - polar plots are such a case.

When plotting time series data, it happens that several serieses with different units are to be shown in a single figure, with which users would like to interact. One can use the time labels as the shared x axis to twin two overlapping subplots, each has its own y axis with its own unit. This enables simultaneous interaction on the subplots; paning and zooming in one subplot act in the same way on the shared axes of both subplots.

SubclassingAxes

Are we really solving a problem with this, or are we just improving on how one can abuse the library?

Being able to subclassAxes is both a potential for the user, AND a feature ofmatplotlib.

• The existence ofaxes_class as a public argument inFigure.add_subplot andFigure.add_axes already shows this.
• Inmpl_toolkits.axisartist, we have an example of subclassingAxes.
• In_AxesBase._make_twin_axes, which is only used bytwinx andtwiny, we already have the potential to insert*args and**kwargs. However they were not in use before the current MR.

@cmp0xff could you give an example of a use-case where you need both a subclass and a twinned axes? I appreciate the value of subclasses and I have added functionality to Matplotlib to handle them (#22608). For that PR I had a specific subclass in mind (the Cartopy GeoAxes) as shown in the PR summary. Do you have a specific subclass in mind for this?

Hi@rcomer , thank you for your hints. After some research, I have realised that what I described above has mostly been implemented byparasite_axes in theaxisartist toolkit.

In practise, we have an in-house extension ofmatplotlib.axes.Axes which also implementsresampling, wheretwinx is also needed. However, the function returns anAxes instance, instead of instantiating the extended Axes. Therefore the wholetwinx function needs to be reimplemented, which is almost entirely the same with the originaltwinx, with the single addition that the extended Axes class is returned.

Now that in3.10.0,twinx has been updated, we need to propagate the changes to our reimplementation. What if the originaltwinx could be adapted a bit, so that it could become more flexible and handle subclasses? This was the motivation of the current MR.

Thanks, this sounds like a reasonable application. I'm fundamentally ok with extending/modifying the behavior oftwinx().

Design considerations:

• It may make sense to twin an Axes subclass of another type, e.g. you could twin yourResamplingAxes to a regularAxes. This would require an explicitaxes_class parameter:ax.twinx(axes_class=ResamplingAxes). This should be made explicit and not folded into kwargs. A corollary is that the return type would stayAxes (or the signature must be overloaded).
• If we take anaxes_class parameter, should the default beAxes (current behavior, maximal compatibility) orSelf (possibly slightly more common application)?

Hi@timhoffm ,

It may make sense to twin anAxes subclass of another type, e.g. you could twin yourResamplingAxes to a regularAxes. This would require an explicitaxes_class parameter:ax.twinx(axes_class=ResamplingAxes). This should be made explicit and not folded intokwargs. A corollary is that the return type would stayAxes (or the signature must be overloaded).

c4c3aa7

If we take anaxes_class parameter, should the default beAxes (current behavior, maximal compatibility) orSelf (possibly slightly more common application)?

After some thinking, I would go for keeping the current behaviour, defaulting toNone (rather thanself).

The reason is that some subclasses useprojection orpolar to instantiate themselves; these parameters are incompatible withaxes_class, which should hence stayNone for these subclasses.

Hi, it has been two weeks since the last update. May I ask for a second approval / a critical review? Thanks and happy new year.