On 5/29/06, Martin v. Löwis [EMAIL PROTECTED] 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
On 5/30/06, Georg Brandl [EMAIL PROTECTED] 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
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
Neal Norwitz wrote:
Already done for gcc, see Py_DEPRECATED in pyport.h. Would be nice if
someone could add support on Windows.
The manner that macro is used can't be leveraged to work in the VC
compiler. I admit to not having done an extensive search for the usage
of Py_DEPRECATED, but to
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
Georg Brandl wrote:
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.
or a
On 5/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
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
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
On 5/29/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
this is a clear case of unnecessary meddling.removing it won't removemuch code (a whopping 11 lines is dedicated to this), nor give any speedups whatsoever; all you're doing is generating extra work and support
issues for a bunch of third-party
Thomas Wouters wrote:
On 5/29/06, *Fredrik Lundh* [EMAIL PROTECTED]
mailto:[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
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
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
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__.
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;
Martin v. Löwis wrote:
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
On 5/29/06, Martin v. Löwis [EMAIL PROTECTED] 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__.
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
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
On 5/28/06, Georg Brandl [EMAIL PROTECTED] 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
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
Neal Norwitz wrote:
On 5/28/06, Georg Brandl [EMAIL PROTECTED] 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
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
On 5/28/06, Georg Brandl [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
On 5/28/06, Georg Brandl [EMAIL PROTECTED] 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
23 matches
Mail list logo
