New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instance methods and WeakRefs don't mix. #58836
Comments
SUMMARY The behavior of instance methods makes it impossible to keep a weakref on them. The reference dies instantly even if the instance and the method still exist. EXAMPLE
>>> def callback1():
... print "In callback1."
>>> class SomeClass:
... def callback2(self):
... print "In callback2."
>>> for callback in callbacks:
... callback()
In callback1.
ANALYSIS The WeakSet in the example above, and the weakref.ref() it employs, actually behave as specified. It's the particular nature of bound methods that causes the unexpected behavior. From what I understand, instance methods are bound dynamically when looked up on the instance. A new object of type instancemethod is created each time: >>> t1 = some_instance.callback
>>> t2 = some_instance.callback
>>> t1 is t2
False So when a program calls weakref.ref(some_instance.callback), a new instancemethod object is created on the fly, a weakref to that object is created... and the instancemethod object dies, because its refcount is 0. This fundamental difference between instance methods and other callables makes it painful to implement weakly referencing callback registries. PROPOSED SOLUTION Changing the fundamental nature of instance methods to accommodate one single corner case doesn't seem worthwhile. Similarly, changing the behavior of weakref.ref(), which does work as specified, is probably not a good idea. My approach is thus to provide a new helper, WeakCallableRef, that behaves like weakref.ref(), but is safe to use on callables and does what you would naturally expect with instance methods. It works by binding the lifetime of the ref to that of 1/ the instance bearing the method, and 2/ the unbound method itself. It is also safe to use on other function types beside instance methods, so implementations of callback registries don't have to special case depending on the callable type. The unexpected behavior should also be mentioned somewhere in the weakref documentation, by the way. See attached file for a proposed implementation. |
I quite like the WeakCallableRef idea, having had to work around this problem myself in the past (using a similar mechanism). This looks like a feature request rather than a bug report, though; changing Type and Versions accordingly. |
Adding some useful links from Simon Feltman in bpo-16452. See also: This is the recipes: |
Just a note this is also referred to as a "WeakMethod" by some folks (so this ticket shows up in those searches). See also: |
WeakMethod sounds like a good name to me. However, instead of acting as a proxy, I think it should act as a regular weakref (i.e. you have to call it to get the actual method object). |
Here is a patch adding a WeakMethod class. It still lacks docs, I'll add some if people agree on the principle. |
The WeakCallableRef that was attached seemed to support regular functions (or anything callable) which is nice. The naming also leaves room for a WeakCallableProxy. |
Some more complex examples from various libraries: https://github.com/django/django/blob/master/django/dispatch/saferef.py I think both of these originated in pydispatcher. |
The patch looks okay to me. What does inheriting from 'ref' buy you? This feels a bit strange to me: the way I think of it, the WeakMethod *has* a weakref to the underlying object, rather than *being* a weakref to the underlying object. The __repr__ also seems a bit misleading as a result: >>> o = Object()
>>> m = o.some_method
>>> WeakMethod(m)
<weakref at 0x100665ae0; to 'Object' at 0x101115840> |
Hmm, I'm not sure. I thought I'd mimick KeyedRef's inheritance design, plus isinstance(..., weakref.ref) works, and composition would make the object slightly bigger. Other than that, probably nothing. |
New changeset 27c20650aeab by Antoine Pitrou in branch 'default': |
Committed, thank you! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: