[Python-Dev] Deprecation policy (original) (raw)
Raymond Hettinger raymond.hettinger at gmail.com
Mon Nov 28 10:30:53 CET 2011
- Previous message: [Python-Dev] ImportError: No module named multiarray (is back)
- Next message: [Python-Dev] Deprecation policy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote:
Hi, our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like: 1) deprecate something and add a DeprecationWarning; 2) forget about it after a while; 3) wait a few versions until someone notices it; 4) actually remove it;
I suggest to follow the following process: 1) deprecate something and add a DeprecationWarning; 2) decide how long the deprecation should last; 3) use the deprecated-remove[1] directive to document it; 4) add a test that fails after the update so that we remember to remove it[2];
How about we agree that actually removing things is usually bad for users. It will be best if the core devs had a strong aversion to removal. Instead, it is best to mark APIs as obsolete with a recommendation to use something else instead. There is rarely a need to actually remove support for something in the standard library. That may serve a notion of tidyness or somesuch but in reality it is a PITA for users making it more difficult to upgrade python versions and making it more difficult to use published recipes.
Raymond -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20111128/73278bf9/attachment.html>
- Previous message: [Python-Dev] ImportError: No module named multiarray (is back)
- Next message: [Python-Dev] Deprecation policy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]