# [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, 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?

 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

```