[Python-Dev] Deprecating C APIs (Use of PyArg_NoArgs()) (original) (raw)
Guido van Rossum guido@python.org
Tue, 02 Apr 2002 09:37:07 -0500
- 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 ]
+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?
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.
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.
--Guido van Rossum (home page: http://www.python.org/~guido/)
- 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 ]