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
