Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-27 Thread Igor Bukanov
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

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-27 Thread Igor Bukanov
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

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-27 Thread Igor Bukanov
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

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-23 Thread Phillip J. Eby
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

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-23 Thread 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 >ch

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-23 Thread Guido van Rossum
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

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-23 Thread Phillip J. Eby
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

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-23 Thread Guido van Rossum
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

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-23 Thread Nick Coghlan
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

[Python-Dev] GeneratorExit is unintuitive and uneccessary

2006-08-22 Thread Igor Bukanov
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