[issue25014] Add contextlib.itercm()

2015-09-08 Thread Ezio Melotti
Ezio Melotti added the comment: > Having spent a few days pondering this after Ezio first mentioned the > concept to me on IRC, I'm rejecting this on the basis of "not every 3 > line function needs to be in the standard library". When I first mentioned this to Nick on IRC, the implementation

[issue25014] Add contextlib.itercm()

2015-09-07 Thread Barry A. Warsaw
Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue25014] Add contextlib.itercm()

2015-09-06 Thread Antoine Pitrou
Antoine Pitrou added the comment: I don't think I like this idea. It's not really a common use case (I've never wished I had itercm()) and it will make it possible to write slightly obscure code. Of course you can already write obscure code using itertools :-) --

[issue25014] Add contextlib.itercm()

2015-09-06 Thread Raymond Hettinger
Raymond Hettinger added the comment: > I don't think I like this idea. It's not really a common use > case (I've never wished I had itercm()) and it will make it > possible to write slightly obscure code. Of course you can > already write obscure code using itertools :-) I concur with Antoine

[issue25014] Add contextlib.itercm()

2015-09-06 Thread Nick Coghlan
Nick Coghlan added the comment: __exit__ will still get invoked even if the generator is never exhausted: >>> def itercm(cm): ... with cm: ... yield from cm ... >>> class TestCM: ... def __iter__(self): ... yield 6 ... yield 9 ... yield 42 ... def

[issue25014] Add contextlib.itercm()

2015-09-06 Thread Martin Panter
Martin Panter added the comment: 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”

[issue25014] Add contextlib.itercm()

2015-09-06 Thread Ezio Melotti
Ezio Melotti added the comment: FTR one of the reason that led me to itercm() is: with open(fname) as f: transformed = (transform(line) for line in f) filtered = (line for line in lines if filter(line)) # ... Now filtered must be completely consumed before leaving the body of the

[issue25014] Add contextlib.itercm()

2015-09-06 Thread Ezio Melotti
New submission from Ezio Melotti: Add an itercm() function that receives an iterable that supports the context manager protocol (e.g. files) and calls enter/exit without having to use the with statement explicitly. The implementation is pretty straightforward (unless I'm missing something):

[issue25014] Add contextlib.itercm()

2015-09-06 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: What if the last line will be never read? We had bugs with resource leaks in generators, and I'm not sure that all such bugs were fixed. -- nosy: +pitrou, serhiy.storchaka ___ Python tracker

[issue25014] Add contextlib.itercm()

2015-09-06 Thread Ezio Melotti
Ezio Melotti added the comment: If you are talking about generators that never get exhausted, the fact that the __exit__ is never invoked is expected and something that developers should take into account while using itercm(). I'm not aware of other generators-related issues that might cause