There's a new PEP proposing to change how to treat StopIteration bubbling
up out of a generator frame (not caused by a return from the frame). The
proposal is to replace such a StopIteration with a RuntimeError (chained to
the original StopIteration), so that only *returning* from a generator (or
On Wed, Nov 19, 2014, at 15:10, Guido van Rossum wrote:
There's a new PEP proposing to change how to treat StopIteration bubbling
up out of a generator frame (not caused by a return from the frame). The
proposal is to replace such a StopIteration with a RuntimeError (chained
to
the original
On 2014-11-19 20:10, Guido van Rossum wrote:
There's a new PEP proposing to change how to treat StopIteration
bubbling up out of a generator frame (not caused by a return from
the frame). The proposal is to replace such a StopIteration with a
RuntimeError (chained to the original StopIteration),
On Thu, Nov 20, 2014 at 7:48 AM, MRAB pyt...@mrabarnett.plus.com wrote:
The PEP says any generator that depends on an implicitly-raised
StopIteration to terminate it will have to be rewritten to either catch
that exception or use a for-loop
Shouldn't that be ... explicitly-raised ..., because
On Thu, Nov 20, 2014 at 3:45 AM, Nick Coghlan ncogh...@gmail.com wrote:
The part I found most compelling was when you pointed out that in the
special method implementations, the normal return path was always spelled
with return, while the value missing result was indicated with a special
kind
