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

Guido van Rossum gvanrossum at gmail.com
Thu May 19 19:38:49 CEST 2005


Here's the word on GC vs. __del__, by the way.

---------- Forwarded message ----------
From: Tim Peters <tim.peters at 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 at 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/)


More information about the Python-Dev mailing list