[Python-Dev] Deprecation policy

[Antoine Pitrou]

Hi,

On Mon, 28 Nov 2011 01:30:53 -0800
Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> 
> On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote:
> 
> > Hi,
> > our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like:
> >  1) deprecate something and add a DeprecationWarning;
> >  2) forget about it after a while;
> >  3) wait a few versions until someone notices it;
> >  4) actually remove it;
> > 
> > I suggest to follow the following process:
> >  1) deprecate something and add a DeprecationWarning;
> >  2) decide how long the deprecation should last;
> >  3) use the deprecated-remove[1] directive to document it;
> >  4) add a test that fails after the update so that we remember to remove it[2];
> 
> How about we agree that actually removing things is usually bad for users.
> It will be best if the core devs had a strong aversion to removal.

Well, it's not like we aren't already conservative in deprecating
things.

> Instead, it is best to mark APIs as obsolete with a recommendation to use something else instead.
> There is rarely a need to actually remove support for something in the standard library.
> That may serve a notion of tidyness or somesuch but in reality it is a PITA for users making it more difficult to upgrade python versions and making it more difficult to use published recipes.

I agree with Xavier's answer that having recipes around which use
outdated (and possibly inefficient/insecure/etc.) APIs is a nuisance.

Also, deprecated-but-not-removed APIs come at a maintenance and
support cost.

Regards

Antoine.