[Python-Dev] making weakref.ref objects subclassable

[Tim Peters]

[Fred L. Drake, Jr.]
> I'm planning to commit a patch (http://www.python.org/sf/983019) that
> makes weak references subclassable.  This includes the following changes:
> 
> ...
> - 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).

I think the new expense is actually that PyType_IsSubtype() will get called 
once per collection on each scanned object that is unreachable, doesn't have

a finalizer, and isn't of one of the three std weakref types (not just for 
weakref objects that aren't of one of the std weakref types -- it's all 
objects that aren't of one of the std weakref types).

But that isn't scary.  An object is typically unreachable exactly once in
its lifetime (so far as gc is concerned), so it's one measly extra 
PyType_IsSubtype() call over the lifetime of each non-std-weakref container 
object without a finalizer, and that is reclaimed by virtue of ending up in
a dead cycle, or reachable only from a dead cycle.  Most container objects 
continue to get reclaimed via refcounting (the patch has no effect on that),

so are never found to be unreachable by gc, and so never incur the trivial-
anyway new call to PyType_IsSubtype().

> ...
> The change to the  cyclic garbage detector probably carries the most risk,

Well, there is no change to gcmodule.c, except for the indirect change in 
what the PyWeakref_Check() macro expands to.  The risks with weakrefs 
historically lie elsewhere (in the weakref code itself, and in typeobject.c 
-- gc had horrible problems with weakrefs when it didn't do anything special

with them, but that was really just one bug-- a massive oversight --and
we've had no additional problems with weakrefs in gc since repairing that
oversight).

> 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.

For reasons given above, I believe gc performance will be virtually
unchanged for almost all programs.