[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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
