Also, how does this intersect with#7528?

mm, i have to check out#7528. I think I need to understand a bit better what_make_twin_axes() is doing...

I don't think this PR conflicts directly with#7528 in terms of functionality, but maybe testing can be consolidated. Seems like there's some confusion on whether theshared axis should be thesameaxis or a copy (whose attributes can be changed independently), both from the API perspective and in terms of the internals.

This looks good to me. I'd just add a bit of documentation on thetwinx andtwiny method to explain this behaviour.

@NelleV thanks, added a note about the autoscale setting to the docstrings.

Thanks! It looks good to me.

OK, I've revised thetwinx andtwiny docstrings to reflect the changes in this PR and clarified the wording to the best of my ability.

However this makes me wonder if the implementation is flawed in that the scales of the twinned axis will diverge if autoscale is turned on, since plotting is done on either the originalor the newAxes. Would it make more sense to share the sameAxis object?

This is making my head hurt. I'm wondering, and you likely know better than me at this point, but what I'm getting from you is that one y is hooked into the displayed x and the other is y hooked into the hidden x? if so, I agree that they they should just both be hooked into a single x, but I wonder if that's possible...

Actually, sorry it seems to work fine with the separate xaxis instances - the autoscaling does stay in sync between the "original" and the "twinned" x-axes. So while the implementation is still confusing to me, I think this will work OK.

importnumpyasnpimportmatplotlib.pyplotaspltfig,ax1=plt.subplots()t=np.arange(0.01,10.0,0.01)s1=np.exp(t)ax1.plot(t,s1,'b-')ax1.set_xlabel('original x-axis')ax1.set_ylabel('exp',color='b')ax1.tick_params('y',colors='b')ax1.tick_params('x',colors='b')ax2=ax1.twinx()ax2.set_ylabel('sin',color='r')ax2.tick_params('y',colors='r')ax2.tick_params('x',colors='r')# Manually set the twinned x-axis visible and shift it downax2.xaxis.set_visible(True)ax2.spines['bottom'].set_position(('axes',-0.2))ax2.set_xlabel('twinned x-axis')t2=np.arange(0.01,20.0,0.01)s2=np.sin(2*np.pi*t2)ax2.plot(t2,s2,'r.')plt.show()

Don't apologize! There are loads of moving pieces here and it gets confusing quickly. Ok, then far as I can tell, the goal of#7376 is to treat original and twin x as two semi-independent axis, in that they should have the same min & max but can be labeled individually. And so making a shared x-axis would probably make that functionality impossible.@madphysicist wanna chime in?

Yep, making a shared xAxis instance would seem to preclude the functionality in#7376. Fortunately we don't have to go down that road to resolve the relevant issues here 😄

This should be ready now - if it gets merged@madphysicist will have to sort a merge conflict in the docstring, but nothing functionally impactful, I think.

Looks good to me, just waiting on gitter.im for how to deal with the appveyor failure that has nothing to do with your test.

@naoyak Until fairly recently, I thought that twinning actually meant sharing the axis. Since that is not the case, yourearlier comment makes me question this whole PR:

However this makes me wonder if the implementation is flawed in that the scales of the twinned axis will diverge if autoscale is turned on, since plotting is done on either the original or the new Axes. Would it make more sense to share the same Axis object?

I don't think that sharing the axis object is an option. I think there may need to be a special provision in autoscaling that sets the widest possible bounds for the entire chain of twinned axes. Inheriting autoscaling is definitely a necessary part of this, but autoscaling itself may need to be redefined to special-case axes with twins. I think that fixing that issue that way will also address the concerns about my PR and autoscaling that@efiring brought up.

@madphysicist

I think there may need to be a special provision in autoscaling that sets the widest possible bounds for the entire chain of twinned axes.

I think that's what the current implementation does, actually - I am not sure how this is accomplished under the hood, though. Per discussion above I realized that sharing theAxis object is unnecessary so that is no longer an issue.

At this point this PR only sets the autoscale setting equal for the twinned axis instances and doesn't touch anything else. I think it's safe to merge without messing with your PR, what do you think?

I think that you are safe to merge. I am working on some autoscaling tests right now. I am pretty sure there will be no conflict but it will be interesting to see how our PRs play together.

#6860 wants a backport.