On 5/29/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 5/29/06, Fredrik Lundh <[EMAIL PROTECTED]> 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
> PyArg_Parse 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
