Guido van Rossum wrote:
[snip]
> - I think there's a better word than Flow, but I'll keep using it
> until we find something better.
How about simply reusing Iteration (ala StopIteration)?
Pass in 'ContinueIteration' for 'continue'
Pass in 'BreakIteration' for 'break'
Pass in 'AbortIteration' for 'return' and finalisation.
And advise strongly *against* intercepting AbortIteration with anything other
than a finally block.
> - The new __next__() API can also (nay, *must*, to make all this work
> reliably) be used to define exception and cleanup semantics for
> generators, thereby rendering obsolete PEP 325 and the second half
> of PEP 288. When a generator is GC'ed (whether by reference
> counting or by the cyclical garbage collector), its __next__()
> method is called with a BreakFlow exception instance as argument (or
> perhaps some other special exception created for the purpose). If
> the generator catches the exception and yields another value, too
> bad -- I consider that broken behavior. (The alternative would be
> to keep calling __next__(BreakFlow()) until it doesn't return a
> value, but that feels uncomfortable in a finalization context.)
As suggested above, perhaps the exception used here should be the exception that
is raised when a 'return' statement is encountered inside the block, rather than
the more-likely-to-be-messed-with 'break' statement.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4