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

[Gareth McCaughan]

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