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.
Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
