<story><title>PEP 594 – Removing dead batteries from the standard library</title><url>https://peps.python.org/pep-0594/</url></story><parent_chain><item><author>nrclark</author><text>There are some things on the list that I totally get. We probably don&amp;#x27;t need support for .aif files in Python&amp;#x27;s stdlib, or support for the Sun directory service.&lt;p&gt;But I hate to see these get removed:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    - cgi
    - pipes
    - uu
    - telnetlib
&lt;/code&gt;&lt;/pre&gt;
A lot of people still use CGI. Yes, it&amp;#x27;s slow &amp;#x2F; low-performance &amp;#x2F; etc. It&amp;#x27;s also a perfectly fine way to make a knockabout internal service.&lt;p&gt;Pipes is a small pure-Python module, with nothing tricky about it. Why delete it? It&amp;#x27;s good at what it does. Subprocess equivalents are a lot more effort to write, even if you can eventually get to the same result.&lt;p&gt;Uu is old, yes. But it&amp;#x27;s not broken either. Folks do still uuencode things from time to time. Why delete it?&lt;p&gt;Telnetlib is personally useful to me, since telnet is one of the easiest ways to interact with a qemu VM&amp;#x27;s console. I hate that the answer is &amp;quot;Use something on Pypi instead&amp;quot;, because that increases my dependency surface and adds no value for me. Why delete working, stable code?</text></item></parent_chain><comment><author>ciupicri</author><text>For uuencode migrate to &lt;i&gt;a2b_uu&lt;/i&gt; and &lt;i&gt;b2a_uu&lt;/i&gt; from the &lt;i&gt;binascii&lt;/i&gt; standard module.&lt;p&gt;[a2b_uu]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;3&amp;#x2F;library&amp;#x2F;binascii.html#binascii.a2b_uu&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;3&amp;#x2F;library&amp;#x2F;binascii.html#binascii.a2b...&lt;/a&gt;&lt;p&gt;[b2a_uu]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;3&amp;#x2F;library&amp;#x2F;binascii.html#binascii.b2a_uu&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.python.org&amp;#x2F;3&amp;#x2F;library&amp;#x2F;binascii.html#binascii.b2a...&lt;/a&gt;</text></comment>
<story><title>PEP 594 – Removing dead batteries from the standard library</title><url>https://peps.python.org/pep-0594/</url></story><parent_chain><item><author>nrclark</author><text>There are some things on the list that I totally get. We probably don&amp;#x27;t need support for .aif files in Python&amp;#x27;s stdlib, or support for the Sun directory service.&lt;p&gt;But I hate to see these get removed:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    - cgi
    - pipes
    - uu
    - telnetlib
&lt;/code&gt;&lt;/pre&gt;
A lot of people still use CGI. Yes, it&amp;#x27;s slow &amp;#x2F; low-performance &amp;#x2F; etc. It&amp;#x27;s also a perfectly fine way to make a knockabout internal service.&lt;p&gt;Pipes is a small pure-Python module, with nothing tricky about it. Why delete it? It&amp;#x27;s good at what it does. Subprocess equivalents are a lot more effort to write, even if you can eventually get to the same result.&lt;p&gt;Uu is old, yes. But it&amp;#x27;s not broken either. Folks do still uuencode things from time to time. Why delete it?&lt;p&gt;Telnetlib is personally useful to me, since telnet is one of the easiest ways to interact with a qemu VM&amp;#x27;s console. I hate that the answer is &amp;quot;Use something on Pypi instead&amp;quot;, because that increases my dependency surface and adds no value for me. Why delete working, stable code?</text></item></parent_chain><comment><author>qbasic_forever</author><text>Nothing is stopping those libraries from being in a new &amp;#x27;legacy internet&amp;#x27; package that motivated folks can maintain on pypi.</text></comment>