On Mon, Jul 15, 2013 at 3:40 AM, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
I definitely like the general colour of this shed but would probably repaint one side of it: while unpacking can create tuples, sets, lists and dicts there's no way to create an iterator. I would like it if the unpacking syntax could somehow be used for iterators. For example:
first_line = next(inputfile) # inspect first_line for line in chain([first_line], inputfile): # process line
could be rewritten as
first_line = next(inputfile): for line in first_line, *inputfile: pass
without reading the whole file into memory. Using the tuple syntax is probably confusing but it would be great if there were some way to spell this and get an iterator instead of a concrete collection.
I think this is going down a slippery slope that could jeopardize the whole PEP, which is nice and non-controversial so far. The problem is that "tuples" (more precisely, things separated by commas) are already overloaded to the point where both the parser and most human readers are strained to the max to tell the different cases apart. For example, this definitely creates a tuple: a = 1, 2, 3 Now consider this: b = 2, 3 a = 1, *b Why would that not create the same tuple? In general, all other uses of *x and **xx create concrete objects (there is nothing "iterator-like" about an argument list). I think overloading these same operators to return iterators in some contexts would just cause too much confusion, and discontinuities in edge cases, making it harder to reason about the equivalency of different ways to write the same thing. (The use of *x in a generator expression is an exception -- a generator expression is *already* an iterator, so here there is no confusion.)
Also this may be outside the scope of this PEP but since unpacking is likely to be overhauled I'd like to put forward a previous suggestion by Greg Ewing that there be a way to unpack some items from an iterator without consuming the whole thing e.g.:
a, ... = iterable
Definitely a different PEP. -- --Guido van Rossum (python.org/~guido)