Home Original page

[Python-Dev] Deprecation policy

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Mon Nov 28 13:45:24 CET 2011 
On 12:14 pm, 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.

+1

Jean-Paul
More information about the Python-Dev mailing list