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 g
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 v
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
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
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
>ch
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
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:
# s
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
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/
> by simpler one:
Sim
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 us
10 matches
Mail list logo