Repository navigation
Axes creation seems to reuse an old one instead of creating a new one #9024
Description
Bug report
Bug summary
It appears that when plt.axes() is called, if the parameters are identical to a previous call, that old axes is reused instead of creating a new one. I don't know if this is by design or not but it makes the behavior very unexpected.
Code for reproduction
%matplotlib notebook
import matplotlib.pyplot as plt
from matplotlib.widgets import Button
from mpl_toolkits.axes_grid1 import inset_locator
fig = plt.figure()
ax = fig.add_subplot(111)
a1=plt.axes([0,0,1,1], facecolor='yellow')
pos1=inset_locator.InsetPosition(parent=ax,lbwh=[.5,.5,.04,.04])
a1.set_axes_locator(locator=pos1)
b1=Button(a1,'1')
a2=plt.axes([0,0,1,1], facecolor='yellow')
# the parameters above are identical to those of a1, resulting in this behaving
# as if one says a2=a1
pos2=inset_locator.InsetPosition(parent=ax,lbwh=[.6,.5,.04,.04])
a2.set_axes_locator(locator=pos2)
b2=Button(a2,'2')
a3=plt.axes([0,0,1,1], facecolor='orange')
# the parameters above are different from previous axes() calls and therefore a new
# axes is created
pos3=inset_locator.InsetPosition(parent=ax,lbwh=[.7,.5,.04,.04])
a3.set_axes_locator(locator=pos3)
b3=Button(a3,'3')
# The use of buttons is to illustrate a use case. But it is not necessary; the behavior is the
# same if one comments out the three Button() calls
plt.show()Actual outcome
Two buttons appear, one with "1" and "2" on top of each other and the other with "3" in it.
Expected outcome
Three buttons appear: "1", "2", and "3" horizontally.
Matplotlib version
- Operating System: Window 7
- Matplotlib Version: 2.0.2
- Python Version: 3.6.1 (Anaconda 4.4.0)
- Jupyter Version: 5.0.0 (IPython 5.3.0)
- Other Libraries: No
Activity
efiring commented on Aug 12, 2017
It's by design--an old design that none of us like.
WeatherGod commented on Aug 12, 2017
fariza commented on Aug 12, 2017
@efiring can we change that old design decision for a future release?
efiring commented on Aug 12, 2017
I don't see any reason why not. There is some movement in that direction. See #7377, especially towards the end of the comment sequence. Maybe we could even get @anntzer's suggested deprecation upon key collision into 2.1, and dump the bad old behavior entirely for 2.2. Comments, @tacaswell?
tacaswell commented on Aug 12, 2017
👍 in principle, but I think it has to be coupled with the sort of improvements that @jklymak and @pganssle have been talking about to improve how to layout many axes.
efiring commented on Aug 12, 2017
To me, these are independent; the suggested deprecation and removal is simply getting rid of a misfeature that has no compelling use case. It has nothing to do with laying out multiple axes.
pganssle commented on Aug 12, 2017
@efiring I more or less agree with this, though I suppose with my feature suggestion one of the open questions is "what will the user-facing API look like", so there might be some overlap there. That said, I think it's easy enough to say early on that whatever the user-facing API looks like, it doesn't need to include this sort of dubious behavior.
jklymak commented on Aug 13, 2017
i don't foresee the commands to place an axes as changing in any user facing way in the changes I was going to make. If someone hard places and axes like this I'd assume they don't want it to participate in any layout.
anntzer commented on Aug 14, 2017
I have a patch that deprecates the behavior (warn on collision) but will wait for #9029 (or similar) to be merged first before making a PR.
tacaswell commented on Aug 14, 2017
On the phone call we decided to go the 'deprecate' route for 2.1.
fariza commented on Aug 15, 2017
Fixed with #9037
anntzer commented on Aug 31, 2017
As a side note, in reply to #9024 (comment) (how was that dealt with when twinning) it appears that twinning works because the second axes is created with the sharex=firstaxes additional kwarg, which thus does not trigger the bad behavior :)
WeatherGod commented on Aug 31, 2017