# [Python-Dev] Half-baked proposal: * (and **?) in assignments

Gareth McCaughan Gareth.McCaughan@pobox.com
Sat, 23 Nov 2002 02:34:19 +0000

```Since

def f(a,b,*c): ...
f(1,2,3,4,5)

does (in effect) a=1, b=2, c=(3,4,5), I suggest that

a,b,*c = 1,2,3,4,5

should do a=1, b=2, c=(3,4,5) too. Likewise,

a,b,c,d,e = 1,2,*(3,4,5)

should be parallel to

def f(a,b,c,d,e): ...
f(1,2,*(3,4,5))

I shall refrain from suggesting that the following
should "work":

a,b,c = 1,**{'b':2,'c':3}
a,**d = (a=1, b=2, c=3)
a,b,c = (b=2, c=3, a=1)

though actually it's an amusing thought, and I wouldn't
complain if they did. The second of them (in the special
case where the LHS is just "**d") would provide an alternative
to Just van Rossum's proposal to overload the dict constructor.
(The two aren't exclusive.) Note that the parens would be
necessary, to avoid ambiguity with "a=b=c=0".

The motivating principle is that parameter passing is,
or should be, just like assignment[1], so what works in
one context should work in the other. I've moderately
often actually wanted the a,b,*c=... notation, too,
usually when using split() on strings containing an
unknown number of fields; the most concise alternative
goes like

a,b,c = (line.split()+[None])[:3]

which both looks and feels ugly.

Of course, you can't take "parameter passing is just like
assignment" too seriously here, because

x = 1,2,3
a,b,c = x

works, whereas

def f(x): ...
def g(a,b,c): ...
f(1,2,3)
g(x)

doesn't. Still, the analogy is (to me) quite a compelling one.

Am I nuts?

[1] This principle matters more in languages like C++ and Eiffel
where parameter passing and assignment can both cause funny
(and potentially user-defined) copying operations to happen,
not just slinging references.

--
g

```