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.