<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 October 2017 at 19:19, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">17.10.17 09:42, Nick Coghlan пише:<span class="gmail-"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 17 October 2017 at 16:32, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> <mailto:<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>>> wrote:<br>
<br>
    So this sounds like a reasonable API UX improvement to me, but you'd<br>
    need to ensure that you don't inadvertently change the external<br>
    behaviour of *successful* containment tests.<br>
<br>
<br>
I should also note that there's another option here beyond just returning "False": it would also be reasonable to raise an exception like "RuntimeError('Attempted negative containment check on infinite iterator')".<br>
</blockquote>
<br></span>
What about other operations with infinite iterators? min(count()), max(count()), all(count(1))? Do you want to implement special cases for all of them?</blockquote><div><br></div>No, as folks expect those to iterate without the opportunity to break out, and are hence more careful with them when infinite iterators are part of their application. We also don't have any existing protocols we could use to intercept them, even if we decided we *did* want to do so.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The distinction I see with "x in y" is:</div><div class="gmail_quote"><br></div>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 clear="all"><div class="gmail_quote">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></div><div class="gmail_quote"><br></div><div class="gmail_quote">So the problem is more likely to be encountered due to "x in y" appearing in both the containment test syntax and as part of the iteration syntax, *and* it's straightforward to do something about it because the __contains__ hook already exists. Those two points together are enough for me to say "Sure, it makes sense to replace the current behaviour with something more user friendly".</div><div class="gmail_quote"><br></div><div class="gmail_quote">If either of them was false, then I'd say "No, that's not worth the hassle of changing anything".<br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Nick.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>