[Python-Dev] reference leaks, __del__, and annotations

[Jim Jewett]

Duncan Booth wrote:
> Surely if you have a cycle what you want to do is to pick just *one* of the
> objects in the cycle and break the link which makes it participate in the
> cycle.

No, I really meant to do them all.  I was trying to avoid creating an
attractive nuisance.  In
http://mail.python.org/pipermail/python-dev/2006-March/063239.html,
Thomas Wouters categorized the purpose of __del__ methods as
[paraphrased]

(A)  Resource Cleanup  (cycles irrelevant)
(B)  Object created a cycle, and knows how to break it safely.
(C)  Those which do things the style guide warns against.

The catch is that objects in the first two categories have no way to
know when they should do the cleanup, except by creating a __del__
method (as generators now do).

For category (A), their __del__ methods should be called as early as
possible.  Even for category (B), it does no harm.  Why waste time
recalculating cycles more often than required?  If the object is lying
about whether it can be used to safely break cycles, that is a bug,
and I would rather catch it as early as possible, instead of letting
it hide behind "oh well, the cycle was already broken".

In fairness, I had not fully considered category(C), when an object
intends not only to revive itself, but to prevent its subobjects from
cleaning up either.

Nick Coghlan
> A simple Boolean attribute (e.g. __finalized__) should be enough. ...
> If it's both present and true, the GC can ignore the finaliser on that instance

That doesn't really take care of resource release, which needs to be
called, and called early.(And the name will sound odd if it holds
resources only sometimes, so that it has to flip the __finalized__
attribute.)

-jJ