PEP 594 – Removing dead batteries from the standard library • Hacker News Board

Re: PEP 594 – Removing dead batteries from the standard library

#21

Post by qbasic_forever » Mon, Mar 14, 2022, 5:31 PM UTC

nrclark wrote: post #16

There are some things on the list that I totally get. We probably don't need support for .aif files in Python's stdlib, or support for the Sun directory service. But I hate to see these get removed: - cgi - pipes - uu - telnetlib A lot of people still use CGI. Yes, it's slow / low-performance / etc. It's also a perfectly fine way to make a knockabout internal service. Pipes is a small pure-Python module, with nothing…

Nothing is stopping those libraries from being in a new 'legacy internet' package that motivated folks can maintain on pypi.

Re: PEP 594 – Removing dead batteries from the standard library

#22

Post by phkahler » Mon, Mar 14, 2022, 5:34 PM UTC

johndfsgdgdfg wrote: post #13

adtac wrote: post #9

Earlier quoted context omitted.

>miniscule reward how so? I see lower maintenance burden and vulnerability surface area as big rewards

Internet is full of entitled narcissistic people. They can't imagine there're other important things in the world beside themselves and their needs.

>> Internet is full of entitled narcissistic people. They can't imagine there're other important things in the world beside themselves and their needs.

I completely agree with you, but I'm not sure which side of the dead batteries debate you're supporting with it! ;-)

Re: PEP 594 – Removing dead batteries from the standard library

#23

Post by Someone » Mon, Mar 14, 2022, 5:35 PM UTC

Beltalowda wrote: post #7

CameronNemo wrote: post #5

They mention that one reason to remove these modules is storage savings, but then there is no information about how much storage will be freed up by their removal... Anyone have an idea if it is significant?

On my system right now: % du -h --exclude=site-packages /usr/lib/python3.10 | tail -n1 41M /usr/lib/python3.10 The amount of savings seems to be about 0.83M: % ls -l \ **/*aifc* \ **/*asynchat* \ **/*asyncore* \ \ **/*cgi* \ **/*cgitb* \ **/*chunk* \ **/*crypt* \ **/*imghdr* \ **/*nntplib* \ **/*ossaudiodev* \ **/*pipes* \ **/*smtpd* \ **/*sndhdr* \ **/*spwd* \ **/*sunau* \ **/*telnetlib* \ **/*uu* \ **/*xdrlib* | aw…

> you should also really round up the files to the disk block size (usually 4k), so let's round it up to 1M.

A decent first-go model for the amount of bytes to add is half a block per file. You’re adding about 168kB. That model would predict that for 84 files. I guess there are quite a few more in those (at least) 18 directories.

Re: PEP 594 – Removing dead batteries from the standard library

#24

Post by mjw1007 » Mon, Mar 14, 2022, 5:36 PM UTC

nrclark wrote: post #16

There are some things on the list that I totally get. We probably don't need support for .aif files in Python's stdlib, or support for the Sun directory service. But I hate to see these get removed: - cgi - pipes - uu - telnetlib A lot of people still use CGI. Yes, it's slow / low-performance / etc. It's also a perfectly fine way to make a knockabout internal service. Pipes is a small pure-Python module, with nothing…

The cgi module didn't actually contain the Python standard library's CGI support. That's in wsgiref.handlers.CGIHandler, and isn't going away.

What the cgi module did contain was some occasionally-useful support for working with HTML forms. As far as I can tell they're throwing that away for no good reason.

Re: PEP 594 – Removing dead batteries from the standard library

#25

Post by tofflos » Mon, Mar 14, 2022, 5:37 PM UTC

at_a_remove wrote: post #11

I find the reasoning to be ... flawed. "Any additional module increases the maintenance cost for the Python core development team. The team has limited resources, reduced maintenance cost frees development time for other improvements." This really doesn't jibe with the "Hey guys we have tools to convert 2 to 3 so easily" and "we aren't breaking stuff." A good working library will continue to be a good working library…

