[Python-Dev] Deprecation policy

[Raymond Hettinger]

On Jan 25, 2014, at 5:29 AM, Ezio Melotti <ezio.melotti at gmail.com> wrote:

> Nick also suggested to document
> our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> http://www.python.org/dev/peps/pep-0005/ ).

Here's a few thoughts on deprecations:

* If we care at all about people moving to Python 3, then we'll stop
doing anything that makes the process more difficult.  For someone
moving from Python 2.7, it really doesn't matter if something that
existed in 2.7 got deprecated in 3.1 and removed in 3.3; from their
point-of-view, it just one more thing that won't work.

* The notion of PendingDeprecationWarnings didn't work out very well.
Conceptually, it was a nice idea, but in practice no one was benefitting
from it.  The warnings slowed down working, but not yet deprecated code.
And no one was actually seeing the pending deprecations.

* When a module becomes obsolete (say optparse vs argparse), there
isn't really anything wrong with just leaving it in and making the docs 
indicate that something better is available.  AFAICT, there isn't much 
value in actually removing the older tool.

* A good use for deprecations is for features that were flat-out misdesigned
and prone to error.  For those, there is nothing wrong with deprecating them
right away.  Once deprecated though, there doesn't need to be a rush to
actually remove it -- that just makes it harder for people with currently
working code to upgrade to newer versions of Python.

* When I became a core developer well over a decade ago, I was a little
deprecation happy (old stuff must go, keep everything nice and clean, etc).
What I learned though is that deprecations are very hard on users and that
the purported benefits usually aren't really important.

my-two-cents,


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140125/cb6739cd/attachment.html>