I am also beginning to like the idea of hanging all of these things off of FigureManager objects. We have them around, but they are really only used in pyplot (which is a shame) and seems a natural place to put all of these aggregation type objects (list of animations, the toolbar stuff, the navigation stuff, the blit-manager object I want to pull in from scikit-image, etc).
@Federico, tell me if I am being dumb about this. Tom On Fri Nov 07 2014 at 2:05:29 PM Thomas Caswell <tcasw...@gmail.com> wrote: > The old-style classes are because mpl pre-dates new-style classes. On > master all classes now inherit from object (as of about 3 weeks ago > https://github.com/matplotlib/matplotlib/pull/3662) > > > > On Fri Nov 07 2014 at 2:02:15 PM Brendan Barnwell <brenb...@brenbarn.net> > wrote: > >> On 2014-11-07 09:37, Benjamin Root wrote: >> > Figured it out! The instance of Test() isn't being retained anywhere, so >> > when it goes out of scope, the garbage collector eventually gets it. The >> > fact that it works in py3k is likely a coincidence as the garbage >> > collector would eventually have cleaned it up at some point. I don't >> > know the scoping/garbage collection rules for lambdas, so I am guessing >> > that they persist as they are part of the code as opposed to a >> > de-reference-able (is that even a word?). Just save the instance of Test >> > as a member variable of App, and you should be good to go! >> >> This note in cbook.py (which handles the callback registry) >> explains >> it. . . sort of: >> >> In practice, one should always disconnect all callbacks when they >> are no longer needed to avoid dangling references (and thus memory >> leaks). However, real code in matplotlib rarely does so, and due >> to its design, it is rather difficult to place this kind of code. >> To get around this, and prevent this class of memory leaks, we >> instead store weak references to bound methods only, so when the >> destination object needs to die, the CallbackRegistry won't keep >> it alive. The Python stdlib weakref module can not create weak >> references to bound methods directly, so we need to create a proxy >> object to handle weak references to bound methods (or regular free >> functions). This technique was shared by Peter Parente on his >> `"Mindtrove" blog >> <http://mindtrove.info/articles/python-weak-references/>`_. >> >> Definitely a hidden trap! >> >> Also, speaking of the dangers of classes not inheriting from >> object, I >> noticed that CallbackRegistry in cbook.py is also an old-style class >> (doesn't inherit from object). I then did a search and found numerous >> old-style classes throughout MPL. Is there any reason for this? >> >> -- >> Brendan Barnwell >> "Do not follow where the path may lead. Go, instead, where there is no >> path, and leave a trail." >> --author unknown >> >> ------------------------------------------------------------ >> ------------------ >> _______________________________________________ >> Matplotlib-users mailing list >> Matplotlib-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >
------------------------------------------------------------------------------
_______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users