Repository navigation
Axes3d attaches itself to a figure, where as Axes does not #18364
Description
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:
matplotlib/lib/mpl_toolkits/mplot3d/axes3d.py
Line 139 in c035f66
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 .
Activity
jklymak commentedon Aug 27, 2020
Cartopy
GeoAxesdoesn't seem to attach itself either (consistent w/Axes).WeatherGod commentedon Aug 27, 2020
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 commentedon Aug 27, 2020
Heh, just realized that this potentially might explain an old "double-draw" bug...
jklymak commentedon Aug 27, 2020
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
AxesStackwhich 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
figas 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 theAxesso that all children classes also get it.dopplershift commentedon Aug 27, 2020
👍 to making the two consistent. I'm just not sure what the ramifications are of making
Axesattach itself.jklymak commentedon Aug 28, 2020
Right now
fig.add_axes(ax)only works ifaxwas created viaAxes(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 commentedon Aug 28, 2020
jklymak commentedon Aug 28, 2020
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 toadd_axes. Given that possibility I'm leaning towards just removing that call fromAxes3Dand making the user explicitly add all axes...anntzer commentedon Mar 20, 2021
Closed by #19496, afaict.