<story><title>Python 3.12.0 is to remove long-deprecated items</title><url>https://discuss.python.org/t/python-3-12-0-alpha-2-released/21087</url></story><parent_chain><item><author>nicoco</author><text>For a different perspective, I started using python about 5 years ago, and I &lt;i&gt;never&lt;/i&gt; experienced a single breakage due to a new python release. Instead, I&amp;#x27;m always excited to read new version releases notes and it&amp;#x27;s the only thing that &lt;i&gt;may&lt;/i&gt; make me move away from debian stable someday. But waiting a few months, using containers, or compiling a newer python is usually fine when I can&amp;#x27;t wait.&lt;p&gt;Removing deprecated stuff is… the point of deprecating stuff?</text></item><item><author>wakeupcall</author><text>I&amp;#x27;m normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I&amp;#x27;m not too vested in it.&lt;p&gt;For languages where I have 10+ years of work behind, it&amp;#x27;s the exact opposite, and where I see the c&amp;#x2F;c++ model of not breaking backward compatibility a much saner choice.&lt;p&gt;Python in particular is an extremely bittersweet pill to swallow. The amount of small and large breakage I had ever since I started to use it for production work (v2.6 and onward) has been relentless. Small and large breakages requiring constant retooling and reworking. Minor release? Yeah, still breaks just as much as a major one. pyenv doesn&amp;#x27;t help when you dependencies need to be updated, and the updates do not support the lower versions you wanted to use anyway. Containerizing everything is a not a solution for a project is expected to be supported for years so the real way forward is to fix it, again, and again, and again. My experience is that every 6 months there _will_ be work just to fix bitrotting. A one year old python project will hardly even run unless it&amp;#x27;s using the stdlib only.&lt;p&gt;By comparison, I never experienced such churn with perl.</text></item></parent_chain><comment><author>cogman10</author><text>&amp;gt; Removing deprecated stuff is… the point of deprecating stuff?&lt;p&gt;The point of deprecating stuff is to redirect to newer&amp;#x2F;better&amp;#x2F;saner APIs, not necessarily removing the thing.&lt;p&gt;This is where I like Java&amp;#x27;s approach.  Stuff is deprecated in the JDK but fairly rarely is it removed.  When it is, it&amp;#x27;s because the feature is either unused or so detrimental to the ecosystem as to warrant removal (see: finalizers).</text></comment>
<story><title>Python 3.12.0 is to remove long-deprecated items</title><url>https://discuss.python.org/t/python-3-12-0-alpha-2-released/21087</url></story><parent_chain><item><author>nicoco</author><text>For a different perspective, I started using python about 5 years ago, and I &lt;i&gt;never&lt;/i&gt; experienced a single breakage due to a new python release. Instead, I&amp;#x27;m always excited to read new version releases notes and it&amp;#x27;s the only thing that &lt;i&gt;may&lt;/i&gt; make me move away from debian stable someday. But waiting a few months, using containers, or compiling a newer python is usually fine when I can&amp;#x27;t wait.&lt;p&gt;Removing deprecated stuff is… the point of deprecating stuff?</text></item><item><author>wakeupcall</author><text>I&amp;#x27;m normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I&amp;#x27;m not too vested in it.&lt;p&gt;For languages where I have 10+ years of work behind, it&amp;#x27;s the exact opposite, and where I see the c&amp;#x2F;c++ model of not breaking backward compatibility a much saner choice.&lt;p&gt;Python in particular is an extremely bittersweet pill to swallow. The amount of small and large breakage I had ever since I started to use it for production work (v2.6 and onward) has been relentless. Small and large breakages requiring constant retooling and reworking. Minor release? Yeah, still breaks just as much as a major one. pyenv doesn&amp;#x27;t help when you dependencies need to be updated, and the updates do not support the lower versions you wanted to use anyway. Containerizing everything is a not a solution for a project is expected to be supported for years so the real way forward is to fix it, again, and again, and again. My experience is that every 6 months there _will_ be work just to fix bitrotting. A one year old python project will hardly even run unless it&amp;#x27;s using the stdlib only.&lt;p&gt;By comparison, I never experienced such churn with perl.</text></item></parent_chain><comment><author>leadingthenet</author><text>You should also look into pyenv if you&amp;#x27;d like to install newer versions sooner, outside a container.</text></comment>