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

[bonono at gmail.com]

r... at yahoo.com wrote:
> > * 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.
>
> Err thanks for the advice, but they are *my* code maintainers and
> I am the best judge of what constitutes a landmine.
:-)

>
> > * 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.
>
> I'm not sure what to say when people start talking about "spirit"
> when making technical decisions.
I am with raymond on this one though. It is not really about spirit but
the definition of zip(). How it would interact with "it", whatever it
is really has nothing to do with the functionality of zip(), and there
is no technically reason why it would do it one way or another. zip()
only gurantee zip(a,b) to be [(a0,b0), (a1,b1) ...], no more, no less.

>
> > * 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.
>
> I don't see how defining zip()'s behavior more precisely, interfers
> at all with this understanding.
See above.

>
> > 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.
>
> I really don't understand this point of view.  It is exactly what
> I was just complaining about in a different thread.  Every one
> your reasons (except the last, which is very weak anyway) is
> based on how you think someone may use zip if you define
> fully what it does.
>
> Why do you feel compelled to tell me how I should or
> shouldn't write my code?!
>
> It is this attitude of "we know what is best for you, child"
> that really pisses me off about Python sometimes.  Please
> make language decisions based on technical considerations
> and not how you want me to use the language.  Believe it
> or not, I can make those decisions on my own.

That is so central to python though ;-)

 But I think it is implemented in a very interesting way, depends on
some magical thing in the head of the creator.

Unlike a language like Haskell where you must ahere or else your
program won't run(Haskell compiler writers consider it a BUG in the
language if you find a trick to corner it), Python allows you to do a
lot of tricky things yet have lots of interesting idioms telling you
not to.

But that to me is one thing I like about Python, I can ignore the idiom
and do my work.