My idea is for a new flag, METH_STACK, that generalizes (and potentially replaces) METH_NOARGS AND METH_O.
How would METH_STACK methods work when called via func(*args)
The args tuple is converted to an equivalent stack reference.
or via the various functions of the C API?
The nice thing about METH_NOARGS and METH_O is that they describe what
There would by an analogue to Py_BuildValue(). the
called function needs.
This is closer to METH_VARARGS which lets the function itself handle the arguments.
METH_STACK sounds like a core dump waiting to happen.
It is no more or less a risk of a core dump than METH_VARARGS. Pretty much if any C function expects one thing and gets another (passing an pointer to the wrong structure or somesuch), then something bad happends. Right now, if you write f(x,y,z) where f is a PyCFunction, then ceval.c will execute CALL_FUNCTION 3 by pulling off three stack variables, load them into a new tuple, pass the tuple to the function, and the function will call either PyArg_ParseTuple() or PyArg_UnpackTuple(). With the new way, CALL_FUNCTION 3 calls the method with a stack pointer and the argument count (essentially the same data as the tuple) and the function calls PyArg_ParseStack() or PyArg_UnpackStack() which verifies the number of arguments and pulls the data off of the stack. All of the steps are encapsulated. Essentially, the only change is transferred the responsibility for pulling data off of the stack from ceval.c to the function that actually uses the data. This saves the unnecessary tuple carrier. Raymond