matplotlib-devel Mailing List for matplotlib

Hello all,
I would like to submit the following branch on github for review and
merging into matplotlib trunk:
http://github.com/ellisonbg/matplotlib/commits/guisupport
This branch implements the logic needed for the qt4 and wx backends to
fully work with the upcoming IPython 0.11 release. In our testing we
have run many of the mpl examples (including the new animation
examples) in both qt4/wx in both the terminal based IPython and the
new IPython Qt GUI. For background on these changes please see this
thread:
http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel
It is important to note that we have not updated the other matplotlib
backends (gtk, tk, etc.) to have this logic. This is mainly because
we know almost nothing about these toolkits and could really use some
help from folks who are experts at the respective toolkits. We have
done some minimal testing and these other backends do work for simple
examples in the terminal IPython, but they won't work in all cases and
will definitely not work in the new IPython Qt based GUI.
We would love feedback and help testing as these changes are
significant (even though only a few lines of code). To test this
stuff you will need to grab the following IPython development branch:
http://github.com/ipython/ipython/tree/newkernel
You should be able to run the examples in regular ipython:
ipython --pylab qt4|wx
Or the new GUI
ipythonqt --pylab qt4|wx
Cheers,
Brian

On 09/03/2010 09:14 AM, Tony S Yu wrote:
>
> On Sep 3, 2010, at 10:23 AM, Sébastien Barthélemy wrote:
>
>> CC to matplotlib-devel& matplotlib-users
>>
>> 2010年9月3日 Tony S Yu<ts...@gm...>:
>>> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>>>
>>>> Hello,
>>>>
>>>> While using sage [1], I got problems drawing a line: for some reason,
>>>> the points with negative coordinates are not plotted (or are plotted
>>>> on top of others due to an offset problem and thus I cannot see them).
>>>> I can only reproduce the bug with specific data sets.
>>>>
>>>> [1] www.sagemath.org
>>>>
>>>> I think I could track down the bug to matplotlib, which sage uses to
>>>> render 2d plots.
>>>>
>>>> I included a sage script which generates the data set (in a pickle
>>>> file), and a python script which draws the faulty line.
>>>>
>>>> Usage is :
>>>>
>>>> $ sage generate_data.sage
>>>> $ python test_mpl.py
>>>>
>>>> I also included the pickled data, thus you don't need sage at all.
>>>> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
>>>>
>>>> Could somebody here confirm the problem, and give me a hint about what
>>>> is going on?
>>>
>>> I can confirm the issue.
>>
>> Great, thank you. I filed a bug:
>> https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
>>
>>> This appears to be a drawing bug: when I pan the drawing so that the negative data touches the edge of the axes frame, the rest of the line is drawn. So the line object is being created, but for some reason it's not being drawn correctly.
>>>
>>> The bug is really finicky: if I plot starting from the 3rd value of your data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The strange thing is that the first 100 or so data points defines the exact same point, so there's noting special about those first two points. (but this overlaying of data may be related to the bug)
>>>
>>> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend doesn't show line even after panning the plot)
>>>
>>> I don't really know how to debug drawing errors like this; so this is as far as can get.
>
> I'm not sure if I should respond to this email or the bug report, but since I made the claim here, I'll correct myself here: The bug is not in the drawing code as I had suggested.
>
> The bug is related to path simplification. If you turn off path simplification (e.g. plt.rc('path', simplify=False), the line is drawn in its entirety. This also explains why the bug disappeared when I trimmed the first two points: path simplification is triggered from data sets with atleast 128 points (your data has 129, so trimming two points turned off path simplification).
>
> I just wanted to correct my earlier comments.
>
Tony,
Thanks--it's in a comment added to the bug report. Also, this is the 
same problem as reported earlier by Jens Nie. The bug is in 
path_converters.h. I think I found part of it, but a real solution may 
require more than a changed line or two, and I can't spend more time on 
it at the moment. Mike D. could figure it out quickly, but I think he 
is not available right now.
Eric
> -T
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sep 3, 2010, at 10:23 AM, Sébastien Barthélemy wrote:
> CC to matplotlib-devel & matplotlib-users
> 
> 2010年9月3日 Tony S Yu <ts...@gm...>:
>> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>> 
>>> Hello,
>>> 
>>> While using sage [1], I got problems drawing a line: for some reason,
>>> the points with negative coordinates are not plotted (or are plotted
>>> on top of others due to an offset problem and thus I cannot see them).
>>> I can only reproduce the bug with specific data sets.
>>> 
>>> [1] www.sagemath.org
>>> 
>>> I think I could track down the bug to matplotlib, which sage uses to
>>> render 2d plots.
>>> 
>>> I included a sage script which generates the data set (in a pickle
>>> file), and a python script which draws the faulty line.
>>> 
>>> Usage is :
>>> 
>>> $ sage generate_data.sage
>>> $ python test_mpl.py
>>> 
>>> I also included the pickled data, thus you don't need sage at all.
>>> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
>>> 
>>> Could somebody here confirm the problem, and give me a hint about what
>>> is going on?
>> 
>> I can confirm the issue.
> 
> Great, thank you. I filed a bug:
> https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
> 
>> This appears to be a drawing bug: when I pan the drawing so that the negative data touches the edge of the axes frame, the rest of the line is drawn. So the line object is being created, but for some reason it's not being drawn correctly.
>> 
>> The bug is really finicky: if I plot starting from the 3rd value of your data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The strange thing is that the first 100 or so data points defines the exact same point, so there's noting special about those first two points. (but this overlaying of data may be related to the bug)
>> 
>> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend doesn't show line even after panning the plot)
>> 
>> I don't really know how to debug drawing errors like this; so this is as far as can get.
I'm not sure if I should respond to this email or the bug report, but since I made the claim here, I'll correct myself here: The bug is not in the drawing code as I had suggested. 
The bug is related to path simplification. If you turn off path simplification (e.g. plt.rc('path', simplify=False), the line is drawn in its entirety. This also explains why the bug disappeared when I trimmed the first two points: path simplification is triggered from data sets with atleast 128 points (your data has 129, so trimming two points turned off path simplification).
I just wanted to correct my earlier comments.
-T

Michiel,
On Fri, Sep 3, 2010 at 9:22 AM, Michiel de Hoon <mjl...@ya...> wrote:
> --- On Wed, 9/1/10, Brian Granger <ell...@gm...> wrote:
>> > So right now you're in a loop in which you let qt4 (or
>> wx) watch the file descriptors qt4 needs, then zeromq the
>> file descriptors that zeromq needs, and so on?
>>
>> ZMQ sockets are not really sockets in that they do not have
>> a file descriptor interface.
>
> That may be, but at the bottom of the ZMQ event loop is a call to select(), which expects a pair of ordinary file descriptors. At the same time, at the bottom of the qt4 event loop is also a call to select(), also using a set of file descriptors.
What you are saying is mostly right. ZMQ uses the best polling
mechanism for the platform (select/poll/epoll/kqueue/etc). In some
cases, there are actual file descriptors in the internals of zeromq.
As I understand it:
* Zeromq runs on other transports other than TCP and not all of those
transports have file descriptors.
* Even if zeromq is using TCP for transport, a single zeromq socket
may be implemented with many low level sockets during its lifetime.
These sockets are not in any way exposed in the public zeromq API.
* zeromq sockets are connectionless. If you were able to get those
low level file descriptors, the model would become leaky because you
would need to start handling the connection related events.
Thus, it is currently not an option to get those low level file
descriptors and do what you are proposing.
> Currently your event loop works approximately as follows:
>
> 1) Run the qt4 event loop, which calls select() inside qt4, watching the file descriptors that qt4 knows about.
> 2) Interrupt the qt4 event loop, and enter the ZMQ event loop, which calls select() inside ZMQ to watch the file descriptors ZMQ knows about.
> 3) If none if the ZMQ file descriptors have been signaled, go to 1).
>
> Ideally, you would want to call select() only once, and have it watch both the file descriptors qt4 knows about, as well as the file descriptors ZMQ knows about.
>
> So how to implement this?
>
> Think about just the ZMQ event loop for now. Just before entering the ZMQ event loop, ZMQ knows which file descriptors it should watch when it calls select(). Which means that ZMQ maintains in some form or another a list of file descriptors to watch. Now I don't know the details of ZMQ, but I suppose there is some function inside ZMQ that effectively adds one file descriptor to the ZMQ list of file descriptors to watch. Now, instead of this function, call an ipython-specific function that effectively adds this file descriptor to the list of file descriptors that qt should watch for (probably using QSocketNotifier). Now you don't need to enter the ZMQ event loop at all: When you enter the qt event loop, and there is any activity on one of the ZMQ file descriptors, the qt event loop will notice and take the appropriate action.
>
> Does this make sense?
Definitely, it makes total sense, it is just not possible today with
how zeromq is implemented. The zeromq devs are working on a file
descriptor interface, but it will not be fully compatible with the
usual one in that you won't be able to distinguish between read, write
and error events with only the file descriptor. I am not sure the
file descriptor interface that zeromq will eventually have will
actually work with what qt is expecting.
The other issue is one of maintainability. Currently the GUI code and
zeromq event loop code is completely separate and orthogonal. We can
easily change one without affecting the other. If we were to combine
the event loops, we would loose that nice separation that makes our
code more robust, stable and maintainable. Also, I should mention
that the current approach functions perfectly well. Both the GUI and
IPython remain extremely responsive at all times.
I should also mention that the help we need with matplotlib right now
is *completely* independent of these issues of how we integrate the
two event loops.
Thanks for the ideas though.
Cheers,
Brian
> --Michiel.
>
>
>
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

