On Sun, Sep 5, 2010 at 9:16 PM, Eric Firing <efir...@hawaii.edu> wrote:
> 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,
>
> It might have been OK already, but I tweaked things a bit to ensure a key
> would be available, and I added a check for duplicate keys. Can you find a
> way to make it fail with legitimate code? As before, it passes
> backend_driver.py, but that certainly doesn't exercise all the
> possibilities.
>
> Eric
>
>
Code mayhem? I'll see what I can do!
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
