On 19 October 2016 at 20:21, Nathaniel Smith <n...@pobox.com> wrote: > On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >> On 19 October 2016 at 19:13, Chris Angelico <ros...@gmail.com> wrote: >>> Now it *won't* correctly call the end-of-iteration function, because >>> there's no 'for' loop. This is going to either (a) require that EVERY >>> consumer of an iterator follow this new protocol, or (b) introduce a >>> ton of edge cases. >> >> Also, unless I'm misunderstanding the proposal, there's a fairly major >> compatibility break. At present we have: >> >>>>> lst = [1,2,3,4] >>>>> it = iter(lst) >>>>> for i in it: >> ... if i == 2: break >> >>>>> for i in it: >> ... print(i) >> 3 >> 4 >>>>> >> >> With the proposed behaviour, if I understand it, "it" would be closed >> after the first loop, so resuming "it" for the second loop wouldn't >> work. Am I right in that? I know there's a proposed itertools function >> to bring back the old behaviour, but it's still a compatibility break. >> And code like this, that partially consumes an iterator, is not >> uncommon. > > Right -- did you reach the "transition plan" section? (I know it's > wayyy down there.) The proposal is to hide this behind a __future__ at > first + a mechanism during the transition period to catch code that > depends on the old behavior and issue deprecation warnings. But it is > a compatibility break, yes.
I missed that you propose phasing this in, but it doesn't really alter much, I think the current behaviour is valuable and common, and I'm -1 on breaking it. It's just too much of a fundamental change to how loops and iterators interact for me to be comfortable with it - particularly as it's only needed for a very specific use case (none of my programs ever use async - why should I have to rewrite my loops with a clumsy extra call just to cater for a problem that only occurs in async code?) IMO, and I'm sorry if this is controversial, there's a *lot* of new language complexity that's been introduced for the async use case, and it's only the fact that it can be pretty much ignored by people who don't need or use async features that makes it acceptable (the "you don't pay for what you don't use" principle). The problem with this proposal is that it doesn't conform to that principle - it has a direct, negative impact on users who have no interest in async. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