--- On Wed, 9/1/10, Brian Granger <ell...@gm...> wrote:
> > So right now you're in a loop in which you let qt4 (or
> wx) watch the file descriptors qt4 needs, then zeromq the
> file descriptors that zeromq needs, and so on?
> 
> ZMQ sockets are not really sockets in that they do not have
> a file descriptor interface.
That may be, but at the bottom of the ZMQ event loop is a call to select(), which expects a pair of ordinary file descriptors. At the same time, at the bottom of the qt4 event loop is also a call to select(), also using a set of file descriptors.
Currently your event loop works approximately as follows:
1) Run the qt4 event loop, which calls select() inside qt4, watching the file descriptors that qt4 knows about.
2) Interrupt the qt4 event loop, and enter the ZMQ event loop, which calls select() inside ZMQ to watch the file descriptors ZMQ knows about.
3) If none if the ZMQ file descriptors have been signaled, go to 1).
Ideally, you would want to call select() only once, and have it watch both the file descriptors qt4 knows about, as well as the file descriptors ZMQ knows about.
So how to implement this?
Think about just the ZMQ event loop for now. Just before entering the ZMQ event loop, ZMQ knows which file descriptors it should watch when it calls select(). Which means that ZMQ maintains in some form or another a list of file descriptors to watch. Now I don't know the details of ZMQ, but I suppose there is some function inside ZMQ that effectively adds one file descriptor to the ZMQ list of file descriptors to watch. Now, instead of this function, call an ipython-specific function that effectively adds this file descriptor to the list of file descriptors that qt should watch for (probably using QSocketNotifier). Now you don't need to enter the ZMQ event loop at all: When you enter the qt event loop, and there is any activity on one of the ZMQ file descriptors, the qt event loop will notice and take the appropriate action.
Does this make sense?
--Michiel.
 

