[Python-Dev] Deprecation policy

[Petri Lehtinen]

Raymond Hettinger wrote:
> 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.

I'm strongly against breaking backwards compatiblity between minor
versions (e.g. 3.2 and 3.3). If something is removed in this manner,
the transition period should at least be very, very long.

To me, deprecating an API means "this code will not get new features
and possibly not even (big) fixes". It's important for the long term
health of a project to be able to deprecate and eventually remove code
that is no longer maintained.

So, I think we should have a clear and working deprecation policy, and
Ezio's suggestion sounds good to me. There should be a clean way to
state, in both code and documentation, that something is deprecated,
do not use in new code. Furthermore, deprecated code should actually
be removed when the time comes, be it Python 4.0 or something else.

Petri