[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