CC to matplotlib-devel & matplotlib-users
2010年9月3日 Tony S Yu <ts...@gm...>:
> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>
>> Hello,
>>
>> While using sage [1], I got problems drawing a line: for some reason,
>> the points with negative coordinates are not plotted (or are plotted
>> on top of others due to an offset problem and thus I cannot see them).
>> I can only reproduce the bug with specific data sets.
>>
>> [1] www.sagemath.org
>>
>> I think I could track down the bug to matplotlib, which sage uses to
>> render 2d plots.
>>
>> I included a sage script which generates the data set (in a pickle
>> file), and a python script which draws the faulty line.
>>
>> Usage is :
>>
>> $ sage generate_data.sage
>> $ python test_mpl.py
>>
>> I also included the pickled data, thus you don't need sage at all.
>> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
>>
>> Could somebody here confirm the problem, and give me a hint about what
>> is going on?
>
> I can confirm the issue.
Great, thank you. I filed a bug:
https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
> This appears to be a drawing bug: when I pan the drawing so that the negative data touches the edge of the axes frame, the rest of the line is drawn. So the line object is being created, but for some reason it's not being drawn correctly.
>
> The bug is really finicky: if I plot starting from the 3rd value of your data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The strange thing is that the first 100 or so data points defines the exact same point, so there's noting special about those first two points. (but this overlaying of data may be related to the bug)
>
> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend doesn't show line even after panning the plot)
>
> I don't really know how to debug drawing errors like this; so this is as far as can get.

