[Python-Dev] When to remove deprecated stuff

Ezio Melotti ezio.melotti at gmail.com
Thu Aug 22 19:34:44 CEST 2013


On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen <petri at digip.org> wrote:
> Removing some cruft on each release can be very painful for users.
> Django's deprecation policy works like this: They deprecate something
> in version A.B. It still works normally in A.B+1, generates a
> (silenced) DeprecationWarning in A.B+2, and is finally removed in
> A.B+3.

I see two problems with this:
1) DeprecationWarnings should be generated as soon as the feature is
deprecated (i.e. A.B, not A.B+2).  Holding off the warnings is not
helping anyone.
2) The deprecation period seems fixed and independent from the
feature.  IMHO the period should vary depending on what is being
deprecated.  Little known/used "features" could be deprecated in A.B
and removed in A.B+1; common "features" can be deprecated in A.B and
removed in A.B+n, with an n >= 2 (or even wait for A+1).

> So if I haven't read through the full release notes of each
> release nor enabled DeprecationWarnings, I end up having something
> broken each time I upgrade Django.

Reading the release notes shouldn't be required -- DeprecationWarnings
are already supposed to tell you what to change.
If you have good test coverage this should happen automatically (at
least with unittest), but even if you don't you should run your code
with -Wa before upgrading (or test your code on the new version before
upgrading Python/Django/etc. in production).

Best Regards,
Ezio Melotti

> I hope the same will not start happening each time I upgrade Python.
> When the removals happen on major version boundaries, it should be
> more evident that something will break. Then people can enable
> DepreationWarnings and test all the affected code thoroughly with the
> new version before upgrading.
> Petri

More information about the Python-Dev mailing list