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

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