Sorry I'm lost in the discussion. What is the relation between the weak references in callback registry and moving stuff to the figure manager?
Federico On 7 Nov 2014 14:13, "Thomas Caswell" <tcasw...@gmail.com> wrote: > 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
