[Python-Dev] Design question: call __del__ for cyclical garbage?

[Tim Peters]

[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 <wink>).

> 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