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/
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