Skip to content

Axes3d attaches itself to a figure, where as Axes does not #18364

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

Closed
jklymak opened this issue Aug 27, 2020 · 9 comments
Closed

Axes3d attaches itself to a figure, where as Axes does not #18364

jklymak opened this issue Aug 27, 2020 · 9 comments

Comments

@jklymak
Copy link
Member

jklymak commented Aug 27, 2020

import matplotlib.pyplot as plt
import matplotlib.axes as maxes

fig = plt.figure()
ax = maxes.Axes(fig, [0.1, 0.1, 0.9, 0.9])
print(fig.get_children())

returns a list with no axes....

[<matplotlib.patches.Rectangle object at 0x7f8d75707dc0>]

For 3-d

import matplotlib.pyplot as plt
import matplotlib.axes as maxes
from mpl_toolkits.mplot3d import Axes3D

fig = plt.figure()
ax = Axes3D(fig)
print(fig.get_children())

has the axes attached:

[<matplotlib.patches.Rectangle object at 0x7fbc2968d160>, <mpl_toolkits.mplot3d.axes3d.Axes3D object at 0x7fbc2968df40>]

Axes3D.__init__ explicitly adds itself to its parent:

self.figure.add_axes(self)

whereas no such thing happens for the base Axes class.

Discovered as part of #18356, but discussing here because its orthogonal. But I think the behaviour here should be the same .

@jklymak
Copy link
Member Author

jklymak commented Aug 27, 2020

Cartopy GeoAxes doesn't seem to attach itself either (consistent w/ Axes).

@WeatherGod
Copy link
Member

git blame says that line has been there for at least 10 years. This might very well be the case where we used to do this for regular 2D axes, but no longer? Also, there were a lot of oddities with the original Axes3D design 10 years ago that required an inordinate amount of hacks to get it to work. When I revamped it for v1.1.0, I trashed a lot of those hacks and simplified the conceptual model. It very well could be that I simply just missed this.

@WeatherGod
Copy link
Member

Heh, just realized that this potentially might explain an old "double-draw" bug...

@jklymak
Copy link
Member Author

jklymak commented Aug 27, 2020

Heh, just realized that this potentially might explain an old "double-draw" bug...

Thats exactly how I found it - I added a new double-draw bug in #18356 by storing the axes in a flat list instead of an AxesStack which gets rid of duplicates by using a key.

I actually don't mind the idea that an axes attaches itself on instantiation - after all they require a fig as a kwarg so it makes sense. However, it would be preferable if both axes classes were consistent, and if it gets added, it should probably be added to the Axes so that all children classes also get it.

@dopplershift
Copy link
Contributor

👍 to making the two consistent. I'm just not sure what the ramifications are of making Axes attach itself.

@jklymak
Copy link
Member Author

jklymak commented Aug 28, 2020

Right now fig.add_axes(ax) only works if ax was created via Axes(fig,...), otherwise it explicitly errors out. So, is there a case where we would create an axes on a figure but not want to also add it to the axes stack?

@WeatherGod
Copy link
Member

WeatherGod commented Aug 28, 2020 via email

@jklymak
Copy link
Member Author

jklymak commented Aug 28, 2020

We still technically support adding a regular Axes object to a figure
without it being managed by a stack or whatever it was before we had the
stack (gridspec?).

I guess you could just add an axes as an artist w/ fig.add_artist(Axes(fig, ...))? I guess if someone wanted it out of the state-based stack (for gca etc) that would be one reason to not enforce a call to add_axes. Given that possibility I'm leaning towards just removing that call from Axes3D and making the user explicitly add all axes...

@anntzer
Copy link
Contributor

anntzer commented Mar 20, 2021

Closed by #19496, afaict.

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

No branches or pull requests

5 participants