[Python-Dev] When to remove deprecated stuff (was: Deprecating the formatter module)

Ezio Melotti ezio.melotti at gmail.com
Thu Aug 15 15:15:50 CEST 2013


Hi,

On Thu, Aug 15, 2013 at 3:29 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Thu, 15 Aug 2013 11:16:20 +0200
>> Victor Stinner <victor.stinner at gmail.com> wrote:
>> > 2013/8/15 Antoine Pitrou <solipsis at pitrou.net>:
>> > > We don't have any substantial change in store for an eventual "Python
>> > > 4", so it's quite a remote hypothesis right now.
>> >
>> > I prefered the transition between Linux 2 and Linux 3 (no major
>> > change, just a "normal" release except the version), rather than the
>> > transition between KDE 3 and KDE 4 (in short, everything was broken,
>> > the desktop was not usable).
>> >
>> > I prefer to not start a list of things that we will make the
>> > transition from Python 3 to Python 4 harder. Can't we do small changes
>> > between each Python release, even between major versions?
>>
>> That's exactly what I'm saying.
>> But some changes cannot be made without breakage, e.g. the unicode
>> transition. Then it makes sense to bundle all breaking changes in a
>> single version change.
>
> A number of us (I don't know how many) have clearly been thinking about
> "Python 4" as the time when we remove cruft.  This will not cause any
> backward compatibility issues for anyone who has paid heed to the
> deprecation warnings, but will for those who haven't.  The question
> then becomes, is it better to "bundle" these removals into the
> Python 4 release, or do them incrementally?
>

A while ago I wrote an email to python-dev about our deprecation policy:
http://mail.python.org/pipermail/python-dev/2011-October/114199.html

My idea was to turn this into an informational PEP but I didn't
receive much feedback.
If people are interested I could still do it.

Best Regards,
Ezio Melotti

> If we are going to do them incrementally we should make that decision
> soonish, so that we don't end up having a whole bunch happen at once
> and defeat the (theoretical) purpose of doing them incrementally.
>
> (I say theoretical because what is the purpose?  To spread out the
> breakage pain over multiple releases, so that every release breaks
> something?)
>
> --David


More information about the Python-Dev mailing list