[Python-Dev] PEP 479: Change StopIteration handling inside generators

Nick Coghlan ncoghlan at gmail.com
Thu Nov 27 00:15:43 CET 2014


On 27 Nov 2014 03:58, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
> On 26 November 2014 at 17:19, Guido van Rossum <guido at python.org> wrote:
> > It's hard to use as an example because the behavior of contextlib is an
> > integral part of it -- currently for me the example boils down to
"there is
> > a bug in contextlib"
>
> Hmm, fair point. I was assuming that the bug in contextlib can't be
> fixed with the current language behaviour (and I'd personally be OK
> with the example simply adding a comment "this can't be fixed without
> changing Python as proposed in the PEP"). But I'm not sure how true
> that is, so maybe it's not quite as compelling as it seemed to me at
> first.

The "contextlib only" change would be to map StopIteration in the body of
the with statement to gen.close() on the underlying generator rather than
gen.throw(StopIteration). (That's backwards incompatible in its own way,
since it means you *can't* suppress StopIteration via a generator based
context manager any more)

This is actually the second iteration of this bug: the original
implementation *always* suppressed StopIteration. PJE caught that one
before Python 2.5 was released, but we didn't notice that 3.3 had brought
it back in a new, more subtle form :(

It's worth noting that my "allow_implicit_stop" idea in the other thread
wouldn't affect subgenerators - those would still convert StopIteration to
RuntimeError unless explicitly silenced.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141127/480417e4/attachment.html>


More information about the Python-Dev mailing list