On 10/01/2010 02:01 PM, Fernando Perez wrote: > Hey Ryan, > > On Fri, Oct 1, 2010 at 6:27 AM, Ryan May<rma...@gmail.com> wrote: > >> On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez<fperez....@gmail.com> wrote: >> >>> This manifested itself in some more complex MPL code that had multiple >>> events not working when run inside ipython, but working OK outside of >>> ipython. Fortunately, the small self-contained example demonstrates >>> the problem even with ipython not being in the picture at all (the >>> runs above were from the command line), so I think there is an issue >>> in MPL proper. >>> >>> Sorry that I can't dig deeper into the code right now to look for a fix... >>> >> Somewhere in the 1.0 development cycle, Michael modified the callback >> code to take weak references to methods. The purpose was to eliminate >> some "leaks" that were occurring because callback connections to >> objects were keeping them around and the proper disconnects were not >> made (much simpler fix than tracking down every mpl_connect and trying >> to see where do disconnect). What you're seeing in your script is that >> since you're not assigning the Handler object to anything, it's being >> garbage collected. It works for me if I change the second to last line >> to: >> >> h = Handler(f) >> > Many thanks for the info, that helps a lot. > > I was wondering though, would we still have a leak if strong > references are held in the canvas attribute? The canvas will be > deleted when the figure goes away, so that should properly allow the > callback references to be deleted, without deleting them early > otherwise, no? > The problem is when callbacks create cyclical references (which your example does not). If the Handler class in your example needed to update the figure or canvas in some way in the callback (which is a common usage pattern), that cyclical reference prevents either from being destroyed without running the cyclical garbage collector. And in that case, you can't write a __del__ method on the handler to explicitly disconnect the callbacks. > In any case, if my logic is flawed (quite likely, since I imagine M. > D. had a good look at this), it might be worth adding a > > .. warning:: > > section about this pattern to the event docs: > > http://matplotlib.sourceforge.net/users/event_handling.html > > because the problem is subtle and hard to diagnose (I just noticed it > had also been reported recently > http://sourceforge.net/mailarchive/forum.php?thread_name=4C9B7793.5020908%40gmail.com&forum_name=matplotlib-devel). > True -- it's non-obvious and confusing. On the other hand, the user is no longer required to explicitly disconnect callbacks, which was the source of many other subtle and hard to diagnose problems within the matplotlib code itself.
I'm still not completely happy with it, so I'd love to find a "third way" if there's anything anyone can suggest. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA ------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
