
The patch http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427190&group_id=5470 introduces two new calling conventions, METH_O and METH_NOARGS. The rationale for METH_O has been discussed already; the rationale for METH_NOARGS is that it allows a convient simplification (plus a marginal speed-up) of functions which do either PyArg_NoArgs(args) or PyArg_ParseTuple(args, ":function_name"). 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? Regards, Martin

Martin von Loewis wrote:
The patch
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=427190&group_id=5470
introduces two new calling conventions, METH_O and METH_NOARGS. The rationale for METH_O has been discussed already; the rationale for METH_NOARGS is that it allows a convient simplification (plus a marginal speed-up) of functions which do either PyArg_NoArgs(args) or PyArg_ParseTuple(args, ":function_name").
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 second... I'm not sure how you will get extension writers who have to maintain packages for all three Python versions to ever change their code to use the new style calling scheme: there simply is no clean way to use the same code base unless you are willing to add tons of #ifdefs. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

M.-A. Lemburg writes:
Any opinions which signature to use?
The second...
Seconded. ;-)
I'm not sure how you will get extension writers who have to maintain packages for all three Python versions to ever change their code to use the new style calling scheme: there simply is no clean way to use the same code base unless you are willing to add tons of #ifdefs.
You won't, and that's OK. Even if 3rd-party extensions never use it, there are plenty of functions/methods in the standard distribution which can use it, and I imagine those would be converted fairly quickly. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations

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.
participants (4)
-
Fred L. Drake, Jr.
-
M.-A. Lemburg
-
Martin von Loewis
-
Tim Peters