[Python-Dev] When to remove deprecated stuff

[MRAB]

On 15/08/2013 13:29, R. David Murray 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?
>
> 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?)
>
Talking of cruft, would that include these methods of the Thread class?

     getName()
     setName()
     isDaemon()
     setDaemon()