> The warning in GCC shouldn't probably have been enabled at all in `-Wall -Wextra` because the cast is explicit. However, it is somewhat true.

The explicit cast is precisely what enables the more nuanced function cast warning where it checks the function for type compatibility.  That is, it will check the types of the return and arguments and then warn in case of mismatch.

> However, the correct way to fix would be to have the METH_NOARGS case cast the function to the right prototype. There exists lots of existing code that *is* going to break too. 

AFAICT, there is no right prototype for the METH_NOARGS function; there used to be a PyCFunctionWithNoArguments but that seems to have fallen out of favour some time back.  The prototype that seems to be commonly in use (and in clinic as well, which is what I based my patches on) is the PyCFunction, which seems like a safe way to do things.

> Perhaps PyCFunction should declare no prototype, i.e. empty parentheses, for backwards compatibility:
> 
>     typedef PyObject *(*PyCFunction)();
> 
> and deprecate it; start using a new typedef for it - and then add proper casts in every place that call a function.

I have a patch in the works that makes it PyObject *(*)(PyObject *, PyObject *, ...)

which allows for two compulsory arguments (fits in with most cases, provided the METH_NOARGS patch is accepted) and then the rest depending on the type of the cast function.  The rest of the PyMethodDef functions are much simpler fixes this way.  It also seems like a more intuitive description of the callbacks.

Then there are getter and setter and other function pointers that need similar fixes to METH_NOARGS.