[Python-Dev] Python Call Mechanism

Michael Hudson mwh21@cam.ac.uk
02 Nov 2000 17:00:37 +0000

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:


dict = {c:d,e:f}

(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




  Those who have deviant punctuation desires should take care of their
  own perverted needs.                  -- Erik Naggum, comp.lang.lisp