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 <h...@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
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