Hi folks,
On Sat, Aug 28, 2010 at 12:42 PM, Brian Granger <ell...@gm...> wrote:
> Hi all,
>
> As you may know, this summer we have been working on a new two
> process IPython that has a beautiful Qt frontend GUI and a ZMQ based
> messaging layer between that GUI and the new IPython kernel. Many
> thanks to Enthought for funding this effort!
>
> We are currently in the process of adding GUI event loop integration
> to the ipython kernel so users can do interactive plotting like they
> can with the regular ipython. You may also remember that last summer
> we implemented a new PyOs_InputHook based GUI integration for the
> regular ipython. This has not been released yet, but all of this will
> be released in the upcoming 0.11 release.
>
> I am emailing everyone because we see that there is a need for all of
> us to agree on two things:
>
> 1. How to detect if a GUI application object has been created by someone else.
> 2. How to detect if a GUI event loop is running.
>
> Currently there is code in both ETS and matplotlib that fails to
> handle these things properly in certain cases. With IPython 0.10,
> this was not a problem because we used to hijack/monkeypatch the GUI
> eventloops after we started them. In 0.11, we will no longer be doing
> that. To address these issues, we have created a standalone module
> that implements the needed logic:
>
> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
>
> This module is heavily commented and introduces a new informal
> protocol that all of use can use to detect if event loops are
> running. This informal protocol is inspired by how some of this is
> handled inside ETS. Our idea is that all projects will simply copy
> this module into their code and ship it. It is lightweight and does
> not depend on IPython or other top-level imports. As you will see, we
> have implemented the logic for wx and qt4, we will need help with
> other toolkits. An important point is that matplotlib and ets WILL
> NOT WORK with the upcoming release of IPython unless changes are made
> to their respective codebases. We consider this a draft and are more
> than willing to modify the design or approach as appropriate. One
> thing that we have not thought about yet is how to continue to support
> 0.10 within this model.
>
> The good news amidst all of this is that the quality and stability of
> the GUI support in IPython is orders of magnitude better than that in
> the 0.10 series.
I just wanted to ping back with this topic, both to update you a
little and to ask for help...
Brian is now using Andrew's git repo and made an mpl branch for
experimenting with the guisupport work:
http://github.com/ellisonbg/matplotlib/tree/guisupport
For now there's just one commit, but at any point in time, this URL
will easily let you compare what's new vs Andrew's trunk (which I'm
considering the canonical reference on github):
http://github.com/ellisonbg/matplotlib/compare/astraw:trunk...guisupport
Basically we're a bit stumped with GTK, and also partly with Tk. With
Tk things *seem* to work ok in light testing, but it's possible that
problems lurk. It's just that we do get something 'for free' because
python itself manages the Tk event loop.
But for GTK, no clue...
This type of code will be needed to support the multiprocess
capabilities we're developing with ipython, and for qt, wx and
(apparently, but only by chance) tk, matplotlib with the guisupport
added, works right now on IPython:
- 0.10.1 with the old -Xthread flags (just like always, rather fragile
and brittle but useful for a lot of things).
- trunk at the command-line, using --pylab {qt, wx, tk}: this uses
PyOSInputHook, which is more reliable than the --Xthread flags.
- our 'newkernel' branch with the fancy Qt widget and two process control.
So we're doing pretty good: Qt and Wx seem solid, Tk so far is cutting
us slack. But GTK is simply hosed. Brian tried and got lost, and I
don't have the foggiest clue.
So if anyone here can help us out solidify the GTK solution, as well
as point out anything that might be needed for Tk and any possible
flaws in the code for Wx/Qt, we'd be immensely grateful.
We're very, very excited about the possibilities the code we're
building in ipython opens up. But we don't want to have the massive
regression of breaking GTK support for matplotlib, and we're a bit
stuck.
Once the code in Brian's branch is tested/fixed/approved by you guys,
we'd like to propose it for merging into matplotlib. The idea is that
MPL would carry its own copy of this guisupport file, enabling it to
cooperate well with IPython or anyone else who supports this approach
(and we've talked with the IEP author --http://code.google.com/p/iep,
enthought for the Traits machinery, etc). But it would NOT create an
ipython dependency on matplotlib, nor should it break any embedded
uses in a GUI application, etc.
This stuff is hard, and Brian and I are both pretty ignorant when it
comes to GUIs, so any help we can get will be really appreciated.
If you want to comment inline or on the whole commit for the purposes
of review, the commit URL at github always allows that:
http://github.com/ellisonbg/matplotlib/commit/d4dcce8635bfe4a82f5e6eef89aa5daf025f1a20
The little + signs on the left of each line are for inline comments,
and the box at the bottom for whole-commit commenting.
Thanks!
f

