Logged In: YES 
user_id=31435

> Ah,the detail that I was missing was that wr_callback is not
> invoked if the weakref list has been cleared.  I.e., calling
> _PyWeakref_ClearRef() is enough ensure that the callback is
> never implicitly envoked

Indeed, ensuring that the callback never triggers by magic is 
a primary *purpose* of _PyWeakref_ClearRef().

I should add something here:  this is so delicate in part 
because I didn't (during the *last* round of bug fixes) want 
to allocate any heap space during gc -- if malloc couldn't find 
more heap space when gc needed it, then the only thing I 
could do is kill the Python process.

So the deeper and somewhat ugly truth here is that gc is (re)
using the (already-allocated) weakref object as a container 
*just* to remember its wr_callback pointer.  It would have 
been easier to understand if, instead, gc could have saved 
away the wr_callback pointers in its own PyList object, and 
used weakrefobject.c's clear_weakref() instead.  Alas, there's 
no limit on how big such a list may need to become.

As things turned out, it's a very good thing I couldn't do 
that.  Fred subsequently made weakrefs subclassable, and 
now there are actual uses for passing the weakref object to 
the callback (e.g., weak value dictionaries use a weakref 
subclass now, and an instance of this subclass has the 
associated dict key as an attribute), so now a weakref object 
has to be kept around as long as its callback may still get 
invoked.