[Python-Dev] issue 9141, finalizers and gc module (original) (raw)

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 tpclear()? 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.

Regards, Martin

More information about the Python-Dev mailing list