Here's the word on GC vs. __del__, by the way. ---------- Forwarded message ---------- From: Tim Peters <tim.peters@gmail.com> Date: May 19, 2005 10:24 AM Subject: Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup To: guido@python.org

Remind me. Why again is GC afraid to touch objects with a __del__? (There's a good reason, it's so subtle I keep forgetting it and I can't seem to reconstruct the argument from first principles this morning.)

tp_clear is called on the objects in a cycle in an arbitrary order, and it's possible for a __del__ method to (e.g.) resurrect any object in the cycle. But obj.tp_clear() doesn't necessarily leave obj in a sane state, so we could end up resurrecting insane objects.

Would the same reasoning apply to a generator that's part of a cycle if deleting the generator would cause more Python code to run?

The general rule now is that gc must guarantee that no object it decided is trash can be reachable from any Python code by the time a gc pass first calls tp_clear. Calling tp_clear can certainly trigger __del__ methods (and weakref callbacks), so it's not (a common misunderstanding) the rule that __del__ methods can't run at all during gc. The real rule is subtler than that: gc is happy to run a __del__ method (or wr callback), provided that no trash is reachable from such a method. I haven't had the bandwidth to follow this discussion, but I sure _suppose_ that other trash objects could be reachable from a trash generator in a cycle. -- --Guido van Rossum (home page: http://www.python.org/~guido/)