> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4