[Gareth] > 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 > [similar suggestions] > > 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. > The advantage, of course, is the explicit nature. > 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? > Not nuts, but perhaps striving too hard for a false generality. I would support this suggestion if it made the assignment code simpler, but if it complicates it then my feeling is YAGNI. It's a nice parallel, but n ot one that meets any crying need, IMO. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com -----------------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4