"0% of diff hit (target 50%)" == complete mystery to me

1. the codecov means this code path has no test.
2. I think this error is in there for good reason... ping@efiring

The problem is that this only gives the desired result because you have carefully chosen your limits to be consistent. I think that allowing this in mpl is bad policy; hence the error. Couldn't you achieve your desired result without sharing?

I guess I could get the same output with something like

from matplotlib import pyplot as pltfig = plt.figure()ax1 = fig.add_subplot(111, label="a")ax2 = fig.add_subplot(111, label="b")ax1.imshow([[0,1],[1,0]], extent=(0,5,10,20))ax2.tick_params(left=False, bottom=False, top=True,                 labeltop=True, labelbottom=False,                labelleft=False)ax2.set_aspect("equal", adjustable="box")ax2.patch.set_visible(False)ax2.axis([36,41,10,20])  plt.show()

But isn't that restriction a bit artificial?
I mean, if you do not set the limits correctly, you will still get a valid plot, but it may look bad in the sense of overlapping axes. So you always get what you ask for; and the warning tells you that this may not necessarily coincide with what you were hoping to get at.
Or is there anything that breaks down and would justify the error?

I don't think it is artificial; it is preventing an inconsistency. Twinning requires the boxes to be identical, and it locks together the ylim of the two Axes (in the twiny case). Setting the aspect ratio on both means that at draw time, for each Axes in sequence, either its data limits or its box is adjusted. Since the xlims are independent, in your example, this means there is a fundamental conflict between the need to adjust the boxes and the requirement that they be identical. I don't think our API should allow this,eventhough you canset the xlims so that the boxes would in fact be the same.

there is a fundamental conflict between the need to adjust the boxes and the requirement that they be identical.

That's probably the main point: Where exactly does this requirement come from?
More precisely, I would say the requirement for a twiny axes is that the boxes are identical inheight, for a twinx axes that they are idential inwidth. As far as I can see this is still preserved in the code base.

Well, I suppose you could superimpose boxes with the same height but different widths, but chances are it would look pretty bad unless you remove the frames. I think it goes against the essence of twinx and twiny, for which a reasonable expectation is that the Axes position boxes coincide..

It seems the fundamental desire is to usetwiny is to provide a second x-spine for the original axes that will have different locators and formatters (an alternate scale), rather than create a second axes that will be plotted on. Is there any other way to achieve that right now?

I agree that this is desirable, and at present it not easy in any obvious way that I know of. Everything is so tightly tied to the Axes object, and the Axes object has only a single Locator and Formatter per Axis. Given that, the solution is probably to make a second Axes with everything turned off except for the desired spine, and use callbacks to lock the position and the desired spine limits to those from the master Axes in which the actual plotting is done. The callback for the limits could then transform those numbers (and the entire scale) from centigrade to fahrenheit, for example, or from frequency to period (which would be my use case), and the second Axes Locator and Formatter for the spine would be able to make appropriate ticks and labels.
We have callbacks for set_xlim and set_ylim; we lack a callback for set_position.

maybe this is off-topic and I've misunderstood the root use-case, in which case we can take this elsewhere. Note I'm pretty sure that is the use case in#10960. But...

Could we just have a list ofsecondary_xaxis andsecondary_yaxis objects that are just subclasses of xaxis objects but also have the "unit" conversion, have an offset of some sort, and are slave to their parentx/yaxis? These could simply be updated every time the parent axes is updated, but would have a known parent (the backwards compatibleAxes.xaxis)? I say a list, because if we allow one extra spine, why not more.

That might work. It looks like the only use of Axes.transData in the Axis is for an optional tweak, so the subclass could disable it.

The normal Axis gets its view_interval from its Axes.dataLim. You would change methods in the subclass so that some transformation function would be applied to Axes.dataLim in setting the slave view_interval?
I think this approach might involve more code than my suggestion of adding a callback for set_position, and providing a helper that makes the mostly-blank slave Axes.
I'm not sure which is better, or whether there is another approach entirely that should be pursued.

Of course any general solution to producing secondary axes for images is preferrable compared to this attempted workaround.

A meta thing: What you are discussing now goes a bit beyond of the purpose of this PR. If I understand correctly my desired change is rejected. So would it make sense to close this PR and continue general discussion about secondary axes elsewhere, in an issue where it can later be found and used by people implementing those features?

Ooops, approval should be modulo a test checking that the warning is emitted...

@WeatherGod, try this, if it is analogous to your use case:

fig,ax=plt.subplots(ncols=2,sharex=True,sharey=True)ax[0].imshow(np.random.randn(15,12))ax[1].imshow(np.random.randn(15,12))

There is no more box-forced; box works in this case.

It was in#10033.

What's the status here? Should this be closed? Should it be left as a place for discussion?

I still recommend that it be closed.

OK, closing this and counting on some other approach to allow for equal aspect doubly sided axes soon.

#11026 is heading that way, though I am planning to stop where I am with that and will add the second slave axes as a different PR once#11026 is in (if its deemed acceptable). Its a little bit orthogonal, with the only relevant addition being the ability to add an axes child...