Martin v. Loewis writes: > +1. IMO, deprecation would involve removing those from the > documentation (or explicitly list them as deprecated, without > explaining what they do), and explain that they are dead in the header > files. That could be the state of deprecation for the years to come. No; the descriptions should not be *removed*; someone needing to port code from an older version of Python to a newer version, or seeking to keep code highly portable among versions, can benefit from the descriptions. These would be marked with the deprecation notice, which would include a pointer to the "new way". The deprecation notices should probably be added to the 2.2.1 docs since this will be important to anyone needing to maintain extensions. (The text of the deprecation notice would clearly need to be different, and would indicate that the deprecation is effective in 2.3.) When the old entry points should be removed is a separate issue, but just as clearly should not be the same version as the deprecation is effective. So 2.4 at the earliest. Tim: I've not had time to follow every detail of this conversation; please file an SF bug report on the docs, listing *exactly* which functions & macros I should mark as deprecated. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
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