Re: [Matplotlib-users] Problem with event handling in matplotlib in tkinter

[Thomas C. <tca...@gm...>]

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 <tca...@gm...> 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 <bre...@br...>
> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>