On the system I'm porting to(*), an application will trap if the caller does not pass the exact parameter list that the callee requires. This is causing problems running Python.

One common instance where this appears to be causing problems is where functions are registered as METH_NOARGS methods. For example, in Obejcts/dictobject.c, dict_popitem() is declared:

static PyObject *dict_popitem(dictobject *mp);

However, as it is declared in the method array as METH_NOARGS, it will be called by Objects/methodobject.c:PyCFunction_Call() as "(*meth)(self, NULL)" (i.e., an extra NULL parameter is passed for some reason). This will fail on my target system.

I've no problem submitting a patch for this (dictobject.c is by no means the only place this is happening - it's just the first one encountered because it's used so much - though some places _do_ correctly declare a second, ignored parameter). However, I'd like to get agreement on the correct form it should be changed to before I put the effort in to produce a patch (it's going to be a fairly tedious process to identify and fix all these).

In various modules, the functions are called internally as well as being registered as METH_NOARGS methods.

Therefore, the change can either be:

static PyObject *foo(PyObject *self)
{
  ...
}

static PyObject *foo_noargs(PyObject *self, void *noargs_null)
{
   return foo(self);
}

... where 'foo' is called internally and 'foo_noargs' is registered as a METH_NOARGS method.

or:

static PyObject *foo(PyObject *self, void *noargs_null)
{
  ...
}

... and any internal calls in the module have to pass a second, NULL, argument in each call.

The former favours internal module calls over METH_NOARGS calls, the latter penalises them. Which is preferred? Should this be raised on a different forum? Does anyone care? ;)

Thanks, Kev.

(*) Details on request.