On 19 October 2016 at 20:21, Nathaniel Smith
On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore
wrote: On 19 October 2016 at 19:13, Chris Angelico
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