[Python-ideas] Deterministic iterator cleanup

[Brendan Barnwell]

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