[Python-Dev] Remove METH_OLDARGS? (original) (raw)

Neal Norwitz nnorwitz at gmail.com
Tue May 30 06:15:53 CEST 2006

On 5/29/06, Thomas Wouters <thomas at python.org> wrote:

On 5/29/06, Fredrik Lundh <fredrik at pythonware.com> wrote: > > this is a clear case of unnecessary meddling. removing it won't remove > much code (a whopping 11 lines is dedicated to this), nor give any speed > ups whatsoever; all you're doing is generating extra work and support > issues for a bunch of third-party developers. trust me, we have better > things to do with our time. > > -1 on meddling with this before 3.0.

-1 from me, too, for the same reason. It would be nice if the use of PyArgParse could generate a (C) compile-time warning, but since it can't, I think a runtime warning for this minor case is just overkill. (The C compile-time warning would be useful in other cases, too... hmm, perhaps we can do some post-processing of .o files, looking for deprecated symbols left undefined...)

How can users find the implicit use of METH_OLDARGS in code like this:

static struct PyMethodDef gestalt_methods[] = { {"gestalt", gestalt_gestalt}, {NULL, NULL} /* Sentinel */ };

static PyMethodDef SwiMethods[]= { { "swi", swi_swi,0}, { NULL, NULL} };

The first one was taken straight from one of Georg's checkins, the second one was modified. How many people knew we were still using METH_OLDARGS in these places? I know this can be done with some simple scripts, but that won't catch all cases. And many people won't run such a script, much less write one.

OTOH, perhaps a deprecation warning on PyArgs_Parse() is sufficient? What about that? It doesn't address other cases where OLDARGS are used without PyArgs_Parse though.

n

More information about the Python-Dev mailing list