Guido van Rossum <guido@python.org> writes:
> > How about dumping the CALL_FUNCTION* opcodes, and replacing them with
> > two non-argumented opcodes, called for the sake of argument NCALL_FUNC
> > and NCALL_FUNC_KW.
> >
> > NCALL_FUNC would pop a function object and a tuple off the stack and
> > apply the function to the tuple.
> >
> > NCALL_FUNC_KW would do the same, then pop a dictionary and then do
> > the moral equivalent of f(*args,**kw).
>
> No, this is a bad idea. Long, long ago, all calls requird building a
> tuple for the arguments first. This tuple creation turned out to be a
> major bottleneck. That's why the current call opcode exists.
Yes, I realize this now. I made my suggestion having not actually
looked at the code or thought about it very much.
I still think there is (or at least might be) value in rewriting the
code for the more complex cases, and moving the dictionary creation
out of the implementation of CALL_FUNCTION.
Then the following could be made essentially equivalent:
f(a,b,c=d,e=f)
dict = {c:d,e:f}
f(a,b,**dict)
(modulo evaluation order).
(I've made some changes to get BUILD_MAP using it's argument and
construct literal dictionaries using it, which I'll whack up onto sf
just as soon as I get round to it... ah, it's at
https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=102227&group_id=5470
).
Cheers,
M.
--
Those who have deviant punctuation desires should take care of their
own perverted needs. -- 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