On 2016-10-19 12:21, Nathaniel Smith wrote:
>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.
To me this makes the change too hard to swallow. Although the issues
you describe are real, it doesn't seem worth it to me to change the
entire semantics of for loops just for these cases. There are lots of
for loops that are not async and/or do not rely on resource cleanup.
This will change how all of them work, just to fix something that
sometimes is a problem for some resource-wrapping iterators.
Moreover, even when the iterator does wrap a resource, sometimes I want
to be able to stop and resume iteration. It's not uncommon, for
instance, to have code using the csv module that reads some rows, pauses
to make a decision (e.g., to parse differently depending what header
columns are present, or skip some number of rows), and then resumes.
This would increase the burden of updating code to adapt to the new
breakage (since in this case the programmer would likely have to, or at
least want to, think about what is going on rather than just blindly
wrapping everything with protect() ).
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
