> Do you suggest to not add these 2 new functions?

Yes, I suggest to not add them. The API for calling is already too large. 
Internally we can directly use _PyObject_FastCall(), and third party code 
should get benefit from optimized PyObject_CallFunctionObjArgs().

> > Can existing function PyObject_Call() be optimized to achieve a
> > comparable benefit?
> Sorry, I don't understand. This function requires a tuple. The whole
> purpose of my patch is to avoid temporary tuples.

Sorry, I meant PyObject_CallFunctionObjArgs() and like.

> Keyword arguments are optional. Having support for them cost nothing when
> they are not used.

My point is that if keyword arguments are used, this is not a fast call, and 
should use old calling protocol. The overhead of creating a tuple for args is 
dwarfen by the overhead of creating a dict for kwargs and parsing it.

> I really want to have a "pystack" API. In this patch, the new file looks
> useless, but in the full patch there are many functions including a few
> complex functions. I prefer to add the file now and complete it later.

But for now there is no a "pystack" API. What do you want to add? Can it be 
added with prefixes PyDict_, PyArg_ or PyEval_? On other side, other code can 
get a benefit from using _PyTuple_FromArray().

Here is alternative simplified patch.

1) _PyStack_AsTuple() is renamed to _PyTuple_FromArray() (-2 new files).
2) Optimized PyObject_CallFunctionObjArgs(), PyObject_CallMethodObjArgs() and 
_PyObject_CallMethodIdObjArgs().
3) Removed PyObject_CallNoArg() and PyObject_CallArg1(). Invocations are 
replaced by PyObject_CallFunctionObjArgs().
4) Removed support of keyword arguments in _PyObject_FastCall() (saved about 
20 lines and few runtime checks in _PyCFunction_FastCall).
5) Reverted changes in Objects/descrobject.c. They added a regression in 
namedtuple attributes access.