itertools.izip brokeness

[Raymond Hettinger]

rurpy at yahoo.com wrote:
> izip's uses can be partitioned two ways:
> 1. All iterables have equal lengths
> 2. Iterables have different lengths.
>
> Case 1 is no problem obviously.
> In Case 2 there are two sub-cases:
>
> 2a. You don't care what values occur in the other iterators
>   after then end of the shortest.
> 2b. You do care.
>
> In my experience 1 and 2b are the cases I encounter the most.
> Seldom do I need case 2a.  That is, when I can have iterators
> of unequal length, usually I want to do *something* with the
> extra items in the longer iterators.  Seldom do I want to just
> ignore them.

That is a reasonable use case that is not supported by zip() or izip()
as currently implemented.



> The whole point of using izip is to make the code shorter,
> more concise, and easier to write and understand.

That should be the point of using anything in Python.  The specific
goal for izip() was for an iterator version of zip().  Unfortunately,
neither tool fits your problem.  At the root of it is the iterator
protocol not having an unget() method for pushing back unused elements
of the data stream.



> This should be pointed out in the docs,

I'll add a note to the docs.


> However, it would be better if izip could be made useful
> fot case 2b situations.  Or maybe, an izip2 (or something)
> added.

Feel free to submit a feature request to the SF tracker (surprisingly,
this behavior has not been previously reported, nor have there any
related feature requests, nor was the use case contemplated in the PEP
discussions: http://www.python.org/peps/pep-0201 ).



Raymond Hettinger