[Python-Dev] Deprecation policy
python-dev at masklinn.net
Mon Nov 28 13:56:31 CET 2011
On 2011-11-28, at 13:06 , Nick Coghlan wrote:
> On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel <catch-all at masklinn.net> 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.
> But restricting ourselves to cleaning out such APIs every 10 years or
> so with a major version bump is also a potentially viable option.
> So long as the old APIs are fully tested and aren't actively *harmful*
> to creating reasonable code (e.g. optparse) then refraining from
> killing them before the (still hypothetical) 4.0 is reasonable.
Sure, the original proposal leaves the deprecation timelines as TBD and I hope I did not give the impression of setting up a timeline (that was not the intention). Ezio's original proposal could simply be implemented by having the second step ("decide how long the deprecation should last") default to "the next major release", I don't think that goes against his proposal, and in case APIs are actively harmful (e.g. very hard to use correctly) the deprecation timeline can be accelerated specifically for that case.
More information about the Python-Dev