Besides, I do not use that much the mpl_toolkits but is it normal that mpl_toolkits.axisartist uses “inward” tick marks? (I mean, while mpl defaults are now to use “outwards” tick marks)
It works correctly on v2.x...
Tick direction: good point. If you are looking for a challenge, see if you can figure out what is determining the tick direction and other properties...
@efiring What version of mpl 2.x did you test? On my computer, with mpl 2.0.0b3.post1859+g80a3f3e (retrieved a few hours ago from GitHub), I get the same picture as in the devdocs gallery, with the second y-axis missing.
I will try to have a look at it, as well as at the tick direction and Cie.
This is broken on master, but not v2.x. Bisect points to d268abf:
d268abf8fd9c41fdc37b9bfeb8b1d576b4b288d3 is the first bad commit
commit d268abf8fd9c41fdc37b9bfeb8b1d576b4b288d3
Author: productivememberofsociety666 <productivememberofsociety666@sol.fr.am>
Date: Fri Aug 14 19:54:02 2015 +0200
Changed twin* functions so the corresponding host axes are invisible; updated _remove_method.
:040000 040000 27e94ea209af1f49c24fe81628ad97d51f772a11 c1bbecea359621967069ba84b1e81a1ee6ffd2a5 M lib
@QuLogic Thank you for figuring out the bisecting point!
I think I may have found the reason why the 2nd y-axis is not visible after d268abf. For example in twinx from axes_grid1.parasite_axes.py, one has (the comments are my own understanding of the code):
before:
# 1/ Deactivate the right side of the parent axis, but its line.self.axis["right"].toggle(all=False)
self.axis["right"].line.set_visible(True)
# 2/ Hide all the sides of the parasite axe but the right side.ax2.axis["right"].set_visible(True)
ax2.axis["left","top", "bottom"].toggle(all=False)
ax2.axis["left","top", "bottom"].line.set_visible(False)
# 3/ Setup the right side of the parasite ax.ax2.axis["right"].toggle(all=True) # Do not forget to activate tick & labels!ax2.axis["right"].line.set_visible(False) # the one from parent ax is visible
after:
# 1/ Simply make the right side of the parent ax not visible.self.axis["right"].set_visible(False)
# 2/ Make all sides of the parasite ax not visible but the right one.ax2.axis["right"].set_visible(True)
ax2.axis["left", "top", "bottom"].set_visible(False)
# 3/ Setup the right side of the parasite ax.# Empty!
and if I add ax2.axis["right"].toggle(all=True) in the 3/, then the demo seems to be OK.
I did not have time to look carefully to the related PR (#4898) yet: I cannot tell for the moment that this is not going against the aim of #4898. I will have a better look at this tomorrow or this weekend.
@afvincent Everything that #4898 was meant to achieve has been put into the mpl_toolkits.tests.test_axes_grid1.test_twin_axes_empty_and_removed test and is illustrated by the difference between the pictures in this comment. Your proposed change doesn't seem to make the test fail, so it should be fine.
Although I don't really get why it doesn't work the way it is. I think it has something to do with the AA.Axes class (which I didn't really consider when writing #4898 - a bad idea given that it's the main selling point of the axes_grid toolkit, sorry about that 😟): if I remove everything that has anything to do with that class, I at least get both twin axes visible, although of course it looks like garbage because I can't have the offset without AA.Axes.
@smheidrich Thank you for the explanations as well as for the experiments :)!
I have played a bit with the test you added in #4898 (doing more or less the same kind of things as you did in gist) and it seemed to me too that the problem has to do with AA.Axes. I will try to investigate this in the next few days, to see if there is a deeper ground to the issue, that could also explain the minor issue with tick directions & Cie.
All right, so to me it seems this comes down to the difference between axis artists that are used by the default axes vs mpl_toolkits.axisartist.Axes, specifically what exactly their set_visible methods do:
set_visible isn't explicitly implemented but inherited from the basic matplotlib.artist.Artist.set_visible method, which of course doesn't know about toggling or anything else, so the child elements that were toggled off stay off.
So that explains why my code worked for default axes without the explicit toggle call, but not for the axisartist axes.
I tested this by making axisartist.AxisArtist.set_visible behave like axes_grid1.mpl_axes.SimpleAxisArtist.set_visible and then demo_parasite_axes2.py works again, although knowing my luck this probably breaks something else. :P
Also I think the better solution might be to do the exact opposite and make axes_grid1.mpl_axes.SimpleAxisArtist.set_visible behave like axisartist.AxisArist.set_visible? Or maybe leave both methods as they are? In either case you would then have to add the toggle code to twin* like @afvincent originally suggested.
But in general one problem with the axes grid toolkit it's that it's so damn inconsistent, so perhaps having at least set_visible behave the same might be nice.
@tacaswell It might be better to make it consistent the other way round, i.e. by making set_visible not toggle any children ever. I guess the way to think about it is that toggle changes the properties of the axisartist. Then set_visible just determines whether the axisartist as a whole is shown, whatever its properties (with/without ticks or ticklabels) might be. In more practical terms, I think it's plausible that some people do use axisartists with e.g. their ticklables turned off as a conscious choice, and they don't expect set_visible to override this choice. I'm not sure though.
Activity
afvincent commented on Jul 26, 2016
Besides, I do not use that much the mpl_toolkits but is it normal that mpl_toolkits.axisartist uses “inward” tick marks? (I mean, while mpl defaults are now to use “outwards” tick marks)
efiring commented on Jul 26, 2016
It works correctly on v2.x...
Tick direction: good point. If you are looking for a challenge, see if you can figure out what is determining the tick direction and other properties...
afvincent commented on Jul 26, 2016
@efiring What version of mpl 2.x did you test? On my computer, with mpl 2.0.0b3.post1859+g80a3f3e (retrieved a few hours ago from GitHub), I get the same picture as in the devdocs gallery, with the second y-axis missing.
I will try to have a look at it, as well as at the tick direction and Cie.
efiring commented on Jul 26, 2016
In [5]: matplotlib.version
'2.0.0b3+23.g18ffa3e'
QuLogic commented on Jul 27, 2016
This is broken on master, but not v2.x. Bisect points to d268abf:
d268abf8fd9c41fdc37b9bfeb8b1d576b4b288d3 is the first bad commit commit d268abf8fd9c41fdc37b9bfeb8b1d576b4b288d3 Author: productivememberofsociety666 <productivememberofsociety666@sol.fr.am> Date: Fri Aug 14 19:54:02 2015 +0200 Changed twin* functions so the corresponding host axes are invisible; updated _remove_method. :040000 040000 27e94ea209af1f49c24fe81628ad97d51f772a11 c1bbecea359621967069ba84b1e81a1ee6ffd2a5 M libafvincent commented on Jul 27, 2016
@QuLogic Thank you for figuring out the bisecting point!
I think I may have found the reason why the 2nd y-axis is not visible after d268abf. For example in twinx from axes_grid1.parasite_axes.py, one has (the comments are my own understanding of the code):
and if I add ax2.axis["right"].toggle(all=True) in the 3/, then the demo seems to be OK.
I did not have time to look carefully to the related PR (#4898) yet: I cannot tell for the moment that this is not going against the aim of #4898. I will have a better look at this tomorrow or this weekend.
smheidrich commented on Jul 31, 2016
@afvincent Everything that #4898 was meant to achieve has been put into the mpl_toolkits.tests.test_axes_grid1.test_twin_axes_empty_and_removed test and is illustrated by the difference between the pictures in this comment. Your proposed change doesn't seem to make the test fail, so it should be fine.
Although I don't really get why it doesn't work the way it is. I think it has something to do with the AA.Axes class (which I didn't really consider when writing #4898 - a bad idea given that it's the main selling point of the axes_grid toolkit, sorry about that 😟): if I remove everything that has anything to do with that class, I at least get both twin axes visible, although of course it looks like garbage because I can't have the offset without AA.Axes.
Anyway, I think your suggestion should fix it.
afvincent commented on Jul 31, 2016
@smheidrich Thank you for the explanations as well as for the experiments :)!
I have played a bit with the test you added in #4898 (doing more or less the same kind of things as you did in gist) and it seemed to me too that the problem has to do with AA.Axes. I will try to investigate this in the next few days, to see if there is a deeper ground to the issue, that could also explain the minor issue with tick directions & Cie.
Potential fix for matplotlib#6836.
smheidrich commented on Aug 1, 2016
All right, so to me it seems this comes down to the difference between axis artists that are used by the default axes vs mpl_toolkits.axisartist.Axes, specifically what exactly their set_visible methods do:
So that explains why my code worked for default axes without the explicit toggle call, but not for the axisartist axes.
I tested this by making axisartist.AxisArtist.set_visible behave like axes_grid1.mpl_axes.SimpleAxisArtist.set_visible and then demo_parasite_axes2.py works again, although knowing my luck this probably breaks something else. :P
Also I think the better solution might be to do the exact opposite and make axes_grid1.mpl_axes.SimpleAxisArtist.set_visible behave like axisartist.AxisArist.set_visible? Or maybe leave both methods as they are? In either case you would then have to add the toggle code to twin* like @afvincent originally suggested.
But in general one problem with the axes grid toolkit it's that it's so damn inconsistent, so perhaps having at least set_visible behave the same might be nice.
tacaswell commented on Aug 2, 2016
👍 making set_visible apply to the children and making AA more consistent.
smheidrich commented on Aug 2, 2016
@tacaswell It might be better to make it consistent the other way round, i.e. by making set_visible not toggle any children ever. I guess the way to think about it is that toggle changes the properties of the axisartist. Then set_visible just determines whether the axisartist as a whole is shown, whatever its properties (with/without ticks or ticklabels) might be. In more practical terms, I think it's plausible that some people do use axisartists with e.g. their ticklables turned off as a conscious choice, and they don't expect set_visible to override this choice. I'm not sure though.
Fix for matplotlib#6836
Fix for matplotlib#6836
QuLogic commented on Feb 9, 2018
Was fixed by above PRs.