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.