<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 5:22 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">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>
</div>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></blockquote><div><br></div><div>Getting a little ahead of ourselves with defining what exactly Python 4 will be, but I have been thinking that if we take a "deprecated modules sit in Python 3 bitrotting until Python 4 for backwards-compatibility reasons" then I'm fine with that as that gives a long period of adjustment to the module going away. I just don't want any deprecated module to sit there forever. </div>

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