This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients
Date 2005-02-17.01:10:54
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=80475

The first sentence becomes even less clear with the "in the
same order" wording.  

The note about truncating to the shortest sequence length is
essential and should not have been dropped.  

The py2.4 change note is in a standard form
(\versionchanged{} following the explanation of current
behavior) and should not have been altered.

The part that addresses the OP's concern is too specific to
the his one example and is unclear unless you know about
that example.  The wording is discomforting, doesn't add new
information, and is somewhat not obvious in its meaning.

I suggest simply changing "sequence" to "iterable".

There is no sense in stating that the order of combination
is undefined.  It doesn't help with the OP's original desire
to be able to predict the outcome of the example.  However,
it does have the negative effect of making a person question
whether they've understood the preceding description of what
actually zip() does do.

zip() is about lockstep iteration and the docs should serve
those users as straight-forwardly as possible.  The OP's
issue on the other hand only comes up when trying funky
iterator magic -- adding a sentence about undefined ordering
doesn't help one bit.

There is a lesson in all this.  These tools were borrowed
from the world of functional programming which is all about
programming that is free of side-effects.  The OP's problem
should be left as a code smell indicating a misuse of
functionals.

History
Date User Action Args
2007-08-23 14:29:32adminlinkissue1121416 messages
2007-08-23 14:29:32admincreate