[Python-Dev] When to remove deprecated stuff

[Ezio Melotti]

On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>>
>> On 22 Aug 2013, at 14:00, Petri Lehtinen <petri at digip.org> wrote:
>> >
>> > 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. 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.
>> >
>>
>> So you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult?
>>
>> Why not check for the deprecation warnings?
>
> Doing so makes very little difference.
>
> This is my opinion (others obviously differ):
>
> Putting in one big chunk of effort at a major release boundary is easier
> to schedule than putting in a chunk of effort on *every* feature
> release.

IMHO there is a third (and better option) that you are missing.

Assume I'm using A.B, and see some DeprecationWarnings.  Now I have at
least 1.5 years to fix them before A.B+1 is released, and once that
happens there shouldn't be any warnings left so I can upgrade
successfully.  Once I do, more warnings will pop up, but then again I
will have 1.5+ years to fix them.

It seems to me that the problem only arises when the developers ignore
(or possibly are unaware of) the warnings until it's time to upgrade.

> More importantly, having it happen only at the major release
> boundary means there's only one hard deadline every ten-ish years, rather
> than a hard deadline every 1.5 years.
>
> [...]
>
> How does one judge what the optimal amount of change is?
>
> It would be great if we could figure out how to figure out what the
> users want.  We more or less have one user opinion so far, from Petri,
> based on his experience as a Django user.  We developers are also users,
> of course, but our opinions are colored by our needs as developers as
> well, so we aren't reliable judges.

As I see it there are 3 groups:
1) developers writing libraries/frameworks/interpreters;
2) developers using these libraries/frameworks/interpreters;
3) end users using the applications wrote by the developers.

The first group is responsible of warning the second group of the
things that got deprecated and give them enough time to update their
code.
The second group is responsible to listen to the warnings and update
their code accordingly.
The third group is responsible to sit back and enjoy our hard work
without seeing warnings/errors.

Best Regards,
Ezio Melotti

>
> --David
>
> PS: When thinking about this, remember that our effective policy for
> (the second half of?) Python2 was to hold all the big cruft removal until
> Python3.  Even some stuff that was originally scheduled to be removed
> sooner got left in.  So our user base is currently used to things being
> pretty stable from a deprecation/backward compatibility standpoint.