[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Tim Peters]

[Guido]
> ...
> I think in the past I've unsuccessfully tried to argue that if a
> cycle contains exactly one object with a Python-invoking finalizer,
> that finalizer could be invoked before breaking the cycle. I still
> think that's a sensible proposal, and generators may be the use case
> to finally implement it.

You have argued it, and I've agreed with it.  The primary hangup is
that there's currently no code capable of doing it.  gc currently
determines the set of objects that must be part of cyclic trash, or
reachable only from cyclic trash, but has no relevant knowledge beyond
that.  For example, it doesn't know the difference between an object
that's in a trash cycle, and an object that's not in a trash cycle but
is reachable only from trash cycles.  In fact, it doesn't know
anything about the cycle structure.  That would require some sort of
new SCC (strongly connected component) analysis.

The graph derived from an arbitrary object graph by considering each
SCC to be "a node" is necessarily a DAG (contains no cycles), and the
general way to approach what you want here is to clear trash in a
topological sort of the SCC DAG:  so long as an SCC contains only one
object that may execute Python code, it's safe to run that object's
cleanup code first (for a meaning of "safe" that may not always
coincide with "explainable" or "predictable" <0.9 wink>).  gc would
probably need to give up after the first such thingie is run, if any
SCCs are reachable from the SCC X containing that thingie (gc can no
longer be sure that successor SCCs _are_ still trash:  they too are
reachable from X, so may have been resurrected by the Python code X
ran).

There's currently no forcing at all of the order in which tp_clear
gets called, and currently no analysis done sufficient to support
forcing a relevant ordering.