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

M.-A. Lemburg mal@lemburg.com
Tue, 02 Apr 2002 21:12:16 +0200


Guido van Rossum wrote:
> 
> > +1 on removing PyArg_GetInt()
> 
> OK.
> 
> > -1 on removing PyArg_NoArgs() ... this API is still in very active
> > use in third party extensions.
> 
> Would it be OK if it issued a warning?

Hmm, people would start screaming, I guess -- this API is used
far more than e.g. the regex/regsub module combo. A one-time-per-
module warning would probably be OK though.

I seriously think that we should install a set of common
third party extensions somewhere to that we can easily
check usage of the APIs in the outside world, e.g. take
the packages Aahz collected recently and unzip them to
some directory on python.org. A grep would then quickly
produce proof of "common" usage.

> > 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.
> 
> In this case, PyArg_ParseTuple(args, ":functionName") is pretty simple
> to explain.
> 
> > 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.
> 
> It shouldn't be a PEP (that's a *proposal*).  It should be part of the
> C API docs, possibly an appendix.

I was thinking of an informational PEP -- mostly because PEPs
are easily accessible and also simple to write (LaTeX is not
everybody's friend ;-).
 
> > 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.
> 
> Not a problem in this case.

True, but there are other instances where this was a problem
in the past, e.g. 

#if PY_VERSION_HEX < 0x01060000

#if !defined(PyObject_DEL)
# define PyObject_DEL(x) free(x)
# define PyObject_Del(x) free(x)
#endif

#endif

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