itertools.izip brokeness

[Paul Rubin]

"Diez B. Roggisch" <deets at nospam.web.de> 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?