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

[rurpy at yahoo.com]

bonono at gmail.com wrote:
> 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.

I don't have a problem with that.  That is a reason based on the
intrinsic behavior that zip() should have, without regard to how
someone might or might not use it.  In contrast, Raymond's
arguments were based on how zip() might be used if it were
more precisely defined.  I did not take any position on how zips
behavior should be defined, my only beef was the arguments
used in support of not defining it.

I am not sure if I  looked at the same SF Bug that Raymond refered
to, but the submitter also was not asking for a change of behavior,
only either documenting how zip() behaves, or documenting it as
undefined.  Seemed like a resonable request to me.

> > > * 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.

Sorry, I still don't see that defining the order in which the argument
elements are processed, makes zip() harder to understand in any
real material sense.

> > > 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.

Haskell is high on the queue to be learned (along with Ocaml) but
I would not consider either as general purpose prgramming languages
in the sense of C, Java, or (almost) Python.  (But maybe I am wrong)
So I would not be surprised to find them to be built around, and
enforce, a very specific programming style.

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

Well, I do too mostly.  On rereading my post, it seems I overreacted
a bit.  But the attitude I complained about I think is real, and has
led to more serious flaws like the missing if-then-else expression,
something I use in virtually every piece of code I write, and which
increases readability.  (Well, ok that is not the end of the world
either but it's lack is irritating as hell, and yes, I know that it is
now back in favor.)