[Python-Dev] PEP 201, zip() builtin
Barry A. Warsaw
bwarsaw@beopen.com
Fri, 28 Jul 2000 01:50:57 -0400 (EDT)
>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> Could we please change "Parallel" to, e.g., "Lockstep"
TP> throughout? Greg Wilson correctly pointed out that "parallel"
TP> in the context of loops means something very different to the
TP> scientific branch of the Python community. Easier to fix this
TP> now that after it's spread to the docs.
I know, and I guess I never came up with anything better which is why
I didn't change it. "Lockstep" it is.
TP> Just as you realized how inappropriate "parallel" was right
TP> here <wink>.
Heh.
>> # find the length of the shortest sequence shortest =
>> min(*map(len, args))
TP> Clearer as
>> shortest = min(map(len, args))
A little experimentation leftover. Good catch.
TP> However, this implies that all sequences must tell the truth
TP> about their lengths, but the iteration protocol actually
TP> terminates via a sequence raising IndexError. I believe we
TP> want zip to follow the iteration protocol, in effect breaking
TP> out of the outer loop as soon as some s[i] raises IndexError.
TP> This was agreed to by all (incl. the BDFL) in some other
TP> year's debates over this.
Yup, I always intended the C implementation to obey the undocumented
iteration protocol. But it /is/ better if the PEP's implementation
were closer to the eventual C code, so I've swapped in a replacement.
>> prefers zip() due to it's Haskell[2] heritage. See version 1.7
TP> "its", not "it's"
Good catch.
>> - Lazy evaluation. An earlier version of this PEP proposed
>> that zip() return a built-in object that performed lazy
>> evaluation using __getitem__() protocol. This has been
>> strongly rejected by the BDFL in favor of returning a real
>> Python list. If lazy evaluation is desired in the future, the
>> BDFL suggests an xzip() function be added.
TP> Which he'll then fight tooth and nail <wink>.
:)
>> ...
TP> Nice job, Barry! Thank you.
My pleasure!
-Barry