[Python-Dev] Re: a serious threat to 2.3's speed?
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
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