[Python-3000] Using *a for packing in lists and other places
Guido van Rossum
guido at python.org
Sun Mar 16 16:00:36 CET 2008
On Sat, Mar 15, 2008 at 6:01 PM, Thomas Wouters <thomas at python.org> wrote:
> On Sat, Mar 15, 2008 at 3:21 PM, Guido van Rossum <guido at python.org> wrote:
> > This post does point out an inconistency in Thomas's patch:
> > def f():
> > yield 1, 2, 3
> > Yields a single three-tuple.
> > But
> > def f():
> > yield *[1, 2], 3
> > Yields three separate values.
> Uhm, what? It doesn't, and it shouldn't, and I'm not sure what makes you
> think it does.
Sorry, I misread the output. I *expected* it to do this based on an
incomplete understanding of what you've implemented. Since I made this
mistake, I expect others will too; I think *something* needs to
A strict proposal would be to change the syntax of yield so that it
only accepts a single expression, optionally prefixed with a '*'. This
yield 1, 2, 3
illegal -- you'd have to rewrite this as
yield (1, 2, 3)
That's a minor inconvenience and can be taken care of by 2to3 easily.
A less strict proposal would be to allow
yield expr, expr, ...
yield *expr, expr, ...
yield expr, *expr, ... # etc.
While we discussed this over drinks last night, it also made me think
about the end-case of *expr in other contexts. We have the following
series of similar assignments:
a, b, *c = x
b, *c = x
*c = x # disallowed
*c, = x # use this instead
This is defensible by analogy to the following:
a, b, c = x # unpack 3-tuple
b, c = x # unpack 2-tuple
c = x # not a tuple unpacking!
c, = x # must unpack 1-tuple this way
However while in the latter case "c = x" there is no syntactic hint
that a tuple might be intended, one could say that in "*c = x" the
star is plenty enough of a hint. (The semantics would be clear by
taking the limit of the first series of examples; "*c = x" is
equivalent to "c = list(x)".)
I don't think I actually *like* this; it would make "yield *expr" even
more of an exception, and it doesn't have any attractive use cases.
However I believe that the analogy between regular tuple unpacking and
extended tuple unpacking is a relatively weak argument to forbid "*c =
x", and I expect that this gray area is likely to cause users to trip
up in their understanding of this proposed new syntax; especially if
they think too hard about it. :)
Two other comments on Thomas's proposal:
(a) *if* we're going to do this, it should also be done for function
calls (though not for function defs). I'd like all of these to be
legal (and their interpretation is obvious):
f(a, b, *x, k=val)
f(a, *x, b, k=val)
f(*x, a, b, k=val, **kw=stuff)
(b) I noticed that the following are equivalent:
I think the latter should not be allowed; the * should be present at
the same level as the commas to which it belongs. (This may be an
issue for the existing extended tuple unpacking as well?)
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000