> +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? > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4