This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients
Date 2004-10-29.17:13:06
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=31435

> I had to change _PyWeakref_ClearRef() since it was also
> clearing the weakref list of the trash object.

That was really its *purpose*.  If a trash weakref with a 
callback isn't removed from the referent's list of weakrefs, 
then the callback will trigger when PyObject_ClearWeakRefs() 
is invoked on the referent.  The purpose of 
_PyWeakref_ClearRef() was to ensure that the callback never 
triggers.

> Now it just sets wr_object to Py_None.

That won't stop the callback from triggering.  It also means 
(see earlier comment) that PyObject_ClearWeakRefs() will 
never removed the weakref from the list either, although I'm 
not sure that does real harm.

> I also made some serious simplifications to gcmodule by
> just treating trash weakref objects with callbacks the same
> as objects with __del__ methods (i.e. move them to the
> finalizers list and then do the transitive closure of that set).

Does that mean they can end up in gc.garbage too?  If so, I 
don't think that's sellable.  See the end of gc_weakref.txt:

    An alternative would have been to treat objects with
    callbacks like objects with __del__ methods, refusing to
    collect them, appending them to gc.garbage instead.
    That would have been much easier.  Jim Fulton gave a
    strong argument against that (on Python-Dev):
    ...

> I'm attaching a patch.  It's a work in progress.

Aren't we all <wink>.
History
Date User Action Args
2007-08-23 14:27:07adminlinkissue1055820 messages
2007-08-23 14:27:07admincreate