making weakref.ref objects subclassable

I'm planning to commit a patch (http://www.python.org/sf/983019) that makes weak references subclassable. This includes the following changes: - weakref.ref and weakref.ReferenceType will become aliases for each other - weakref.ref will be a modern, new-style class with proper __new__ and __init__ methods - weakref.WeakValueDictionary will have a lighter memory footprint, using a new weakref.ref subclass to associate the key with the value, allowing us to have only a single object of overhead for each dictionary entry (currently, there are 3 objects of overhead per entry: a weakref to the value, a weakref to the dictionary, and a function object used as a weakref callback; the weakref to the dictionary could be avoided without this change) - a new macro, PyWeakref_CheckRefExact(), will be added - PyWeakref_CheckRef() will check for subclasses of weakref.ref - the cyclic garbage detector will be affected by the change to PyWeakref_CheckRef(); it will potentially call issubtype() for objects in the unreachable list that do not have finalizers (in the move_troublemakers() function). This should only happen for weakref objects which are not of one of the "standard" three types (ref, proxy, and callable proxy). For debug builds, it will also affect assertions in the clear_weakerfs() and release_weakrefs() functions. The change to the cyclic garbage detector probably carries the most risk, and that only because the potential for a performance penalty. Running the Zope 3 test suite did not show any clear change in performance, and a key subsystem in Zope (zope.interface) uses weakrefs extensively. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

"Fred L. Drake, Jr." <fdrake@acm.org> writes:
I'm planning to commit a patch (http://www.python.org/sf/983019) that makes weak references subclassable. This includes the following changes:
Would "why?" be an apposite question? I'm sure there is a reason, but I haven't seen it yet :-) Cheers, mwh -- incidentally, asking why things are "left out of the language" is a good sign that the asker is fairly clueless. -- Erik Naggum, comp.lang.lisp

On Thursday 01 July 2004 10:43 am, Michael Hudson wrote:
Would "why?" be an apposite question? I'm sure there is a reason, but I haven't seen it yet :-)
Absolutely! I hinted at the reason in my original email, but it was not made explicit that it was the reason. The change allows the WeakValueDictionary to be implemented in a much more memory-efficient manner. The current implementation causes each entry to create and retain the following objects in addition to the actual key: - a weakref to the value, with a callback - a function object used as the callback; a new function is created for every entry, since it contains a reference to the key in a default parameter value - a weakref to the WeakValueDictionary itself, to avoid creating a cycle. The last object could be removed without any change to the C implementation; all that's really needed is a single weakref to the WeakValueDictionary that can be shared by all such callbacks. Using a subclass of the weakref.ref type (KeyedRef in the patch), the key can be stored as an attribute of the weakref, allowing a single object to be created and retained as overhead (with the allocation for that object being at most 8 bytes larger than a stock weakref). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
participants (2)
-
Fred L. Drake, Jr.
-
Michael Hudson