[Python-Dev] Design question: call del for cyclical garbage? (original) (raw)

Tim Peters tim_one@email.msn.com
Fri, 3 Mar 2000 22:26:54 -0500

[Tim]

Note, though, that there is NO good answer to finalizers in cycles! The

[Greg Stein]

"Note" ?? Not just a note, but I'd say an axiom :-)

An axiom is accepted without proof: we have plenty of proof that there's no thoroughly good answer (i.e., every language that has ever addressed this issue -- along with every language that ever will ).

By definition, you have two objects referring to each other in some way. How can you definitely know how to break the link between them? Do you call A's finalizer or B's first? If they're instances, do you just whack their dict and hope for the best?

Exactly. The programmer may know the right thing to do, but the Python implementation can't possibly know. Facing both facts squarely constrains the possibilities to the only ones that are all of understandable, predictable and useful. Cycles with finalizers must be a Magic-Free Zone else you lose at least one of those three: even Guido's kung fu isn't strong enough to outguess this.

[a nice implementation sketch, of what seems an overly elaborate scheme, if you believe cycles with finalizers are rare in intelligently designed code) ]

Provided Guido stays interested in this, he'll make his own fun. I'm just inviting him to move in a sane direction <0.9 wink>.

One caution:

... If the careful-cleaning algorithm hits the end of the careful set of objects and the set is non-empty, then throw an exception: GCImpossibleError.

Since gc "can happen at any time", this is very severe (c.f. Guido's objection to making resurrection illegal). Hand a trash cycle back to the programmer instead, via callback or request or whatever, and it's all explicit without more cruft in the implementation. It's alive again when they get it back, and they can do anything they want with it (including resurrecting it, or dropping it again, or breaking cycles -- anything). I'd focus on the cycles themselves, not on the types of objects involved. I'm not pretending to address the "order of finalization at shutdown" question, though (although I'd agree they're deeply related: how do you follow a topological sort when there isn't one? well, you don't, because you can't).

realistically y'rs - tim