[Python-Dev] Deprecation policy

[Nick Coghlan]

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.

OTOH, genuinely problematic APIs that ideally wouldn't have survived
even the 3.x transition (e.g. the APIs that the 3.x subprocess module
inherited from the 2.x commands module that run completely counter to
the design principles of the subprocess module) should probably still
be considered for removal as soon as is reasonable after a superior
alternative is made available.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia