[Python-ideas] PEP for issue2292, "Missing *-unpacking generalizations"

Guido van Rossum guido at python.org
Mon Jul 15 19:39:42 CEST 2013


On Mon, Jul 15, 2013 at 3:40 AM, Oscar Benjamin
<oscar.j.benjamin at 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)


More information about the Python-ideas mailing list