[Python-3000] Using *a for packing in lists and other places

[Guido van Rossum]

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
change.

A strict proposal would be to change the syntax of yield so that it
only accepts a single expression, optionally prefixed with a '*'. This
would render

  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

and

  yield expr, expr, ...

but not

  yield *expr, expr, ...

nor

  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:

  a, *b
  a, (*b)

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/)