[Python-Dev] PEP 201, zip() builtin

[Guido van Rossum]

> bwarsaw at beopen.com (Barry A. Warsaw):
> >      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.

Greg Ewing <greg at cosc.canterbury.ac.nz> replies:
> Well, in that case I think the BDFL has just shot this
> proposal in the foot as far as being a serious solution
> to the parallel for loop problem.
> 
> I was willing to live with the idea of using zip() instead
> of having a proper parallel iteration syntax, as long as
> it was implemented lazily. But now it seems I'll have to
> use another ugly x-named function all over the place.

Who says all over the place?  As far as I can tell, lock-step
iteration (let's not call it "parallel") is a fairly uncommon
operation -- but just common enough that people have been arguing for
some kind of support for it.

The proposed implementation will be blindingly fast -- zip() could
approximate the existing range() function in speed.  There are a few
well-known cases where xrange() is to be preferred over range(), but
in *most* cases, I claim, range() performs well enough.  Note that I'm
not saying that range() is faster than xrange() -- I am saying that it
is *fast enough* for typical usage.

I claim the same for zip().  We'll have a C implementation of zip() in
the 2.0b1 release (expect it late August); please hold back your
judgement until then.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)