On 09/02/2010 04:12 PM, Ryan May wrote:
> On Thu, Sep 2, 2010 at 8:33 PM, Benjamin Root<ben...@ou...> wrote:
>> On Thu, Sep 2, 2010 at 7:57 PM, Eric Firing<ef...@ha...> wrote:
>>> On 09/02/2010 01:21 PM, Benjamin Root wrote:
>>>> I think I understand the purpose for each container by itself, but not
>>>> for having all three together at the same time. At the very least,
>>>> maybe we can eliminate the list container? I think the difficulty there
>>>> would be with clearing the stack properly.
>>>
>>> You can't just blow away self.axes, because that is a public interface,
>>> and a convenient one. Maybe self.axes needs to be an object that can
>>> behave like a list, to preserve the public interface, but that
>>> underneath has the mechanisms required for the functionality now
>>> provided by self._seen and self._axstack, so that they can be eliminated.
>>
>> Right, of course... must have had a brain-fart moment.
>>
>> Creating another list-like object would probably be an ideal way to tuck
>> away self._seen and self._axstack. Especially given the public nature of
>> self.axes, we could never really be sure that self._axstack and self._seen
>> had all the axes listed in self.axes. I am gonna have to look through the
>> code and see what needs to be implemented.
>>
>> Does Python 2.4 support subclassing things like list?
Yes: http://docs.python.org/release/2.4.4/lib/module-UserList.html
But I agree that turning Figure.axes into a property with the getter 
generating a list probably will do the trick. Maybe you can use 
_ax_stack._elements? It looks like that may completely parallel the 
present Figure.axes. Stack, or a subclass or derivative, could store 
(ax, key) tuples instead of just the ax list. Then the equivalent of 
_seen could be generated on the fly as needed. (This is very fast.) 
This would completely eliminate the redundant storage of Axes references 
in Figure, and simplify some Figure methods.
Eric
>
> Probably. But why not take advantage of properties as they were meant
> to be? You can make self.axes a property that generates the list
> from the self._axstack/self._seen only when accessed. We'd need to see
> if self.axes is used in any performance sensitive areas, but this
> seems like a *textbook* example of why properties are awesome.
>
> Is there any instance where adding to self.axes is a public API?
> Because given self._axstack/self._seen, it would seem that appending
> to this list would not by itself work.
>
> I'm willing to cook up the patch tomorrow if no one beats me to it.
>
> Ryan
>

