@vstinner, note that this partially reverts commit 2ff58a2 : IMO PyObject_CallNoArgs should always stay behind #ifndef Py_LIMITED_API (i.e. be in Include/cpython/).

The problem is that Include/cpython/ doesn't work with checks on the Python limited API version:

#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x03090000
/* Call a callable Python object without any arguments */
PyAPI_FUNC(PyObject *) PyObject_CallNoArgs(PyObject *func);
#endif

Include/cpython/abstract.h is not included if Py_LIMITED_API is defined!

I'm not sure that I understood your comment properly. It was decided to add PyObject_CallNoArgs() to the limited API on purpose (commit 2ff58a2, bpo-37194). Do you see a reason to exclude it from the limited API?

Hmm, I see I misunderstood the bpo-37194 conversation.
The way I read it, there are 3 layers of the C apis: limited (Py_LIMITED_API), public (cpython/) and private (internal/).
I don't think adding something to the public API necessarily means adding it to the stable ABI, especially if there are other ways of doing the same thing.

I see now that you were talking about the limited API (stable ABI) when you said "public".
Do you think PyObject_CallNoArgs should be in the stable ABI? I don't.

The main reasons for excluding things from the stable API/ABI is if we think they might be difficult for other implementations to provide, or if they're intrinsically exposed to ABI compatibility issues.

PyObject_CallNoArgs() doesn't suffer from either of those problems - worst case is that other implementations just need to define it as a naive wrapper around PyObject_Call()

Do you think PyObject_CallNoArgs should be in the stable ABI?

Yes, I consider that it is safe to add it to the stable ABI, since it should be trivial to implement.