> Second, why do we want a community-contributed module to be widely used? That's stated as a goal but without explanation. If there is a widely used community-contributed module that is better, put it in the standard library.

I think the reasoning is that offering a flawed version in the standard library can prevent an alternative from being written and gaining adoption.

Re: PEP 594 – Removing dead batteries from the standard library

#26

Post by moltke » Mon, Mar 14, 2022, 5:40 PM UTC

nrclark wrote: post #16

There are some things on the list that I totally get. We probably don't need support for .aif files in Python's stdlib, or support for the Sun directory service. But I hate to see these get removed: - cgi - pipes - uu - telnetlib A lot of people still use CGI. Yes, it's slow / low-performance / etc. It's also a perfectly fine way to make a knockabout internal service. Pipes is a small pure-Python module, with nothing…

Meh. CGI was one of the easier to consume interfaces that is really not hard to rebuild from scratch. I suppose it makes sense that python has (or had I guess) a library for it but it's really not necessary. Enough of the primitives are there. Those that need it could easily write a shim.

It does make you wonder why it was removed though. I can't imagine it was difficult to maintain.

Re: PEP 594 – Removing dead batteries from the standard library

#27

Post by kstrauser » Mon, Mar 14, 2022, 5:40 PM UTC

tofflos wrote: post #25

at_a_remove wrote: post #11

I find the reasoning to be ... flawed. "Any additional module increases the maintenance cost for the Python core development team. The team has limited resources, reduced maintenance cost frees development time for other improvements." This really doesn't jibe with the "Hey guys we have tools to convert 2 to 3 so easily" and "we aren't breaking stuff." A good working library will continue to be a good working library…

> Second, why do we want a community-contributed module to be widely used? That's stated as a goal but without explanation. If there is a widely used community-contributed module that is better, put it in the standard library. I think the reasoning is that offering a flawed version in the standard library can prevent an alternative from being written and gaining adoption.

I think that's it. If you haven't heard of Requests, you might re-implement it yourself from the standard library. That's totally possible (and I had to do that back in the dark days before Requests and pip), but not something most people should be doing.

Re: PEP 594 – Removing dead batteries from the standard library

#28

Post by ammar2 » Mon, Mar 14, 2022, 5:43 PM UTC

at_a_remove wrote: post #11

I find the reasoning to be ... flawed. "Any additional module increases the maintenance cost for the Python core development team. The team has limited resources, reduced maintenance cost frees development time for other improvements." This really doesn't jibe with the "Hey guys we have tools to convert 2 to 3 so easily" and "we aren't breaking stuff." A good working library will continue to be a good working library…

> A good working library will continue to be a good working library until you break it.

This isn't necessarily true, it depends on what the library is targeting. Sure, you could try to use a libcurl 7.9 from 2001 but there's going to be security bugs abound and it's going to be a pain to send verbs like PUT that some APIs expect. Standards, security concerns and paradigms change over time and can easily break good working libraries that are unmaintained.

However, things like a json parser and writer are relatively stable and don't need many changes over time because of the stability of the format.

Re: PEP 594 – Removing dead batteries from the standard library

#29

Post by immibis » Mon, Mar 14, 2022, 5:48 PM UTC

amoe_ wrote: post #10

I don't have any data on it, but I'd speculate that CGI is still fairly widely used. Though how widely it's used with Python is another issue. Regardless of how poorly designed the cgi module is, removing it without providing a one-module migration path in PyPI doesn't seem like an obvious win.

CGI is a very useful way to throw a random script on a low-traffic webserver.

Re: PEP 594 – Removing dead batteries from the standard library

#30

Post by loloquwowndueo » Mon, Mar 14, 2022, 5:51 PM UTC

AdmiralAsshat wrote: post #20

If they're deprecating part of the stdlib where a third-party lib is favored (e.g. 'lxml' instead of 'xml', per the article), will they be bringing the third-party module into the core stdlib?

They are not deprecating xml.