<story><title>Pip has dropped support for Python 2</title><url>https://pip.pypa.io/en/stable/news/#id1</url></story><parent_chain><item><author>orf</author><text>&amp;gt; The minor improvements of Python 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives.&lt;p&gt;There where large changes to fundamental parts of the type system, as well as core types. Pretending this isn’t the case belays ignorance or at the very least cherry picking.&lt;p&gt;How would you have handled the string&amp;#x2F;bytes split in a way that’s backwards compatible? Or the removal of old-style classes?</text></item><item><author>Blikkentrekker</author><text>Hindsight might very well be easy in this case, but I cannot think otherwise than finding the &lt;i&gt;Python&lt;/i&gt; developers to have been ridiculously naïve in how they handled this, and foolish to even begin it from the start.&lt;p&gt;The minor improvements of &lt;i&gt;Python&lt;/i&gt; 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives.&lt;p&gt;The very swarms of users that chanted “just upgrade” as if that not incur a significant cost also seemed ridiculously naïve to me, not understanding the real cost that large projects have by having to rewrite very extensive codebases and dealing the potential regressions that that might involve.&lt;p&gt;Everything about the switch, from it&amp;#x27;s very conception, to it&amp;#x27;s execution, was handled in a veritably disastrous way by the team, that really did not seem to appreciate even a fraction of what obviously is involved with projects that have millions of lines of code and of course would rather not have to rewrite that all.&lt;p&gt;This is why many projects such as &lt;i&gt;Linux&lt;/i&gt;, &lt;i&gt;Windows&lt;/i&gt;, &lt;i&gt;Rust&lt;/i&gt;, &lt;i&gt;Cobol&lt;/i&gt;, &lt;i&gt;Fortran&lt;/i&gt;, &lt;i&gt;C&lt;/i&gt;, and &lt;i&gt;C++&lt;/i&gt; take backwards compatibility quite serious. Serious enterprises do not like to invest in something if it mean that 10 years later they would have to rewrite their entire codebase again.&lt;p&gt;Even on my home computer, I simply do not have the time to rewrite the many &lt;i&gt;Python&lt;/i&gt; 2 scripts that have written over the years that run my computer. — it is cumbersome enough that once in a while part of my desktop stops functioning because my distribution removed a &lt;i&gt;Python&lt;/i&gt; 2 library which I had relied upon as a system library that I now have to install as a user library but that was hitherto quite easily fixed.&lt;p&gt;Do these men think that time is free?</text></item><item><author>oconnor663</author><text>I think a lot of important lessons got learned in both cases. Clearly perl6 should have had a different name. But I think python2-&amp;gt;python3 could&amp;#x27;ve been much less painful if they&amp;#x27;d known to prioritize single-codebase compatibility from the very beginning. I think you can see that lesson applied with e.g. Rust editions, which as far as I can tell have been a complete success.</text></item><item><author>ChuckMcM</author><text>This is awesome in terms of avoiding all of the weird things when a person typed pip rather than pip3 and module didn&amp;#x27;t seem to get installed anywhere. That said, watching perl trying to kill perl5 with perl6 (unsuccessful) and python trying to kill python 2 with python 3 (more successful) it struck me how ridiculous it is that open source languages have to put up with this. Clearly &amp;quot;major&amp;quot; numbers are insufficient, the only real answer is to rename the entire freaking language when you make incompatible changes to it.</text></item></parent_chain><comment><author>naniwaduni</author><text>Let&amp;#x27;s not pretend that py3&amp;#x27;s string changes weren&amp;#x27;t &lt;i&gt;fundamentally wrong&lt;/i&gt; and didn&amp;#x27;t create years of issues trying to decode things that could properly be arbitrary byte sacks as utf-8.&lt;p&gt;So my answer is that it was a deeply misconceived change that shouldn&amp;#x27;t have been made at all, let alone been taken as the cornerstone of a &amp;quot;necessary&amp;quot; break in backward compatibility.</text></comment>
<story><title>Pip has dropped support for Python 2</title><url>https://pip.pypa.io/en/stable/news/#id1</url></story><parent_chain><item><author>orf</author><text>&amp;gt; The minor improvements of Python 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives.&lt;p&gt;There where large changes to fundamental parts of the type system, as well as core types. Pretending this isn’t the case belays ignorance or at the very least cherry picking.&lt;p&gt;How would you have handled the string&amp;#x2F;bytes split in a way that’s backwards compatible? Or the removal of old-style classes?</text></item><item><author>Blikkentrekker</author><text>Hindsight might very well be easy in this case, but I cannot think otherwise than finding the &lt;i&gt;Python&lt;/i&gt; developers to have been ridiculously naïve in how they handled this, and foolish to even begin it from the start.&lt;p&gt;The minor improvements of &lt;i&gt;Python&lt;/i&gt; 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives.&lt;p&gt;The very swarms of users that chanted “just upgrade” as if that not incur a significant cost also seemed ridiculously naïve to me, not understanding the real cost that large projects have by having to rewrite very extensive codebases and dealing the potential regressions that that might involve.&lt;p&gt;Everything about the switch, from it&amp;#x27;s very conception, to it&amp;#x27;s execution, was handled in a veritably disastrous way by the team, that really did not seem to appreciate even a fraction of what obviously is involved with projects that have millions of lines of code and of course would rather not have to rewrite that all.&lt;p&gt;This is why many projects such as &lt;i&gt;Linux&lt;/i&gt;, &lt;i&gt;Windows&lt;/i&gt;, &lt;i&gt;Rust&lt;/i&gt;, &lt;i&gt;Cobol&lt;/i&gt;, &lt;i&gt;Fortran&lt;/i&gt;, &lt;i&gt;C&lt;/i&gt;, and &lt;i&gt;C++&lt;/i&gt; take backwards compatibility quite serious. Serious enterprises do not like to invest in something if it mean that 10 years later they would have to rewrite their entire codebase again.&lt;p&gt;Even on my home computer, I simply do not have the time to rewrite the many &lt;i&gt;Python&lt;/i&gt; 2 scripts that have written over the years that run my computer. — it is cumbersome enough that once in a while part of my desktop stops functioning because my distribution removed a &lt;i&gt;Python&lt;/i&gt; 2 library which I had relied upon as a system library that I now have to install as a user library but that was hitherto quite easily fixed.&lt;p&gt;Do these men think that time is free?</text></item><item><author>oconnor663</author><text>I think a lot of important lessons got learned in both cases. Clearly perl6 should have had a different name. But I think python2-&amp;gt;python3 could&amp;#x27;ve been much less painful if they&amp;#x27;d known to prioritize single-codebase compatibility from the very beginning. I think you can see that lesson applied with e.g. Rust editions, which as far as I can tell have been a complete success.</text></item><item><author>ChuckMcM</author><text>This is awesome in terms of avoiding all of the weird things when a person typed pip rather than pip3 and module didn&amp;#x27;t seem to get installed anywhere. That said, watching perl trying to kill perl5 with perl6 (unsuccessful) and python trying to kill python 2 with python 3 (more successful) it struck me how ridiculous it is that open source languages have to put up with this. Clearly &amp;quot;major&amp;quot; numbers are insufficient, the only real answer is to rename the entire freaking language when you make incompatible changes to it.</text></item></parent_chain><comment><author>Blikkentrekker</author><text>&amp;gt; &lt;i&gt;How would you have handled the string&amp;#x2F;bytes split in a way that’s backwards compatible?&lt;/i&gt;&lt;p&gt;A language pragma.&lt;p&gt;All functions that return `bytes` continue to do so unless specifically opted in on a per file basis, then they return `unicode`.&lt;p&gt;`str` thus returns `bytes` as it does in 2, unless the pragma ask otherwise.&lt;p&gt;&amp;gt; &lt;i&gt;Or the removal of old-style classes?&lt;/i&gt;&lt;p&gt;They would obviously not be removed and still be available but depræcated.</text></comment>