@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.

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

stable API/ABI

Got it! Thanks for explaining and sorry for the misunderstanding.

I would like to see a public discussion if we should pass tstate to functions or not (change the calling convention).

I think that's a good change, but I don't think I'll have time myself to do that for 3.9.

The vectorcall API should be added in 3.9, but it can still be changed before the final release. (If it is, I'd prefer the underscored versions to stay as they are for 3.8 compatibility.)

This PR touches a lot of files; if it's open for a long time it might need to be rebased often. Can we not block this on the tstate discussion?

I think that's a good change, but I don't think I'll have time myself to do that for 3.9.

I started a thread on python-dev: https://mail.python.org/archives/list/python-dev@python.org/thread/PIXJAJPWKDGHSQD65VOO2B7FDLU2QLHH/

If we agree that it's a good idea to pass tstate a part of VECTORCALL, I can work on the actual implementation.

@vstinner

Before making the API public, I would like to see a public discussion if we should pass tstate to functions or not (change the calling convention).

Why must this be done before this PR is merged?
The discussion is not about making the API public. And this PR doesn't need to be final – if the discussion concludes we need changes to the API, that can still be done.

Why must this be done before this PR is merged?

There are two open questions:

• Should VECTORCALL calling convention be modified to add a tstate parameter?
• Should the public VECTORCALL C API be modified to add a tstate parameter?

Early answers on python-dev are that the calling convention should be modified, but the public C API should not include tstate (passed implicitly if the calling convention is changed). We can use a private C API which accepts a tstate.

So far, these questions don't seem to block this PR. Changing the calling convention can be done later.

For the private C API with tstate parameter, I added for example _PyObject_VectorcallTstate() function. I think that we can keep this name for now. We cannot use _PyObject_Vectorcall() name, since it is kept as an alias to PyObject_Vectorcall() to backward compatibility.

So far, these questions don't seem to block this PR.

That's my impression as well.
I have made the requested changes; please review again
(i.e. I made all of the zero requested changes.)

For the private C API with tstate parameter, I added for example _PyObject_VectorcallTstate() function. I think that we can keep this name for now. We cannot use _PyObject_Vectorcall() name, since it is kept as an alias to PyObject_Vectorcall() to backward compatibility.

If the calling convention passes tstate explicitly, it would make sense to make PyObject_Vectorcall* take tstate as well. (But, for consistency, the new PyObject_Call* ones should not take tstate.)

Thanks for making the requested changes!

@vstinner: please review the changes made to this pull request.