Half-baked proposal: * (and **?) in assignments
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
participants (10)
-
Brett Cannon
-
Brian Quinlan
-
Fredrik Lundh
-
Gareth McCaughan
-
martin@v.loewis.de
-
Nathan Clegg
-
Patrick K. O'Brien
-
Raymond Hettinger
-
Skip Montanaro
-
Steve Holden