On 8/23/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Simpler is in the eye of the beholder - the current close() merely uses
throw() to raise a particular kind of exception 'asynchronously' (which is
already a familiar concept due to KeyboardInterrupt). What you're suggesting
is a completely new
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
Regarding yield in the finally problem:
The current implementation throws RuntimeException after the yield
transfer the control back to the close method. If that is changed to
reporting a bad behavior and rethrowing GeneratorExit or its hidden
analog as suggested at the point of yield inside the
Igor Bukanov wrote:
This example also suggests how to fix generators. One just need to
change the close method so it would cause return executed right after
the yield instead of throw.
I.e. replace the current text from
http://www.python.org/dev/peps/pep-0342/
snip close() =
This discussion probably happens as a result of attempts to copy
Python's design in JavaScript. I propose that JavaScript do whatever
it wants and its developers leave Python alone -- maybe some time in
the future we'll be able to compare the two approaches. I think it's
impossible to do so at the
I rather like it, actually. I don't recall there being any real reasons to
catch a GeneratorExit exception, but even if there were, you could do the
equivalent like this:
try:
closed = True
yield 1
closed = False
finally:
if closed:
#
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
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
At 01:44 AM 8/24/2006 +0200, Igor Bukanov wrote:
Regarding yield in the finally problem:
The current implementation throws RuntimeException after the yield
transfer the control back to the close method. If that is changed to
reporting a bad behavior and rethrowing GeneratorExit or its hidden
Consider the following example:
for i in range(3):
try:
print i
break
except:
print Unexpected exception!
finally:
print Finally
When executed, it naturally prints
0
Finally
since break does not use exceptions to transfer the control and as
such can not be stopped using
10 matches
Mail list logo
