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

[Tim Peters]

[Michael Hudson]
>> I'm not sure the problem is so much that anyone _wants_ to support
>> resurrection in __del__, it's just that it can't be prevented.

[Guido]
> Well, Java has an answer to that (at least I believe Tim Peters told
> me so years ago): it allows resurrection, but will only call the
> finalizer once. IOW if the resurrected object is GC'ed a second time,
> its finalizer won't be called.

Right, that's a technical trick Java uses.  Note that it doesn't stop
resurrection:  all the resurrection-related pitfalls remain.  One good
result is that cycles containing objects with finalizers don't stop gc
progress forever; some progress can always be made, although it may be
as little as reclaiming one object per full gc cycle (ignoring that
"full gc cycle" is a fuzzy concept in a runs-in-parallel threaded gc).
 A bad result is an endless stream of nearly-impenetrable articles
encouraging deep fear of Java finalizers ;-); e.g.,

    http://www.devx.com/Java/Article/30192/0/page/1

> This would require a bit "__del__ already called" on an object, but don't we have
> a whole word of GC-related flags?

Nope!  You're probably thinking of gc_refs.  That's a Py_ssize_t
today, and is overloaded to hold, at various times, a status enum
(which only needs a few bits) or a copy of the object's refcount
(which uses all the bits).