RetroSearch Browse

Fri Feb 27 23:06:56 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-February/042841.html

>  > 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?

There would by an analogue to Py_BuildValue().

> The nice thing about METH_NOARGS and METH_O is that they describe what
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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-February/042841.html below:

[Python-Dev] Idea for a fast calling convention