On 4 Nov 2014 10:31, "Guido van Rossum" <guido@python.org> wrote:
>
> On Mon, Nov 3, 2014 at 1:38 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>>
>> Guido van Rossum wrote:
>>
>>> FWIW the implementation of my proposal is easy to describe (which the Zen approves of): when a StopIteration leaves a frame, replace it with some other exception (either a new, custom one or maybe just RuntimeError), chaining the original StopIteration.
>>
>>
>> Wouldn't that break all existing iterators whose next() method
>> is implemented in Python? Since the code that catches the
>> StopIteration is always in a different frame then.
>>
>> Or are you only talking about generator frames here, not
>> frames in general?
>
>
> I have to apologize, I pretty much had this backwards.
>
> What I should have said is that a generator should always be terminated by a return or falling off the end, and if StopIteration is raised in the generator (either by an explicit raise or raised by something it calls) and not caught by an except clause in the same generator, it should be turned into something else, so it bubbles out as something that keeps getting bubbled up rather than silently ending a for-loop. OTOH StopIteration raised by a non-generator function should not be mutated.
>
> I'm sorry if this invalidates Nick's endorsement of the proposal.

I actually thought this was what you meant originally, and while it *would* require changes to contextlib, they're fairly minor: the current check for StopIteration would change to catch "UnexpectedStopIteration" instead, and the exception identity check would look at __cause__ rather than directly at the caught exception.

> I definitely see this as a serious backward incompatibility: no matter how often it leads to buggy or obfuscated code, it's how things have always worked.

Aye, breaking the equivalence between "return" and "raise StopIteration" is pretty major.

I'm not even sure a plausible transition plan is possible, as at least contextlib would trigger any warning we might issue.

Regards,
Nick.