Live data from Hacker News

PEP 594 – Removing dead batteries from the standard library

peps.python.org

1–10 of 95 posts

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

#6

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?

It is just unnecessary breakage for minuscule reward

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

#7

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* |
   awk '{ print $5 }' | paste -sd+ | bc
 877283
This excludes the "msilib" and "nis" packages, which aren't on my system (I guess my distro excludes them?), and you should also really round up the files to the disk block size (usually 4k), so let's round it up to 1M.

Is that significant? You decide. It doesn't seem all that significant to me given that the stdlib is 41M, so for space-constrained use-cases you're still not going to be able to copy/install all of the stdlib in the first place as it's still not even close to fitting on "devices with just a few hundred kilobyte of storage (e.g. BBC Micro:bit)" that the PEP mentions.

I do think that removing these packages is a good idea, but "space savings" seems like a very weak argument.

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

#8

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…

msilib and nis are probably Windows-only.

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

#9
post #6

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?

It is just unnecessary breakage for minuscule reward

>miniscule reward

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

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

#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.
Post reply on HN