@efiring. I made the parameter have to be explicitly specified by the user. The default is to share the ticker. Initially, even if the container is not shared, the actual Locator and Formatter are. It is then up to the savy user to mess things up for themselves.

Given the way I structured it, the user has to first manually disable theshare_tickers option when twinning, then explicitly change one of the locators. I think that adding a warning in the docs about being careful with auto scaling should be enough since the default behavior is unchanged. Keep in mind that even withshare_tickers disabled, the twinned axis will share a reference to the original locator until the user explicitly changes it. I just added a way to make such a change possible as a non default behavior.

@efiring Hopefully the explicit warnings I added in the documentation will be sufficient. Perhaps I should add an actual warning to the low-level functions that set up auto-scaling that will be triggered ifself._share* is non-None andself._share_tickers isFalse?

Current coverage is 61.90% (diff: 100%)

Merging#7528 intomaster will decrease coverage by4.52%

@@             master      #7528   diff @@==========================================  Files           109        173     +64     Lines         46780      56171   +9391     Methods           0          0             Messages          0          0             Branches          0          0           ==========================================+ Hits          31075      34771   +3696- Misses        15705      21400   +5695  Partials          0          0

Powered byCodecov. Last updatedfd38f7...eb18ba8

I think you push some commits for#7482 on here accidentally.

@QuLogic. It was not entirely an accident. I wanted to make the documentation change in the example once (if) both branches get merged. That last commit should be in whichever branch gets merged last. My mistake was pushing it here early.

Sorry, pushing all kinds of buttons unintentionally in mobile version.

@QuLogic. I undid the push. Once either PR gets accepted, I will add the example modifications to the other one. Thanks for the catch.

While I realize that I need to add more tests for things like subplots using the new keyword, is the failure in coveralls something I should be worried about in general?

@madphysicist do you have a screenshot of what this would look like (i.e. a shared axis with 2 distinct ticker formats)? I'm working on#7904 and wanted to be sure things would be consistent in terms of approach.

@naoyak. Thanks for reaching out. I am glad to see you working on the auto-scaling, which I know next to nothing about. There is a screenshot of the expected behavior ina comment I made in the issue that started this PR. It also has the code used to generate it. The portion of the discussion following that comment also has some points by@efiring about autoscaling. I am not sure if they are pertinent to your PR though.

Awesome, the screenshot helps. I don't think our PRs will clash in any way but if you are close to finishing this one up, I might just wait and rebase on top.

I agree that there will likely be no clash. I was wondering if you have any thoughts aboutthis comment. If the twinned axes have different locators and autoscaling is turned on, is there really a possibility for conflict between the locators? If so, how would you recommend resolving it?

What do we mean here when we talk about a conflict in autoscaling? Do you mean that one of the twinnedAxes would have autoscaling turned on, and the other has it turned off? In any case, new data would only apply to one of theAxes, I think.

@naoyak Going off the comment I linked to in my previous post, there may be the possibility that the locator is used to determine bounds when autoscaling is turned on. Since my PR will allow different locators on each of the twinned axes, which one will determine the final bounds that are set (assuming that both have autoscaling on simultaneously, as they should)? I am not 100% convinced that there is a possibility for conflict at all, but I have not traced through the code enough or done any experiments to confirm one way or the other. I thought you might have more insight into the possibilities.

@tacaswell I switchedTicker to useupdate_from and I think it makes the code look better overall. Also saves on an allocation whenself._share_tickers isFalse.

Looks like everything is working. However, I would like to add a couple of tests with subplots and autoscaling before this gets merged.

Closing in favour of discussion on#10976, and as a duplicate of#10960.