[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 backwards > incompatibility) that parsing *args this way would be bad? . . . > In fact, with the help of the folks from this list, I did: > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302325
* 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 nicely". * 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 solution. Raymond Hettinger "Not everything that can be done, should be done." -- http://mail.python.org/mailman/listinfo/python-list
