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

Nick Coghlan ncoghlan at gmail.com
Thu May 19 12:15:07 CEST 2005


Guido van Rossum wrote:
> I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX
> (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still
> awaiting PEP moderator approval I believe?)

It turns out my submission email took the scenic route, and I wasn't using a 
proper text editor so the formatting of the raw text version is messed up.

Given that I need to clean that formatting up, I figure I might as well update 
it in light of recent discussions before I resubmit it.

> the main difference is
> that Nick proposes a way to inject an exception into a generator; and
> I've said a few times that I like that idea.

If the current generator integration is dropped from PEP 343, I can rewrite my 
PEP to be *just* about the combination of PEP 288 and PEP 325 you describe, and 
use PEP 343 integration as a motivating use case.

The alternative would be to just submit and immediately withdraw it (since the 
user defined statement semantics now match PEP 343, and I basically like the 
generator interface you are proposing here, there wouldn't be much left of my 
PEP except for the big 'Rejected Options' section giving my understanding of the 
reasons we didn't take up various options).

<snip parts of the proposal I agree with completely>

> - g.close() throws a GeneratorExit exception in the generator, and
> catches it (so g.close() itself does not raise an exception).
> g.close() is idempotent -- if the generator is already closed, it is a
> no-op. If the generator, against the rules, yields another value, it
> is nevertheless marked closed.

Can't we make the method raise a RuntimeError when the generator breaks the 
rules? Or should we just print a warning instead (like the deletion code does if 
__del__ raises an exception)?

> - When a generator is GC'ed, its close() method is called (which is a
> no-op if it is already closed).

This is like giving it a __del__ method though, since it can now resurrect 
arbitrary objects from a cycle it is involved in. I think you made the right 
call elsewhere, when you convinced me that generator's shouldn't have a __del__ 
method any more than files should.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com


More information about the Python-Dev mailing list