[Python-Dev] Deprecation policy

Steven D'Aprano steve at pearwood.info
Mon Nov 28 13:14:46 CET 2011

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.


More information about the Python-Dev mailing list