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

Guido van Rossum gvanrossum at gmail.com
Thu May 19 19:01:43 CEST 2005


[James Y Knigh]
> 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.

Thank you for reminding me -- that's indeed the reason, and it applies
here. I think in the past I've unsuccessfully tried to argue that if a
cycle contains exactly one object with a Python-invoking finalizer,
that finalizer could be invoked before breaking the cycle. I still
think that's a sensible proposal, and generators may be the use case
to finally implement it.

All this suggests that generators should indeed have a __del__()
method which is synonymous with close() (I want close() to be the
user-facing API).

BTW I think that close() and __del__() should raise an exception when
the throw(GeneratorExit) call doesn't end up either re-raising
GeneratorExit or raising StopIteration. The framework for calling
__del__() takes care of handling this exception (by printing and then
ignoring it). Raymond take notice if you're still working on the PEP.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list