One other question occurred to me for "deprecate X in favour of Y" situations -
should the deprecation warning added to X point developers towards Y?
Also, should the PEP include example wordings for deprecation warnings, rather
than being completely freeform? Martin listed some information that should be
included, but it seems an example or two would make it easy to get right.
E.g.:
Unmaintained, with a maintained alternative:
"Due to lack of maintenance, this module has been deprecated in favour of module
Y and will be removed in Python 2.6 (see PEP 4 for information on the
deprecation process)"
Security problems, no alternative:
"Due to security concerns, this module has been deprecated and will be removed
in Python 2.6 (see PEP 4 for information on the deprecation process)"
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
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