Message250027
I had also thought of this kind of function, but I dismissed it because it would either have to rely on garbage collection or an explicit close() call to close the generator in case the iteration is aborted. I think it might need some kind of “with-for” combined statement added to the langauge to be bulletproof.
Considering the second example in your script, “exit is called in case of errors”: What is stopping the interpreter from storing the iterator of the current “for” loop in the top-level frame object? Then the iterator would be referenced by the exception traceback, and prevent garbage collection of its itercm() instance. Hypothetically:
__traceback__ → tb_frame → “for” iterator → itercm() instance
Also, I would tend to put this sort of function in “itertools”, since generators are not context managers by design. |
|
Date |
User |
Action |
Args |
2015-09-06 22:13:10 | martin.panter | set | recipients:
+ martin.panter, rhettinger, ncoghlan, pitrou, ezio.melotti, serhiy.storchaka |
2015-09-06 22:13:10 | martin.panter | set | messageid: <1441577590.9.0.317537102647.issue25014@psf.upfronthosting.co.za> |
2015-09-06 22:13:10 | martin.panter | link | issue25014 messages |
2015-09-06 22:13:10 | martin.panter | create | |
|