Problem with event handling in matplotlib in tkinter

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 <brenbarn@…1219…> 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@…1735…sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-users