Feature or enhancement
The new-as-of-3.9 PyCMethod signature is great in that it simplifies getting access to the relevant module state via the defining_class argument. However, it is only available with the METH_FASTCALL flag. However, the docs for the vectorcall protocol (https://docs.python.org/3/c-api/call.html#vectorcall to get around the link limitation for new users) states:
A class should not implement vectorcall if that would be slower than tp_call. For example, if the callee needs to convert the arguments to an args tuple and kwargs dict anyway, then there is no point in implementing vectorcall.
In my attempts to port VTK to use the stable ABI, accessing the relevant module state is important to get access to the PyTypeObject* pointers for internal type comparisons and subclassing. However, method implementations have no access except via the vectorcall protocol which is definitely true because the methods do not support kwargs (which is a new error path) and usually want a tuple of the args anyways (maybe this is fixable, but it is work I haven’t gotten to yet and even if it is would involve even way more “if 3.9+ … else …” code as 3.6 is still supported).
Pitch
Instead of locking defining_class behind the most featureful method signature, it should be available to at least one non-METH_FASTCALL signature (preferably one with kwargs and one without). Making every combination is probably infeasible (even if possible, the names will be very cumbersome).