[Python-Dev] Deprecation policy

Matt Joiner anacrolix at gmail.com
Mon Nov 28 15:38:18 CET 2011

On Mon, Nov 28, 2011 at 11:14 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> Xavier Morel wrote:
>> Not being too eager to kill APIs is good, but giving rise to this kind of
>> living-dead APIs is no better in my opinion, even more so since Python has
>> lost one of the few tools it had to manage them (as DeprecationWarning was
>> silenced by default). Both choices are harmful to users, but in the long
>> run I do think zombie APIs are worse.
> I would much rather have my code relying on "zombie" APIs and keep working,
> than to have that code suddenly stop working when the zombie is removed.
> Working code should stay working. Unless the zombie is actively harmful,
> what's the big deal if there is a newer, better way of doing something? If
> it works, and if it's fast enough, why force people to "fix" it?
> It is a good thing that code or tutorials from Python 1.5 still (mostly)
> work, even when there are newer, better ways of doing something. I see a lot
> of newbies, and the frustration they suffer when they accidentally
> (carelessly) try following 2.x instructions in Python3, or vice versa, is
> great. It's bad enough (probably unavoidable) that this happens during a
> major transition like 2 to 3, without it also happening during minor
> releases.
> Unless there is a good reason to actively remove an API, it should stay as
> long as possible. "I don't like this and it should go" is not a good reason,
> nor is "but there's a better way you should use". When in doubt, please
> don't break people's code.

This is a great argument. But people want to see new, bigger better
things in the standard library, and the #1 reason cited against this
is "we already have too much". I think that's where the issue lies:
Either lots of cool nice stuff is added and supported (we all want our
favourite things in the standard lib for this reason), and or the old
stuff lingers...

I'm sure a while ago there was mention of a "staging" area for
inclusion in the standard library. This attracts interest,
stabilization, and quality from potential modules for inclusion.
Better yet, the existing standard library ownership is somehow
detached from the CPython core, so that changes enabling easier
customization to fit other implementations (jpython, pypy etc.) are

tl;dr old stuff blocks new hotness. make room or separate standard
library concerns from cpython

> --
> Steven
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com

More information about the Python-Dev mailing list