> Hmm - the interaction of "a=b" style args & *-ed args is a bit > counter-intuitive, particularly as the "a=b" args syntatically have to > come before the *-ed args: > > >>> def f(a,b,c,d): > ... return a,b,c,d > ... > >>> f(1,c=3,*(2,4)) > Traceback (most recent call last): > File "<stdin>", line 1, in ? > TypeError: keyword parameter 'c' redefined in call to f() > >>> f(1,b=3,*(2,4)) > Traceback (most recent call last): > File "<stdin>", line 1, in ? > TypeError: keyword parameter 'b' redefined in call to f() > >>> f(1,d=4,*(2,3)) > (1, 2, 3, 4) > > I humbly submit that This Is Wrong. I haven't seen anybody complain > about it, which suggests to me that noone is using this combination, > and I propose either: > > 1) banning it > 2) demanding that the *-ed arg precede the "a=b" args Interesting. The *-ed arg cannot precede the a=b args currently, but I agree that it would have made more sense to do it that way. I'm not sure that it's worth allowing the combination of kw args and *tuple, but I'l also not sure that it *isn't* worth it. > Of course, if noone is using this "feature", then maybe this dusty > little corner of the language should be left undisturbed. I think it may be best to leave it alone. > And I haven't even thought about default arguments yet... That's unrelated. --Guido van Rossum (home page: http://www.python.org/~guido/)
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