<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Tue, Oct 17, 2017 at 2:46 PM, Serhiy Storchaka </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><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. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Just to note that there is currently nothing that would prevent making `for x in y in z` a syntax error. There is nothing meaningful that it could do, really, because y in z can only return True or False (or raise an Exception or loop infinitely).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">But for an infinite iterable, the right answer may be Maybe ;)</div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<br>
<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>
<br>
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__.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>