/cc @vstinner @markshannon @encukou @methane

Note that PyCFunction_Call is not a documented C API function, so I assumed that this minor change in behaviour (no longer doing the recursion check) would be acceptable.

That's the kind of function that projects like Cython call directly.

That's the kind of function that projects like Cython call directly.

What point are you trying to make? It that just a comment or is it saying something about this PR? Or are you just complaining about Cython? Or is it a joke somehow?

I suggest to ensure that any PyCFunction_Call behavior change will not break anything, especially in Cython.

It is undocumented, so the only documentation available to people who wanted to use this function was the code itself.
It would be OK to remove/rename PyCFunction_Call, if we needed to do that, but I don't think we should subtly change its behavior.

Perhaps CPython could use cfunction_call_varargs internally, and that would have the check removed; PyCFunction_Call could then be a wrapper that does the check?

I checked and Cython doesn't use PyCFunction_Call. I'm not sure if that function was ever intended to be public. It's quite special, there are no such functions for other classes. It's not documented. And what's the use case? You can only use PyCFunction_Call if you somehow know in advance that some object is a builtin_function_or_method, which you typically don't know. And if you somehow do know that it's a builtin_function_or_method and care about speed, you will want to use the vectorcall calling convention instead of the slow tp_call convention used by PyCFunction_Call.

PyCFunction_Call could then be a wrapper that does the check?

At that point, probably best would be to just alias it to PyObject_Call.

Right, it's quite useless as public API. Remove it in 3.9. But:

• Don't keep the same name if the semantics changed.
• Mention the removal in the news file, so anyone who did use it may know the removal was intentional.

It was probably never intended to be public (and probably predates discussions on what should be public), but it is an exported symbol.

We need to keep it for the stable ABI, but that's easily solved by making it an alias of PyObject_Call.

I updated my branch to do this.

Added a deprecation for PyCFunction_Call.