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.

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

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

Closed
omasoud opened this Issue Aug 12, 2017 · 13 comments

Comments

Projects
None yet
8 participants
@omasoud

omasoud commented Aug 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@efiring

efiring Aug 12, 2017

Member

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

Member

efiring commented Aug 12, 2017

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

@WeatherGod

This comment has been minimized.

Show comment
Hide comment
@WeatherGod

WeatherGod Aug 12, 2017

Member
Member

WeatherGod commented Aug 12, 2017

@fariza

This comment has been minimized.

Show comment
Hide comment
@fariza

fariza Aug 12, 2017

Member

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

Member

fariza commented Aug 12, 2017

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

@efiring

This comment has been minimized.

Show comment
Hide comment
@efiring

efiring Aug 12, 2017

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@tacaswell

tacaswell Aug 12, 2017

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.

Member

tacaswell commented 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.

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

@efiring

This comment has been minimized.

Show comment
Hide comment
@efiring

efiring Aug 12, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@pganssle

pganssle Aug 12, 2017

Contributor

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

Contributor

pganssle commented 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

This comment has been minimized.

Show comment
Hide comment
@jklymak

jklymak Aug 13, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@anntzer

anntzer Aug 14, 2017

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@tacaswell

tacaswell Aug 14, 2017

Member

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

Member

tacaswell commented Aug 14, 2017

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

@anntzer anntzer referenced this issue Aug 15, 2017

Merged

Deprecate axes collision #9037

0 of 6 tasks complete
@fariza

This comment has been minimized.

Show comment
Hide comment
@fariza

fariza Aug 15, 2017

Member

Fixed with #9037

Member

fariza commented Aug 15, 2017

Fixed with #9037

@anntzer

This comment has been minimized.

Show comment
Hide comment
@anntzer

anntzer Aug 31, 2017

Contributor

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 :)

Contributor

anntzer commented 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

This comment has been minimized.

Show comment
Hide comment
@WeatherGod

WeatherGod Aug 31, 2017

Member
Member

WeatherGod commented Aug 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment