Possible addition to itertools
One feature that I'd find nice in itertools is access to "universal newlines" behavior. This would make it much easier to extend zipfile and other compression-related code to provide pseudo-files that iterate properly. To try out a simple Python equivalent, look at: http://members.dsl-only.net/~daniels/ilines.html If people think such code would be useful in itertools, I'd be happy to add it as a patch. If not, I'll provide it as a Cookbook recipe or some such. -- -- Scott David Daniels Scott.Daniels@Acm.Org
[Scott David Daniels]
One feature that I'd find nice in itertools is access to "universal newlines" behavior. This would make it much easier to extend zipfile and other compression-related code to provide pseudo-files that iterate properly.
My initial thoughts are: * the functionality is useful * it duplicates some code from fileobject.c * ilines() is not abstracted from the problem domain like other itertools * it meets other criteria for inclusion in itertools: - iterable in, iterable out - does bring the whole input into memory - interacts well with other itertools * unsure whether the needs to be Unicode aware I'm interested to see whether a fan club emerges for this one. Raymond Hettinger
On Jun 21, 2004, at 12:53 PM, Raymond Hettinger wrote:
[Scott David Daniels]
One feature that I'd find nice in itertools is access to "universal newlines" behavior. This would make it much easier to extend zipfile and other compression-related code to provide pseudo-files that iterate properly.
My initial thoughts are:
* the functionality is useful * it duplicates some code from fileobject.c
Which isn't available in pure Python anywhere, and isn't extensible enough to do what he wants to do.
* unsure whether the needs to be Unicode aware
Universal newlines doesn't really make sense in the context of unicode. Unicode would definitely have another implementation, anyway (unicode.splitlines(...)). FWIW, I've wanted to do things like this before.. but I think that the universal newlines support in fileobject should just be refactored so that you can use it without a file object (possibly with a similar API to this). -bob
-----Original Message-----
[Scott David Daniels]
One feature that I'd find nice in itertools is access to "universal newlines" behavior. This would make it much easier to extend zipfile and other compression-related code to provide pseudo-files that iterate properly.
[Raymond]
My initial thoughts are:
* the functionality is useful * it duplicates some code from fileobject.c
Which isn't available in pure Python anywhere, and isn't extensible enough to do what he wants to do.
* unsure whether the needs to be Unicode aware
Universal newlines doesn't really make sense in the context of unicode. Unicode would definitely have another implementation, anyway (unicode.splitlines(...)).
FWIW, I've wanted to do things like this before.. but I think that
[Bob] the
universal newlines support in fileobject should just be refactored so that you can use it without a file object (possibly with a similar API to this).
I would support exposing this as a static function for the file type. Alternately, I could see it going in the string module. Raymond
On Wed, Jun 16, 2004, Scott David Daniels wrote:
One feature that I'd find nice in itertools is access to "universal newlines" behavior. This would make it much easier to extend zipfile and other compression-related code to provide pseudo-files that iterate properly.
That's a great idea, but I don't think it belongs in itertools. If/when we create the semi-mythical text/string package, it should go there. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith, c.l.py
participants (4)
-
Aahz -
Bob Ippolito -
Raymond Hettinger -
Scott David Daniels