On 09/05/2010 11:06 AM, Benjamin Root wrote: > On Sun, Sep 5, 2010 at 2:53 PM, Eric Firing <efir...@hawaii.edu > <mailto:efir...@hawaii.edu>> wrote: > > On 09/04/2010 05:50 PM, Benjamin Root wrote: > > On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee > <lee.j.j...@gmail.com <mailto:lee.j.j...@gmail.com> > > <mailto:lee.j.j...@gmail.com <mailto:lee.j.j...@gmail.com>>> wrote: > > > > On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root > <ben.r...@ou.edu <mailto:ben.r...@ou.edu> > > <mailto:ben.r...@ou.edu <mailto:ben.r...@ou.edu>>> wrote: > > > I think there are multiple issues here. Primarially, there is > > the issue > > > that Axes3D is attaching itself to a figure. However, in the > > interest of > > > backwards-compatibility, we can't just fix this outright. There > > is also the > > > issue that there are multiple places in the Figure class that are > > adding > > > axes to the figure object. Ideally, shouldn't we have a single > > function > > > that performs proper checks and adds an axes? Then that function > > should be > > > used in the other class functions to perform this action. In my > > opinion, > > > there is too much duplicated code here. > > > > While I agree that we need to do something with the > duplicated code, I > > think our priority should be fixing a bug. > > The easiest solution (that is backward compatible) seems to be > > registering an Axes class that does not add itself to the figure. > > For example, > > > > class Axes3DBase(Axes): > > # All of the original Axes3D stuff, but do not add itself > to the > > figure during the initialization > > > > class Axes3D(Axes3DBase): > > def __init__(self, ...) > > Axes3DBase.__init__(self, ...) > > self.fig.add_axes(self) > > > > # And register Axes3DBase instead of Axes3D > > import matplotlib.projections as proj > > proj.projection_registry.register(Axes3DBase) > > > > Regards, > > > > -JJ > > > > > > > > Hmm, that actually would solve the problem at hand. What I am > concerned > > about is having others use this as a way to solve other issues with > > Axes3D that we then can't get rid of it. > > > > My vote is that your approach be use as a last resort. I doubt > this bug > > is time-critical, and I rather see the problems in Figure be > correctly > > addressed. > > I agree. > > I went ahead and committed a fix to the trunk, svn 8681, and closed the > ticket. Please review the changeset. It can always be reverted or > modified as needed. The changeset solves the Axes3D problem by blocking > double-addition of an Axes to a Figure. It does this entirely in > figure.py, plus a small change in artist.py. It consolidates the > tracking of Axes instances, eliminating _seen and turning .axes into a > property. Unfortunately, it causes a net increase in LOC. > > There is still much duplication between add_axes and add_subplot which I > did not try to address at all. I don't know whether it is worth trying > to factor out the commonality, or whether that would reduce readability. > > Eric > > > Eric, > > Looking through the changeset, everything seems fine to me. My only > question is that it seemed, to me at least, that it was possible to add > an axes to a figure without adding a key. Was this an invalid operation > or not? If not, how does the AxesStack handle axes without a key?
Ben, I think that it aught not be possible to add an axes without a key--but it looks like it is possible at present via add_subplot. I will try to fix that. Eric > > Thanks, > Ben Root > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