On Thu, Sep 2, 2010 at 8:33 PM, Benjamin Root <ben...@ou...> wrote:
> On Thu, Sep 2, 2010 at 7:57 PM, Eric Firing <ef...@ha...> wrote:
>> On 09/02/2010 01:21 PM, Benjamin Root wrote:
>> > I think I understand the purpose for each container by itself, but not
>> > for having all three together at the same time. At the very least,
>> > maybe we can eliminate the list container? I think the difficulty there
>> > would be with clearing the stack properly.
>>
>> You can't just blow away self.axes, because that is a public interface,
>> and a convenient one. Maybe self.axes needs to be an object that can
>> behave like a list, to preserve the public interface, but that
>> underneath has the mechanisms required for the functionality now
>> provided by self._seen and self._axstack, so that they can be eliminated.
>
> Right, of course... must have had a brain-fart moment.
>
> Creating another list-like object would probably be an ideal way to tuck
> away self._seen and self._axstack. Especially given the public nature of
> self.axes, we could never really be sure that self._axstack and self._seen
> had all the axes listed in self.axes. I am gonna have to look through the
> code and see what needs to be implemented.
>
> Does Python 2.4 support subclassing things like list?
Probably. But why not take advantage of properties as they were meant
to be? You can make self.axes a property that generates the list
from the self._axstack/self._seen only when accessed. We'd need to see
if self.axes is used in any performance sensitive areas, but this
seems like a *textbook* example of why properties are awesome.
Is there any instance where adding to self.axes is a public API?
Because given self._axstack/self._seen, it would seem that appending
to this list would not by itself work.
I'm willing to cook up the patch tomorrow if no one beats me to it.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Sep 2, 2010 at 7:57 PM, Eric Firing <ef...@ha...> wrote:
> On 09/02/2010 01:21 PM, Benjamin Root wrote:
> > On Thu, Sep 2, 2010 at 3:51 PM, Ryan May <rm...@gm...
> > <mailto:rm...@gm...>> wrote:
> >
> > On Sep 2, 2010, at 14:14, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> >
> > > There was a bug report recently (not to the mailing list) where
> > the reporter noted that if an Axes3D was created using the
> > fig.add_subplot(111, projection='3d') or fig.gca(projection='3d'),
> > then you can not clear the figure using fig.clf(). Doing so causes
> > an exception to be thrown.
> > >
> > > Tracing down the problem revealed that the Axes3D object was
> > added twice to the figure's self.axes, but exists only once in
> > self._axstack. So, when looping through self.axes, a delete is
> > attempted on an axes that no longer exists in the stack.
> > >
> > > I traced down the cause for why the axes is added twice. Because
> > of how Axes3D used to be attached to a figure (and is still valid),
> > the __init__() function for Axes3D calls figure.add_axes(self) on
> > its own. This initialization is done after the check in add_subplot
> > to see if the axes exists already in the figure. So, add_subplot
> > then adds the axes without knowing that it already happened.
> > >
> > > 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.
> >
> > I agree the duplicated code should be eliminated. Depending on how
> > complex it would be to clean that up and not break existing code,
> > could we in the short term make use of sets to eliminate duplicates?
> >
> > Ryan
> >
> >
> > I am not exactly sure how possible that would be. I am not exactly sure
> > I understand the rationale behind the current implementation. There is
> > a dictionary self._seen that stores key/axes pairs, a self.axes list
> > storing the axes, and a self._axstack Stack (from cbook, I believe) that
> > also contains the axes.
> >
> > I think I understand the purpose for each container by itself, but not
> > for having all three together at the same time. At the very least,
> > maybe we can eliminate the list container? I think the difficulty there
> > would be with clearing the stack properly.
>
> You can't just blow away self.axes, because that is a public interface,
> and a convenient one. Maybe self.axes needs to be an object that can
> behave like a list, to preserve the public interface, but that
> underneath has the mechanisms required for the functionality now
> provided by self._seen and self._axstack, so that they can be eliminated.
>
> Eric
>
>
>
Right, of course... must have had a brain-fart moment.
Creating another list-like object would probably be an ideal way to tuck
away self._seen and self._axstack. Especially given the public nature of
self.axes, we could never really be sure that self._axstack and self._seen
had all the axes listed in self.axes. I am gonna have to look through the
code and see what needs to be implemented.
Does Python 2.4 support subclassing things like list?
Ben Root

On 09/02/2010 01:21 PM, Benjamin Root wrote:
> On Thu, Sep 2, 2010 at 3:51 PM, Ryan May <rm...@gm...
> <mailto:rm...@gm...>> wrote:
>
> On Sep 2, 2010, at 14:14, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
> > There was a bug report recently (not to the mailing list) where
> the reporter noted that if an Axes3D was created using the
> fig.add_subplot(111, projection='3d') or fig.gca(projection='3d'),
> then you can not clear the figure using fig.clf(). Doing so causes
> an exception to be thrown.
> >
> > Tracing down the problem revealed that the Axes3D object was
> added twice to the figure's self.axes, but exists only once in
> self._axstack. So, when looping through self.axes, a delete is
> attempted on an axes that no longer exists in the stack.
> >
> > I traced down the cause for why the axes is added twice. Because
> of how Axes3D used to be attached to a figure (and is still valid),
> the __init__() function for Axes3D calls figure.add_axes(self) on
> its own. This initialization is done after the check in add_subplot
> to see if the axes exists already in the figure. So, add_subplot
> then adds the axes without knowing that it already happened.
> >
> > 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.
>
> I agree the duplicated code should be eliminated. Depending on how
> complex it would be to clean that up and not break existing code,
> could we in the short term make use of sets to eliminate duplicates?
>
> Ryan
>
>
> I am not exactly sure how possible that would be. I am not exactly sure
> I understand the rationale behind the current implementation. There is
> a dictionary self._seen that stores key/axes pairs, a self.axes list
> storing the axes, and a self._axstack Stack (from cbook, I believe) that
> also contains the axes.
>
> I think I understand the purpose for each container by itself, but not
> for having all three together at the same time. At the very least,
> maybe we can eliminate the list container? I think the difficulty there
> would be with clearing the stack properly.
You can't just blow away self.axes, because that is a public interface, 
and a convenient one. Maybe self.axes needs to be an object that can 
behave like a list, to preserve the public interface, but that 
underneath has the mechanisms required for the functionality now 
provided by self._seen and self._axstack, so that they can be eliminated.
Eric
>
> Ben Root
>