Skip to content

Axes creation seems to reuse an old one instead of creating a new one #9024

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
omasoud opened this issue Aug 12, 2017 · 13 comments
Closed

Axes creation seems to reuse an old one instead of creating a new one #9024

omasoud opened this issue Aug 12, 2017 · 13 comments
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Milestone
v2.1

Comments

@omasoud
Copy link

omasoud commented Aug 12, 2017 •
edited
Loading

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
@efiring
Copy link
Member

efiring commented Aug 12, 2017

It's by design--an old design that none of us like.

@WeatherGod
Copy link
Member

WeatherGod commented Aug 12, 2017 via email

@fariza
Copy link
Member

fariza commented Aug 12, 2017

@efiring can we change that old design decision for a future release?

@efiring
Copy link
Member

efiring commented 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
Copy link
Member

👍 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.

@tacaswell tacaswell added this to the 2.2 (next next feature release) milestone Aug 12, 2017
@efiring
Copy link
Member

efiring commented 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
Copy link
Member

@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
Copy link
Member

jklymak commented 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
Copy link
Contributor

anntzer commented 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 tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Aug 14, 2017
@tacaswell tacaswell added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Aug 14, 2017
@tacaswell
Copy link
Member

On the phone call we decided to go the 'deprecate' route for 2.1.

@anntzer anntzer mentioned this issue Aug 15, 2017
Merged
6 tasks
@fariza
Copy link
Member

fariza commented Aug 15, 2017

Fixed with #9037

@fariza fariza closed this as completed Aug 15, 2017
@anntzer anntzer mentioned this issue Aug 31, 2017
Merged
@anntzer
Copy link
Contributor

anntzer commented Aug 31, 2017 •
edited
Loading

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
Copy link
Member

WeatherGod commented Aug 31, 2017 via email

@anntzer anntzer mentioned this issue Sep 7, 2017
Closed
@ResidentMario ResidentMario mentioned this issue Dec 23, 2017
Closed
@jklymak jklymak mentioned this issue Jan 25, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Milestone
v2.1
Development

No branches or pull requests
8 participants
@efiring @tacaswell @WeatherGod @anntzer @pganssle @fariza @jklymak @omasoud