Michael Hudson <mwh21@cam.ac.uk> writes:
> Guido van Rossum <guido@python.org> writes:
>
> Then the following could be made essentially equivalent:
>
> f(a,b,c=d,e=f)
>
> dict = {c:d,e:f}
> f(a,b,**dict)
... except when you have stuff like
f(a,b=c,**kw)
Gruntle. Maybe Python function calls are just complicated! (Has
anyone looked at bytecodehacks.xapply? - and that doesn't even handle
*-ed and **-ed arguments...).
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
Of course, if noone is using this "feature", then maybe this dusty
little corner of the language should be left undisturbed.
And I haven't even thought about default arguments yet...
about-to-make-an-opcode-called-BODGE_KEYWORD_ARGUMENTS-ly y'rs
M.
--
nonono, while we're making wild conjectures about the behavior
of completely irrelevant tasks, we must not also make serious
mistakes, or the data might suddenly become statistically valid.
-- Erik Naggum, comp.lang.lisp
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