Python 3000, zip, *args and iterators

Raymond Hettinger python at
Mon Dec 27 19:11:09 CET 2004

[Steven Bethard]
> What I would prefer is something like:
>  >>> zip(*g(4))
> <iterator object at ...>
>  >>> x, y, z = zip(*g(4))
>  >>> x, y, z
> (<iterator object at ...>, <iterator object at ..., <iterator object
at ...)
. . .
> So I guess my real question is, should I expect Python 3000 to play
> nicely with *args and iterators?  Are there reasons (besides
> incompatibility) that parsing *args this way would be bad?
. . .
> In fact, with the help of the folks from this list, I did:

* The answer to the first question is Yes.  The point of Python 3000 is
building on what was learned and writing a simpler, cleaner language
without the encumbrance of backwards compatibility.

* However, IMHO, the proposed behavior doesn't qualify as "playing

* Your excellent recipe provides a good basis for discussion and it
highlights some of the issues around the proposed behavior:

1:  The current implementation's behavior is easy to learn, easy to
explain, and does what most folks expect (not folks who are pushing the
iterator and *arg protocols to the outer limits).  In contrast, the
proposed recipe is somewhat complex and its implications are not
immediately obvious.  The itertools.tee() component is of extra concern
because it invisibly introduces memory intensive characteristics into
an otherwise lightweight, low-overhead function.

2.  It is instructive to look at Guido's reactions to other *args
proposals.  His receptivity to a,b,*c=it wanes whenever someone then
requests support for a,*b,c=it.  Likewise, he considers zip(*args) as a
transpose function to be an abuse of the *arg protocol.  IOW,
supporting "odd" usages does not bode well for a proposal.

3.  The recipe discussion and newsgroup posting present only toy
examples -- real use cases have not yet emerged.  If some do emerge, I
suspect that each problem will have a better solution (using existing
tools) than the one being proposed.  If so, then adopting the proposal
will have the negative effect of leading folks away from the correct

Raymond Hettinger

"Not everything that can be done, should be done."

More information about the Python-list mailing list