Ok, so I looked again at your change: fastcall-no-keywords-2.patch LGTM,
I like the idea!

Since your patch is huge, I expect that it will be a pain to rebase it. I
suggest you to push it as soon as possible, to avoid conflicts. I will rework
my issue #29465 patch once this issue is done.


According to the number of modified functions and files, not accepting keyword
arguments is very common, and so it is annoying to have to call
_PyArg_NoStackKeywords() in each function. Avoiding the "PyObject *kwnames" can
also reduces the stack consumption per call, especially in long call stacks.

At least my assumption that almost no function will accept only positional
arguments is plain wrong :-) In practice, it's more the opposite!

I checked quickly fastcall-no-keywords-2.patch stack usage and performance.
It seems non significant, but I'm not surprised, it isn't really the purpose
of the change. IMHO the purpose of the change is more to simplify the code,
avoid to duplicate _PyArg_NoStackKeywords() everywhere, and only check
keyword arguments at one place.

For stack consumption and performances, I got good results on my issue #29465
which adds a new _PyObject_FastCall() function. IMHO this function fits well
with your new METH_FASTCALL (no keyword argument)! If we combine both changes,
we can get something very good ;-)

@Stefan Behnel: Thank you for you reply. So the backward compatibility was a
fake issue, and we are free to modify METH_FASTCALL. Anyway, *if* someone uses
METH_FASTCALL, IMHO it will be easy to update his/her code and add #ifdef on
the Python version if needed. Again, as Serhiy wrote, METH_FASTCALL is out of
the stable ABI, so we are safe on our warranties.