[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 

   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 

   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.


More information about the Python-Dev mailing list