(original) (raw)

On Wed, Nov 26, 2014 at 3:15 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 27 Nov 2014 03:58, "Paul Moore" <p.f.moore@gmail.com> wrote:
\>
\> On 26 November 2014 at 17:19, Guido van Rossum <guido@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.

You've lost me in this subthread. Am I right to conclude that the PEP change doesn't cause problems for contextlib(\*), but that the PEP change also probably wouldn't have helped diagnose any contextlib bugs?

(\*) Except perhaps that some old 3rd party copy of contextlib may eventually break if it's not updated.

--Guido van Rossum (python.org/\~guido)