[Python-Dev] METH_NOARGS calling convention

[Tim Peters]

Cool!

[Martin von Loewis]
> ...
> Now, one open issue is whether the METH_NOARGS functions should have
> a signature of
>
>   PyObject * (*unaryfunc)(PyObject *);
>
> or of
>
>   PyObject *(*PyCFunction)(PyObject *, PyObject *);
>
> which then would be called with a NULL second argument; the first
> argument would be self in either case.
>
> IMO, the advantage of passing the NULL argument is that NOARGS methods
> don't need to be cast into PyCFunction in the method table; the
> advantage of the second approach is that it is clearer in the function
> implementation.
>
> Any opinions which signature to use?

The one that makes sense <wink>:  delcare functions with the number of
arguments they use.  I don't care about needing to cast in the table:  you
do that once, but people read the *code* over and over, and an unused arg
will be a mystery (or even a source of compiler warnings) every time you
bump into one.

The only way needing to cast could be "a problem" is if this remains an
undocumented gimmick that developers have to reverse-engineer from staring
at the (distributed all over the place) implementation.  I like what the
patch does, but I'd reject it just for continuing to leave this stuff
Utterly Mysterious:  please add comments saying what METH_NOARGS and METH_O
*mean*:  what's the point, why are these defined, how and when are you
supposed to use them?  That's where to explain the need to cast METH_NOARGS.