At 12:36 PM 5/19/2005 -0400, James Y Knight wrote:
On May 19, 2005, at 8:43 AM, Phillip J. Eby wrote:
At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote:
Guido van Rossum wrote:
- When a generator is GC'ed, its close() method is called (which is a no-op if it is already closed).
Does this mean that all generators will be ineligible for cyclic garbage collection (since they implicitly have something equivalent to a __del__ method)?
No, since it's implemented in C. (The C equivalent to __del__ does not interfere with cyclic GC.)
But you're missing the point -- there's a *reason* that __del__ interferes with cyclic GC. It doesn't just do it for the heck of it! You can't simply have the C delete call into python code...the objects the generator has references to may be invalid objects already because they've been cleared to break a cycle. If you want to execute python code on collection of a generator, it must be done via __del__, or else it'll be horribly, horribly broken.
Eeyowch. Good point. OTOH, the only way a generator-iterator can become part of a cycle is via an action taken outside the generator. (E.g. passing it into itself via 'continue', creating a link from one of its arguments to it, etc.) So, it's probably not a terrible limitation in practice.