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