This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients larry, rhettinger, serhiy.storchaka, vstinner
Date 2016-04-21.08:57:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Attached patch adds the following new function:

   PyObject* _PyObject_CallStack(PyObject *func,
                                 PyObject **stack, 
                                 int na, int nk);

where na is the number of positional arguments and nk is the number of (key, pair) arguments stored in the stack.

Example of C code to call a function with one positional argument:

    PyObject *stack[1];
    stack[0] = arg;
    return _PyObject_CallStack(func, stack, 1, 0);

Simple, isn't it?

The difference with PyObject_Call() is that its API avoids the creation of a tuple and a dictionary to pass parameters to functions when possible. Currently, the temporary tuple and dict can be avoided to call Python functions (nice, isn't it?) and C function declared with METH_O (not the most common API, but many functions are declared like that).

The patch only modifies property_descr_set() to test the feature, but I'm sure that *a lot* of C code can be modified to use this new function to beneift from its optimization.

Should we make this new _PyObject_CallStack() function official: call it PyObject_CallStack() (without the understand prefix) or experiment it in CPython 3.6 and decide later to make it public? If it's made private, it will require a large replacement patch later to replace all calls to _PyObject_CallStack() with PyObject_CallStack() (strip the underscore prefix).

The next step is to add a new METH_STACK flag to pass parameters to C functions using a similar API (PyObject **stack, int na, int nk) and modify the argument clinic to use this new API.

Thanks to Larry Hasting who gave me the idea in a previous edition of Pycon US ;-)

This issue was created after the discussion on issue #26811 which is an issue in a micro-optimization in property_descr_set() to avoid the creation of a tuple: it caches a private tuple inside property_descr_set().
Date User Action Args
2016-04-21 08:57:22vstinnersetrecipients: + vstinner, rhettinger, larry, serhiy.storchaka
2016-04-21 08:57:21vstinnersetmessageid: <>
2016-04-21 08:57:21vstinnerlinkissue26814 messages
2016-04-21 08:57:21vstinnercreate