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. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
