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

[Isaac Schwabacher]

On 11/26/14, Nick Coghlan  wrote:
> On 26 November 2014 at 04:04, Guido van Rossum <guido at python.org> wrote:
> > On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico <rosuav at gmail.com> wrote:
> >>
> >> On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
> >> <ischwabacher at wisc.edu> wrote:
> >> > Yield can also raise StopIteration, if it's thrown in. The current
> >> > interaction of generator.throw(StopIteration) with yield from can't be
> >> > emulated under the PEP's behavior, though it's not clear that that's a
> >> > problem.
> >> >
> >>
> >> Hrm. I have *absolutely* no idea when you would use that, and how
> >> you'd go about reworking it to fit this proposal. Do you have any
> >> example code (production or synthetic) which throws StopIteration into
> >> a generator?
> >
> >
> > Sounds like a good one for the obfuscated Python contest. :-)
> >
> > Unless the generator has a try/except surrounding the yield point into which
> > the exception is thrown, it will bubble right out, and PEP 479 will turn
> > this into a RuntimeError. I'll clarify this in the PEP (even though it
> > logically follows from the proposal) -- I don't think there's anything to
> > worry about.
> 
> This is actually the edge case that needs to be handled in contextlib
> - a StopIteration raised by the with statement body gets thrown into
> the generator implementing the context manager. My current porting
> recommendation is to catch the RuntimeError & look at __cause__ to see
> if it's the StopIteration instance that was thrown in, but an
> alternative option would be to just call gen.close() in that case,
> rather than gen.throw(exc).

If this is the current contextlib implementation, does it break if the yield statement is replaced with yield from another context manager generator?

ijs