<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 October 2017 at 21:46, Serhiy Storchaka <span dir="ltr"><<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">17.10.17 14:10, Nick Coghlan пише:<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. It's pretty easy to write "for x in y in y" when you really meant to write "for x in y", and if "y" is an infinite iterator, the "y in y" part will become an unbreakable infinite loop when executed instead of the breakable one you intended (especially annoying if it means you have to discard and restart a REPL session due to it, and that's exactly where that kind of typo is going to be easiest to make)<br>
</blockquote>
<br></span>
I think it is better to left this on linters. I never encountered this mistake and doubt it is common. In any case the first execution of this code will expose the mistake.<span class=""><br></span></blockquote><div><br></div><div>People don't run linters at the REPL, and it's at the REPL where accidentally getting an unbreakable infinite loop is most annoying.</div><div><br></div><div>Keep in mind we're not talking about a regular loop you can break out of with Ctrl-C here - we're talking about a tight loop inside the interpreter internals that leads to having to kill the whole host process just to get out of it.</div><div> <span class=""></span><br><span class="">
</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Containment testing already has a dedicated protocol so containers can implement optimised containment tests, which means it's also trivial for an infinite iterator to intercept and explicitly disallow containment checks if it chooses to do so<br>
</blockquote>
<br></span>
But this has non-zero maintaining cost. As the one who made many changes in itertools.c I don't like the idea of increasing its complexity for optimizing a pretty rare case.<br></blockquote><div><br></div><div>It's not an optimisation, it's a UX improvement for the interactive prompt. The maintenance burden should be low, as it's highly unlikely we'd ever need to change this behaviour again in the future (I do think deprecating the success case would be more trouble than it would be worth though).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

And note that the comparison can have side effect. You can implement the optimization of `x in count()` only for the limited set of builtin types. For example `x in range()` is optimized only for exact int and bool. You can't guarantee the finite time for cycle() and repeat() either since they can emit values of arbitrary types, with arbitrary __eq__.</blockquote><div><br></div>We're not trying to guarantee finite execution time in general, we're just making it more likely that either Ctrl-C works, or else you don't get stuck in an infinite loop in the first place.<br></div><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>