[Python-Dev] Deprecating C APIs (Use of PyArg_NoArgs())

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> > Both PyArg_GetInt() & PyArg_NoArgs() both have comments above them
> > stating they should not be used.  There are no more occurances
> > of PyArg_GetInt().  I'm working on reducing METH_OLDARGS, down to 214.
> >
> > If you want I can remove them from Include/Python.h when done.
> 
> Has the api documentation documented them as obsolete?  If so, or if
> they were undocumented, yes, please remove them.  If not, I'd see if
> there's a way to turn these into warnings for one release.

+1 on removing PyArg_GetInt()
-1 on removing PyArg_NoArgs() ... this API is still in very active
use in third party extensions.
 
> > If so, should I write up anything in NEWS?
> 
> Yes, I think so.  It's always good to announce explicitly when
> a previously deprecated item actually gets deleted, no matter how
> small.

I think we should come up with a better way to deprecate C level
APIs. NEWS is not as effective as one might wish; any deprecation
or removal of an API should also include upgrade information
for the C extension writer so that upgrading their modules
does not require diving into the new style C API code every 
time.

I'd suggest to have a PEP which documents all C API changes
or deprecations together with a short decsription of how to
update old code.

Another aspect which we ought to consider is that C extension
writers may have a different view of when to leave backward
compatibility path in favour of a new Python version. IMHO,
there should always be a way to emulate old behaviour so that
extensions can continue to support Python 1.5.2 if they need to.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/