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.
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.
Raymond
_______________________________________________
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
