[Python-Dev] Deprecating C APIs (Use of PyArg_NoArgs()) (original) (raw)
M.-A. Lemburg mal@lemburg.com
Tue, 02 Apr 2002 21:12:16 +0200
- Previous message: [Python-Dev] Deprecating C APIs (Use of PyArg_NoArgs())
- Next message: [Python-Dev] Deprecating C APIs (Use of PyArg_NoArgs())
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guido van Rossum wrote:
> +1 on removing PyArgGetInt() OK. > -1 on removing PyArgNoArgs() ... 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, PyArgParseTuple(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/
- Previous message: [Python-Dev] Deprecating C APIs (Use of PyArg_NoArgs())
- Next message: [Python-Dev] Deprecating C APIs (Use of PyArg_NoArgs())
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]