[Python-Dev] Re: a serious threat to 2.3's speed? (original) (raw)

Phillip J. Eby pje at telecommunity.com
Thu Dec 11 12:06:17 EST 2003

At 04:35 PM 12/11/03 +0000, Duncan Booth wrote:

The way I was planning to do function calls (and had partially implemented it), was to have an IPyCallable interface, and a set of classes that implement that interface.

The interface includes methods: PyObject call(); PyObject call(PyObject arg1); PyObject call(PyObject arg1, PyObject arg2); PyObject call(PyObject arg1, PyObject arg2, PyObject arg3); PyObject call(PyObject[] args); PyObject call(PyObject[] args, PyDict keywordArgs); Concrete classes exist for functions and for bound methods taking 0, 1, 2, 3 or more arguments. The constructor for a function object takes a delegate, a list of argument names and a list of defaults.

Hm. We could steal this exact same idea for use in CPython, although it'd be tedious to implement. The current tp_call would cover the last two cases shown, but adding a tp_call0 through tp_call3 or so might speed up a lot of function calls. Specialized bytecodes for these calls would have very short implementations. The tp_call_N slots could have default implementations in 'object' that delegate back to the regular tp_call, so that end-user types wouldn't need to reimplement them.

Hm. Actually, this'd be really tedious to implement right, because of all the custom bound method types needed, and the C multiple wrappers for call methods written in Python. OTOH, this might be an "opportunity" to write generic leftcurry and rightcurry functions, and use rightcurry for default arguments...

Bleah. What this really seems to want is to generate a new type on the fly, that is precisely coded to do the necessary left and right currying as part of C-level code invocation. A JIT, in other words.

Ah well, it sounded cool at first. :)

More information about the Python-Dev mailing list