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

[Phillip J. Eby]

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.  :)