[pypy-dev] RFC: draft idea for making for loops automatically close iterators

[Alex S.]

That’s a good point, as it means there’s probably no safe & portable way to ensure that kind of stuff. «Trying to collect» something doesn’t really fall short of an actual collection, I believe (finding referers is hard).
But I believe iterclose() defined appropriately on derived iterators would solve that?..
> 21 окт. 2016 г., в 17:13, hubo <hubo at jiedaibao.com> написал(а):
> 
> Well I'm really shocked to find out what I thought was a "automatic close" is really the ref-couting GC of CPython, means that a lot of my code breaks in PyPy...
> It really becomes a big problem after iterators heavily used in Python nowadays. Some builtin functions like zip, map, filter return iterators in Python 3 instead of lists in Python 2, means invisible bugs for code ported from Python 2, like zip(my_generator(), my_other_generator()) may leave the iterators open if exited from a for loop. Even in Python 2, functions in itertools may create these bugs.
> In CPython, this kind of code will work because of the ref-counting GC, so it is not obvious in CPython, but they break in PyPy.
>  
> I'm wondering since a ref-counting GC implemention is not possible for PyPy, is it possible to hack on the for loop to make it "try to" collect the generator? That may really save a lot of lives. If the generator is still referenced after the for loop, it may be the programmer's fault for not calling close(), but loop through a returned value is something different - sometimes you even do not know if it is a generator.
>  
> 2016-10-21 
> hubo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20161021/b2ca0bc6/attachment.html>