I added a patch to SF: http://python.org/sf/1107887 I would like feedback on whether the approach is desirable. The patch adds a new method type (flags) METH_ARGS that is used in PyMethodDef. METH_ARGS means the min and max # of arguments are specified in the PyMethodDef by adding 2 new fields. This information can be used in ceval to call the method. No tuple packing/unpacking is required since the C stack is used. The benefits are: * faster function calls * simplify function call machinery by removing METH_NOARGS, METH_O, and possibly METH_VARARGS * more introspection info for C functions (ie, min/max arg count) (not implemented) The drawbacks are: * the defn of the MethodDef (# args) is separate from the function defn * potentially more error prone to write C methods??? I've measured between 13-22% speed improvement (debug build on Operton) when doing simple tests like: ./python ./Lib/timeit.py -v 'pow(3, 5)' I think the difference tends to be fairly constant at about .3 usec per loop. Here's a portion of the patch to show the difference between conventions: -builtin_filter(PyObject *self, PyObject *args) +builtin_filter(PyObject *self, PyObject *func, PyObject *seq) { - PyObject *func, *seq, *result, *it, *arg; + PyObject *result, *it, *arg; int len; /* guess for result list size */ register int j; - if (!PyArg_UnpackTuple(args, "filter", 2, 2, &func, &seq)) - return NULL; - # the are no other changes between METH_O and METH_ARGS - {"abs", builtin_abs, METH_O, abs_doc}, + {"abs", builtin_abs, METH_ARGS, abs_doc, 1, 1}, - {"filter", builtin_filter, METH_VARARGS, filter_doc}, + {"filter", builtin_filter, METH_ARGS, filter_doc, 2, 2}, Neal