[Python-Dev] GeneratorExit is unintuitive and uneccessary

[Phillip J. Eby]

At 04:10 PM 8/23/2006 -0700, Guido van Rossum wrote:
>IIUC this is how return currently works -- in some sense it's an
>exception, but it can't be caught, and it won't escape from the
>current frame. Ditto for break/continue.
>
>The generator extensions are still very young, and I'm not against
>changing them somewhat in 2.6 or py3k. Perhaps GeneratorExit can be
>replaced by a treatment similar to the treatment of return. But I'm
>not sure it helps with the original problem;

It depends on what you're referring to as "the original problem".  If you 
mean the problem Bob Ippolito opened a bug for, then yes, it does not solve 
that problem.  But I think we agree that *that* problem doesn't actually 
need solving.

However, it *does* solve the problem(s) that Igor Bukanov brought up, 
namely that GeneratorExit is unintuitive and unnecessary.  :)  It also 
fixes the problem of calling close() or GC'ing a generator written for an 
earlier version of Python, that yields inside a try-except.


>In a generator, a yield
>in the finally clause still needs to be dealt with somehow.

And we should keep the existing PEP-defined behavior for dealing with 
it.  That is, my understanding is that the only part of close()'s 
definition that would change is the 'throw(GeneratorExit)' bit.

I just wish this had been proposed some time much sooner, like maybe not 
long after I did the original implementation of 
throw()/close()/etc.  During the original discussion, I'd have been more 
skeptical of a return-based approach.  But knowing what I know now about 
the implementation, making it based on return instead would be trivial.  A 
proof-of-concept patch I just whipped up adds 7 lines to the hook code in 
ceval.c (to determine whether WHY_RETURN or WHY_EXCEPTION should be used), 
and 5 lines to gen_close() in genobject.c.