[Python-Dev] weakref enhancements
Raymond Hettinger
rhettinger at ewtllc.com
Fri Sep 29 01:08:56 CEST 2006
[Alex Martelli]
>I've had use cases for "weakrefs to boundmethods" (and there IS a
>Cookbook recipe for them),
>
Weakmethods make some sense (though they raise the question of why bound
methods are being kept when the underlying object is no longer in use --
possibly as unintended side-effect of aggressive optimization).
I'm more concerned about weakattr which hides the weak referencing from
client code when it is usually the client that needs to know about the
refcounts:
n = SomeClass(x)
obj.a = n
del n # hmm, what happens now?
If obj.a is a weakattr, then n get vaporized; otherwise, it lives.
It is clearer and less error-prone to keep the responsibility with the
caller:
n = SomeClass(x)
obj.a = weakref.proxy(n)
del n # now, it is clear what happens
The wiki-space example shows objects that directly assign a copy of self
to an attribute of self. Even in that simplified, self-referential
example, it is clear that correct functioning (when __del__ gets called)
depends knowing whether or not assignments are creating references.
Accordingly, the code would be better-off if the weak-referencing
assignment was made explicit rather than hiding the weak-referencing
wrapper in a descriptor.
Raymond
More information about the Python-Dev
mailing list