Georg Brandl wrote:

...

There's still a ton used under Modules. Also, if no flag is specified, it will default to 0 (ie, METH_OLDARGS). I wonder how many third party modules use METH_OLDARGS directly or more likely indirectly.

These modules can be converted.

I think that should be done for 2.5, but nothing else. Or, perhaps a deprecation warning could be generated if it is still used. Regards, Martin

Guido van Rossum wrote:

...

I think that should be done for 2.5, but nothing else. Or, perhaps a deprecation warning could be generated if it is still used.

I'll let Martin decide this one.

I just sent a message to some that producing a DeprecationWarning is fine, but now I read some opposition; given that this really just needs very little code to support it, and given that run-time warnings annoy the users, not the module authors, I agree that this should stay silently until 3.0. We should still continue to remove all uses we have ourselves. Regards, Martin

On 5/28/06, Georg Brandl wrote:

Neal Norwitz wrote:

...

On 5/28/06, Georg Brandl wrote:

...

In the process of reviewing and possibly extending getargs.c, I stumbled over the "compatibility" flag supposedly used for METH_OLDARGS functions. No code in the core uses this calling convention any more, and it has been deprecated for quite a long time (since 2.2), so would it be appropriate to end support for it in 2.5?

There's still a ton used under Modules. Also, if no flag is specified, it will default to 0 (ie, METH_OLDARGS). I wonder how many third party modules use METH_OLDARGS directly or more likely indirectly.

These modules can be converted.

We can convert the one's in Python, but not the third party ones. It's also very difficult to search for something that's not there. You need to review every PyMethodDef entry to verify it has a METH_* flag. These implicit METH_OLDARGS may well exist in Python, especially given who did the patch to add them in the first place. :-) http://mail.python.org/pipermail/python-dev/2002-March/022009.html http://mail.python.org/pipermail/patches/2002-July/009023.html

...

I would like to get rid of the flag, but I'm not sure we can do it safely until 3.0.

It has been deprecated since 2.2, so it'd be no surprise if it went away.

There's a difference between "it'd be no surprise" and "it should be no surpise". While I agree in theory they are the same, in practice, they are not. That's the difference between theory and practice. :-)

Also, it would be easy to detect METH_OLDARGS in PyCFunction_New and raise an appropriate exception.

I agree with Martin this should raise a deprecation warning in 2.5. n

Neal Norwitz wrote:

...

Also, it would be easy to detect METH_OLDARGS in PyCFunction_New and raise an appropriate exception.

I agree with Martin this should raise a deprecation warning in 2.5.

why? 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. </F>

Thomas Wouters wrote:

On 5/29/06, *Fredrik Lundh* mailto:fredrik@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 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...)

Isn't there at least a GCC __attribute__((deprecated))? Georg

Martin v. Löwis wrote:

Georg Brandl wrote:

...

Isn't there at least a GCC __attribute__((deprecated))?

Yes, but it applies to functions only. I guess you could make a __deprecated__ function, and then expand METH_OLDARGS to a call of that function. That won't help in cases where there are no flags given at all in the method structures.

I thought more about PyArg_Parse for __deprecated__. If you look at the patch on SF, it's creating warnings whenever a new CFunction is created with a METH_OLDARGS flag. I'm not sure this is the right way since it may mean that users of extensions using METH_OLDARGS might get a warning each time they get a bound method using it. Georg

On 5/29/06, "Martin v. Löwis" wrote:

Georg Brandl wrote:

...

I thought more about PyArg_Parse for __deprecated__.

Ah, PyArg_Parse can, of course. Having it actually do that should not hurt, either - but you need a reliable check whether the compiler supports __deprecated__.

Already done for gcc, see Py_DEPRECATED in pyport.h. Would be nice if someone could add support on Windows. n

On 5/29/06, Thomas Wouters wrote:

On 5/29/06, Fredrik Lundh 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

On 5/29/06, "Martin v. Löwis" wrote:

...

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.

What other cases remain? People might have complex argument processing procedure not involving PyArg_Parse, these would just break with a runtime error in Py3k. If the module is maintained, it should be easy to fix it. If the module is unmaintained, producing a warning now might not help, either.

One case would be if the function doesn't take any args, but the args aren't checked, just ignored. Another case I was thinking about was PyArg_NoArgs which is a macro, but that just calls PyArg_Parse, so it would get flagged. I can't imagine there would be enough of these cases to matter. I'd be satisfied with a deprecation warning for PyArg_Parse, though we (*) should really figure out how to make it work on Windows. I haven't seen anyone object to the C compiler deprecation warning. n -- * Where we means someone with a Windows box of course. :-)

On 5/30/06, Georg Brandl wrote:

Neal Norwitz wrote:

...

I'd be satisfied with a deprecation warning for PyArg_Parse, though we (*) should really figure out how to make it work on Windows. I haven't seen anyone object to the C compiler deprecation warning.

There is something at http://msdn2.microsoft.com/en-us/library/044swk7y.aspx

but it says only "C++".

I checked, and it works with C as well. (VC 7.1 toolkit compiler, but I can't believe it makes a difference...) Paul.

Fredrik Lundh wrote:

Georg Brandl wrote:

...

...

I'd be satisfied with a deprecation warning for PyArg_Parse, though we (*) should really figure out how to make it work on Windows. I haven't seen anyone object to the C compiler deprecation warning.

There is something at http://msdn2.microsoft.com/en-us/library/044swk7y.aspx

but it says only "C++".

and links to

http://msdn2.microsoft.com/en-us/library/c8xdzzhh.aspx

which provides a pragma that does the same thing, and is documented to work for both C and C++, and also works for macros.

But we'd have to use an #ifdef for every deprecated function. Of course, there aren't so many of them. Georg