If we want to call an object's method from C code and pass it the args and kwargs tuples unchanged, we need to first retrieve the callable object using PyObject_GetAttrString(), then call it using PyObject_Call().

I would like to propose wrapping the two calls in a new helper.

Is this case common enough for adding special API? The name PyObject_CallMethodArgs looks too similar to the existing name PyObject_CallMethodObjArgs, this will make confusion. If add an API that accepts the method name as C string, you need to add also an API for method name passed as Python string and a private API for method name passed as `struct _Py_Identifier *`. Adding new API has a non-zero cost. It adds maintenance burden for core developers, it increases the number of things that should be learned by users, and can leads to generating less optimal code by the compiler, because it will need to analyze more code in the same file, and it can optimize less common paths and left more common paths unoptimized.

Are you aware that you can pass the args tuple unchanged by using PyObject_CallMethod()? PyObject_CallMethod(obj, name, "O", args)

> PyObject_CallMethodArgs(PyObject *obj, const char *name, PyObject *args, PyObject *kwargs)

This API is not efficient. It requires to create a temporary tuple and dictionary to pass position and keyword arguments. Look at FASTCALL which has a very different API. Sadly, FASTCALL APIs are currently private.

It seems that this issue is languishing without any additional comments from the OP.  Should it be closed as rejected?  Thanks!

I agree with rejecting and closing this issue.