<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 8:29 AM, R. David Murray <span dir="ltr"><<a href="mailto:rdmurray@bitdance.com" target="_blank">rdmurray@bitdance.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>


> On Thu, 15 Aug 2013 11:16:20 +0200<br>
> Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br>
> > 2013/8/15 Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>>:<br>
> > > We don't have any substantial change in store for an eventual "Python<br>
> > > 4", so it's quite a remote hypothesis right now.<br>
> ><br>
> > I prefered the transition between Linux 2 and Linux 3 (no major<br>
> > change, just a "normal" release except the version), rather than the<br>
> > transition between KDE 3 and KDE 4 (in short, everything was broken,<br>
> > the desktop was not usable).<br>
> ><br>
> > I prefer to not start a list of things that we will make the<br>
> > transition from Python 3 to Python 4 harder. Can't we do small changes<br>
> > between each Python release, even between major versions?<br>
><br>
> That's exactly what I'm saying.<br>
> But some changes cannot be made without breakage, e.g. the unicode<br>
> transition. Then it makes sense to bundle all breaking changes in a<br>
> single version change.<br>
<br>
A number of us (I don't know how many) have clearly been thinking about<br>
"Python 4" as the time when we remove cruft.  This will not cause any<br>
backward compatibility issues for anyone who has paid heed to the<br>
deprecation warnings, but will for those who haven't.  The question<br>
then becomes, is it better to "bundle" these removals into the<br>
Python 4 release, or do them incrementally?<br>
<br>
If we are going to do them incrementally we should make that decision<br>
soonish, so that we don't end up having a whole bunch happen at once<br>
and defeat the (theoretical) purpose of doing them incrementally.<br>
<br>
(I say theoretical because what is the purpose?  To spread out the<br>
breakage pain over multiple releases, so that every release breaks<br>
something?)<br></blockquote><div><br></div><div>Incremental has one benefit, and that's we get to completely stop caring sooner. =) By completely removing the module sooner lessens the chance of errant bug reports, etc.</div>

<div><br></div><div>Doing the removal en-masse at massive release boundaries is that compatibility for the stdlib can be stated as "Python 3" instead of "Python 3.3 and older" for those that continue to rely on the older modules.</div>

<div><br></div><div>I also don't know if we would want to extend this to intra-module objects as well (e.g. classes). In which case we would need to clearly state that anything deprecated is considered dead and under active bitrot and so do not expect it to necessarily work with the rest of the module (e.g. new APIs to work with the deprecated ones).</div>

</div></div></div>