defining the behavior of zip(it, it) (WAS: Converting a flat list...)

[rhettinger at gmail.com]

>  > ii. The other problem is easier to explain by example.
>  > Let it=iter([1,2,3,4]).
>  > What is the result of zip(*[it]*2)?
>  > The current answer is: [(1,2),(3,4)],
>  > but it is impossible to determine this from the docs,
>  > which would allow [(1,3),(2,4)] instead (or indeed
>  > other possibilities).
>  > """
>  > IMO left->right is useful enough to warrant making it defined
>  > behaviour
>
> And in fact, it is defined behavior for itertools.izip() [1].
>
> I don't see why it's such a big deal to make it defined behavior for
> zip() too.

IIRC, this was discussednd rejected in an SF bug report.  It should not
be a defined behavior for severals reasons:

* It is not communicative to anyone reading the code that zip(it, it)
is creating a sequence of the form (it0, it1), (it2, it3), . . .   IOW,
it conflicts with Python's style of plain-speaking.
* It is too clever by far -- much more of a trick than a technique.
* It is bug-prone -- zip(x,x) behaves differently when x is a sequence
and when x is an iterator (because of restartability).  Don't leave
landmines for your code maintainers.
* The design spirit of zip() and related functions is from the world of
functional programming where a key virtue is avoidance of side-effects.
 Writing zip(it, it) is exploiting a side-effect of the implementation
and its interaction with iterator inputs.  The real spirit of zip() is
having multiple sequences translated to grouped sequences out -- the
order of application (and order of retrieving inputs) should be
irrelevant.
* Currently, a full understanding of zip() can be had by remembering
that it maps zip(a, b) to (a0, b0), (a1, b1), . . . .  That is simple
to learn and easily remembered. In contrast, it introduces unnecessary
complexity to tighten the definition to also include the order of
application to cover the special case of zip being used for windowing.
IOW, making this a defined behavior results in making the language
harder to learn and remember.

Overall, I think anyone using zip(it,it) is living in a state of sin,
drawn to the tempations of one-liners and premature optimization.  They
are forsaking obvious code in favor of screwy special cases.  The
behavior has been left undefined for a reason.


Raymond Hettinger