[Python-Dev] issue 9141, finalizers and gc module

martin at v.loewis.de martin at v.loewis.de
Tue Apr 17 16:45:36 CEST 2012

> What I want to know is, why is this limitation in place?  Here are  
> two possibilities:
> 1)      "The order of calling finalizers in a cycle is undefined so  
> it is not a solvable problem".  But this would allow a single  
> object, with only internal cycles to be collected.  Currently this  
> is not the case.

It's similar to this, but not exactly: "A finalizer in a cycle mail
try to refer back to an object that was already cleared, and fail
because of that; this may cause arbitrary failures changing from
run to run".

It's true that a cycle involving only a single object with __del__
could be safely collected. This special case was not implemented.

> 2)      "During collection, the interpreter is in a fragile state  
> (linked lists of gc objects with refcount bookkeeping in place) and  
> no unknown code can be allowed to run".  This is the reason I  
> personally think is the true reason.

No, that's not the case at all. As Antoine explains in the issue,
there are plenty of ways in which Python code can be run when breaking
a cycle. Not only weakrefs, but also objects released as a consequence
of tp_clear which weren't *in* the cycle (but hung from it).

> So, I ask you:  What is allowed during tp_clear()?  Is this a hard  
> rule?  What is the reason?

We are all consenting adults. Everything is allowed - you just have to
live with the consequences.


More information about the Python-Dev mailing list