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; you could still put a
yield in a finally clause that intercepts a return, just as today you
can write
def f():
for i in range(10):
print i
try:
return
finally:
break
print 999
where the finally clause nullifies the return. In a generator, a yield
in the finally clause still needs to be dealt with somehow.
On 8/23/06, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> On 8/23/06, Phillip J. Eby wrote:
> > Our original
> > assumption was that if they could implement throw() then they could clearly
> > implement close(), since close() was defined in terms of throw(). An
> > asynchronous return might be another matter.
>
> Such asynchronous return can always be implemented via a special
> hidden exception that is invisible to catch statements. I.e an
> implementation of generators can still use ___GeneratorExit
> internally as long as it is not exposed to scripts.
>
> Regards, Igor
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
