"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > No. If you want that, use > > list(iterable) > > Then you have random access. If you _know_ there will be only so much data > needed to "unget", write yourself a buffered iterator like this:
You can't use list(iterable) in general because the iterable may be infinite. > buffered(iterable, size) > > Maybe something like that _could_ go in the itertools. But I'm not really > convinced, as it is too tied to special cases - The usual pushback depth needed is just one item and it would solve various situations like this. The ASPN recipe I cited for detecting an empty iterable shows that such problems come up in more than one place. Note that besides the buffered iterable, there would also have to be a version of izip that pushed unused items back onto its iterables. > and besides that very easily done. Just about everything in itertools is very easily done, so that's not a valid argument against it. > > How about this (untested): > > > > def myzip(iterlist): > > """return zip of smaller and smaller list of iterables as the > > individual iterators run out""" > > If that fits your semantics - of course. But the general zip shouldn't > behave that way. Of course it shouldn't. In another post I suggested a way to extend the general izip, to throw a list of the remaining non-empty iterables once it hit an empty one. Maybe there's some problem with that too, but if so, it's more subtle. Any idea how Haskell would deal with this? -- http://mail.python.org/mailman/listinfo/python-list
