bonono

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.


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.

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.


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.

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.

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

bonono

I have the same feeling too, which I coin the "personality" of the
group and the language in general :-)

Yes, I've often thought I'd like to study sociology, using the internet
as a laboratory.

I know that I'm tilting at windmills, but I optimistic enough to hope
that maybe some small change will result.
The problem is that Python is really a very good language which
makes its flaws stand out all the more.

steven bethard

[snip arguments about how confusing zip(it, it) is]

Then why document itertools.izip() as it is? The documentation there is
explicit enough to know that izip(it, it) will work as intended. Should
we make the documentation there less explicit to discourage people from
using the izip(it, it) idiom?

STeVe

bonono

That to me is also a slip but does demonstrate that it is easy for
people to be drawn into this "sin", including those people responsible
for the formal documentation, or those behind the implementation.

But technically speaking, you are still referring to the implementation
detail of izip(), not the functionality of izip().

I do now agree with another poster that the documentation of both zip
and izip should state clear that the order of picking from which
iterable is undefined or can be changed from implementation to
implementation, to avoid this kind of temptation.

fredrik lundh

you obviously need to learn more Python idioms. Python works better
if you use it to write Python code; not when you mechanically translate
stuff written in other languages to Python.

the thing that's in favour is "then-if-else", not "if-then-else".
</F>

bonono

there it comes :-)

antoon pardon

Op 2005-11-23, Fredrik Lundh schreef <fredrik@pythonware.com>:


What does this mean?

It could mean that python works better with those concepts that are
already implemented in python. That seems obvious, but isn't
an argument for or against implementing a particular language
feature.

It could also mean that some language feature will never work well
in python even when implemented. Are you arguing that a conditional
expression is such a feature?

Well I don't know about the previous poster, but I'm mostly interesseted
in a conditional expression. Whether it is "then-if-else" or "if-then-else"
seems less important to me.

--
Antoon Pardon

dave hansen

ISTM that one would use itertools.izip in order to get some
functionality not available from zip. Perhaps this is one of those
bits of functionality.

But I admit, I'm not all that familiar with itertools...

In any case, the solution seems obvious: if you want the guarantee,
use the tool that provides it.

Regards,
-=Dave

--
Change is inevitable, progress is not.