On 2011-11-28, at 13:06 , Nick Coghlan wrote:
> On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel <catch-...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
