<div dir="ltr">Trying to keep the thread on focus...<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 7, 2014 at 3:20 AM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 06, 2014 at 10:54:51AM -0800, Guido van Rossum wrote:<br>
<span class="">> If I had had the right foresight, I would have made it an error to<br>
> terminate a generator with a StopIteration, probably by raising another<br>
> exception chained to the StopIteration (so the traceback shows the place<br>
> where the StopIteration escaped).<br>
><br>
> The question at hand is if we can fix this post-hoc, using clever tricks<br>
> and (of course) a deprecation period.<br>
<br>
</span>Do we need "clever tricks"? In my earlier email, I suggested that if<br>
this needs to be fixed, the best way to introduce a change in<br>
behaviour is with the __future__ mechanism. 3.5 could introduce<br>
<br>
    from __future__ stopiteration_is_an_error<br>
<br>
(in my earlier post, I managed to get the suggested behaviour completely<br>
backwards) and then 3.6 could raise a warning and 3.7 could make it<br>
<span class="">the default behaviour.<br></span></blockquote><div><br></div><div>Sure. (Though IMO __future__ itself is a clever hack.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
We're still breaking backwards compatibility, but at least we're doing<br>
</span>it cleanly, without clever and/or ugly hacks. There will be a transition<br>
<span class="im HOEnZb">period during which people can choose to keep the old behaviour or the<br>
new, and then we transition to the new behaviour.</span><br></blockquote></div><br></div><div class="gmail_extra">We'd still need to specify the eventual behavior. I propose the following as a strawman (after the deprecation period is finished and the __future__ import is no longer needed):<br><br></div><div class="gmail_extra">- If a StopIteration is about to bubble out of a generator frame, it is replaced with some other exception (maybe RuntimeError, maybe a new custom Exception subclass, but *not* deriving from StopIteration) which causes the next() call (which invoked the generator) to fail, passing that exception out. From then on it's just like any old exception.<br><br></div><div class="gmail_extra">During the transition, we check if the generator was defined in the scope of the __future__, and if so, we do the the same thing; otherwise, we issue a warning and let the StopIteration bubble out, eventually terminating some loop or generator expression.<br><br></div><div class="gmail_extra">It would be nice if, when the warning is made fatal (e.g. through the -W flag), the exception raised was the same one mentioned above (i.e. RuntimeError or a custom subclass -- I don't care much about this detail).<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>