7 ms·

PEP 594 – Removing dead batteries from the standard library

170 points by williamsmj 5y ago

ptx 5y ago
> A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage (e.g. BBC Micro:bit). It probably would, but the standard library is never going to be reduced to that size (I hope!), so how do these removals benefit those devices?
jjgreen 5y ago
Dead link: try https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/
- tlb 5y ago
  Fixed, thanks.
afandian 5y ago
CGI module deprecated. That got me strongly in the nostalgia.
CameronNemo 5y ago
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?
- d0mine 5y ago
  It is just unnecessary breakage for minuscule reward
  - adtac 5y ago
    >miniscule reward how so? I see lower maintenance burden and vulnerability surface area as big rewards
    - johndfsgdgdfg 5y ago
      Internet is full of entitled narcissistic people. They can't imagine there're other important things in the world beside themselves and their needs.
      - phkahler 5y ago
        >> 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! ;-)
- Beltalowda 5y ago
  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.
  - loeg 5y ago
    msilib and nis are probably Windows-only.
    - jandrese 5y ago
      NIS is definitely not a Windows thing. Maybe the python module would appear if you installed NIS support on your system?
      - loeg 5y ago
        Oh, you're right. I was thinking NDIS for some reason. Probably the distribution does not support NIS and/or does not enable it in their Python builds.
  - Someone 5y ago
    > 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.
amoe_ 5y ago
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.
- immibis 5y ago
  CGI is a very useful way to throw a random script on a low-traffic webserver.
at_a_remove 5y ago
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 until you break it. "Modules in the standard library are generally favored and seen as the de facto solution for a problem. A majority of users only pick third-party modules to replace a stdlib module, when they have a compelling reason, e.g. lxml instead of xml. The removal of an unmaintained stdlib module increases the chances of a community-contributed module to become widely used." First, part of the appeal of Python is that de facto standard. Recall all of the XKCD comics about it. I don't have to make choices about which of seventeen different Perl libraries I can maybe find that exist on CPAN and try to decide between them. This is one of the reasons why I fled Perl. 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 could almost like "A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage ..." except that there ought to be a mechanism for cutting parts out of the standard library anyway if they aren't being used by your particular space-starved platform. This doesn't actually solve the problem being posed. It isn't the sunau module that is making or breaking the memory budget -- find a way to dis-include unused stdlib modules for projects. Listen to this: "The crypt module has fundamental flaws that are better solved outside the standard library." So either fix them or move whatever is being used into the standard library. Now, we can quibble about individual modules (I am rather fond of cgi, it's just so damned handy if you want to make something small without hauling in entire frameworks), but that misses the point -- the standard library exists to free us from the burden of sifting through N implementations of whatever it is we want to solve, where the complete coverage of the issue varies from "the happy path" to "eighty percent of the problem but sadly you need to do work in the twenty percent not covered."
- tofflos 5y ago
  > 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.
cuteboy19 5y ago
It might be better to upload all the modules to PyPI as third party repos. Maybe hand it off to some third party maintainers. This way if import cgi fails then you can at least pip install cgi to fix that
- oblvious-earth 5y ago
  No one has stepped up to maintain them in the standard library so who do they hand them over to maintain outside the standard library? This code is all open source, literally anyone could step up and do it themselves if they had the motivation.
codedokode 5y ago
I don't understand the motivation to remove MSI support. The document says: > Microsoft is slowly moving away from MSI in favor of Windows 10 Apps (AppX) as a new deployment model First, MSI has better OS support than AppX, second, many users are still using Windows 7 and won't be able to use AppX. MSI is not some 30-years old deprecated standard.
- AdamN 5y ago
  This PEP doesn't really stop functionality for nearly 3 years and even then it's only with the newest Python version so people can stay on the older version for another 2-3 years of further transition fully supported by the Python community. In 5 years, Windows 10 will be the bare minimum for a secure OS from MS.
- qbasic_forever 5y ago
  Why can't legacy MSI support be a standalone library? It looks like no one is maintaining it right now anyways so that should be some red flags right there.
- mananaysiempre 5y ago
  FWIW, CPython officially follows Microsoft’s support schedule on Windows systems, so versions ≥ 3.9 won’t even install on Windows 7. (Some reasonable people like it and some don’t, but this has been the official stance for a long time.) As for MSI, I’m torn: it is the most widely-supported and reliable packaging approach for Windows and, at the same time, a 20-year-old undocumented dumpster fire of an archive format spliced together with a scripting language forced into the mold of an allegedly-SQL relational database for which it is the sole user, and I can’t really find it in myself to blame Microsoft for wanting to kill that. (At the same time, they also cheerfully promote an admittedly documented 10-year-old metadata format [WinMD] grafted onto a bytecode+metadata format for a different platform [.NET] packed into a Win32 executable format [PE] that is built upon an early and obsolete SysV object file format [COFF] with a stub executable for DOS [MZ] prepended in contravention of the original spec—as a substitute for a 30-year-old undocumented metadata format [TLB] that is actually two different incompatible formats [SLGT or MSFT] but at least doesn’t have so many layers, so I can’t exactly promote them as a shining beacon of logic and sanity either.)
nrclark 5y ago
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 tricky about it. Why delete it? It'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. Uu is old, yes. But it's not broken either. Folks do still uuencode things from time to time. Why delete it? Telnetlib is personally useful to me, since telnet is one of the easiest ways to interact with a qemu VM's console. I hate that the answer is "Use something on Pypi instead", because that increases my dependency surface and adds no value for me. Why delete working, stable code?
- qbasic_forever 5y ago
  Nothing is stopping those libraries from being in a new 'legacy internet' package that motivated folks can maintain on pypi.
  - nrclark 5y ago
    You're right, nothing is stopping anybody from putting these modules on Pypi. If somebody's already using Pypi dependencies, then another is no big deal. But there's a really big jump from "This tool is self-contained" to "This tool needs X from pypi". It ripples into deployment, source-control, everything. I try very hard to make tools that don't need anything except for Python's stdlib. That's based on a perception of trust: that the stdlib will be supported, and represents Python's only stable dependency. Once the team starts to erode that trust, Python's compatibility story will start to break.
    - qbasic_forever 5y ago
      cgi, nntp, telnet, etc. are old and obsolete. And not just in the 5 years out of fashion/not the trendy new thing--these things are decades out of date and have major or glaring security issues, etc. If you're publishing brand new code in 2022 that still depends on python's built-in cgi support, etc. you have far greater problems than having to pull in a third party dependency now. Python changes in breaking ways--just look at the python 2 to 3 change. You will have to learn to deal with it. There is no explicit guarantee that python will continue to work in exactly the way it has always worked for you forever.
renewiltord 5y ago
Surprised the ones without a replacement don't have PyPI modules available. I'm sure some enterprising fellow will simply extract the code and switch it into a PyPI module.
AdmiralAsshat 5y ago
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?
- loloquwowndueo 5y ago
  They are not deprecating xml.
tablespoon 5y ago
> For example, least controversial are 30-year-old multimedia formats like the sunau audio format, which was used on SPARC and NeXT workstations in the late 1980s Why would something like that add maintenance burden to the Python devs? I'd expect such code to be very, very stable.
- michaelt 5y ago
  Many software projects impose targets on themselves for things like 'software quality' that involves even stable code being checked and changed. For example, maybe they've received reports the code has bugs, but nobody thinks fixing is a good use of maintainers' time - or with such an old format, maybe no-one even knows what the correct behaviour should be. Maybe they have decided all file loading and network-interaction code should be fuzz-tested for security bugs. Or that every such module should have at least x% unit test coverage. Perhaps the the code uses deprecated methods and needs to be modernised. Or maybe they simply feel every file ought to have an owner, and nobody trusted has stepped up.
somat 5y ago
I feel that every release, the python team should do some soul searching and pick 5 modules to downgrade to external package(pypi) status, then pick 5 deserving external packages and elevate them to base status. This would, for one, add a bit of churn to the standard library leading to a more healthy ecosystem. And two, give everyone a target to complain about, I mean, people are going to complain about something, might as well focus their attention.
- jphoward 5y ago
  Because dependency hell isn't dreadful enough? Some entries will be completely missing from requirements.txt because the person assumes a certain version of python is present.
- overgard 5y ago
  That would make upgrading the interpreter version terrifying
- MengerSponge 5y ago
  Furthermore, imagine the joy of a package winning the Premier League just a year after returning from relegation?
- selfhoster11 5y ago
  That would result in a mini-Python 2/3 catastrophe every release. No, thank you. Maybe that's acceptable when you're the author of a piece of software, but as an ops engineer, that prospect makes my hair stand on end.
- oblvious-earth 5y ago
  Very few modules in the standard library actually get deprecated, that's why this PEP got put together. It also took 3 years of discussion to achieve consensus and the initial list was whittled down quite a bit and the reasoning became much stronger on the final list. And these aren't even being removed until Python 3.13! The SC have also said this is a one time event and they won't accept a similar PEP in the future, modules in the future most be handled on a case by case basis and the preferred outcome will not be to remove them.
dnsco 5y ago
> Post-History 21-May-2019, 04-Feb-2022 I would express all of the concerns being expressed here were debated ad nauseam over the three year political process of getting this proposal accepted. If you want to vent your fears and frustrations in a hopefully more productive way, you can get involved in Python's process. All that is to say, I'm thankful that the Python community gets things done, and people are willing to go through three year processes for changes such as this.
- williamsmj 5y ago
  Agreed. I also want to highlight these packages will be part of the stdlib for python 3.12, which will EOL in October 2028. In other words, if this change will affect you then you have up to 6.5 years to figure out and implement a plan.
- oblvious-earth 5y ago
  I am happy that people like Brett Cannon are in the Python Core Dev team getting things moving along. For reference here is the first discussions: https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704 https://discuss.python.org/t/pep-594-removing-dead-batteries... and https://mail.python.org/archives/list/python-dev@python.org/thread/NRSGCZKKICMR5DAF454I7CV3NWHGMU2Q/#KURMNB3JJDPI6DKLWOQ3HSW3PGUT7N3T https://mail.python.org/archives/list/python-dev@python.org/... And nearly 3 years later here is the second discussion: https://discuss.python.org/t/pep-594-take-2-removing-dead-batteries-from-the-standard-library/13508 https://discuss.python.org/t/pep-594-take-2-removing-dead-ba... I thought that feedback from the first discussion was carefully considered and I'm pretty happy with take 2. I have used the some of the modules being removed but largely agree now they are either legacy or there are significantly better third party options.
karmanyaahm 5y ago
As someone who has simple Python code for a CGI service that runs a couple of time a day (Golang vanity URL thing), that's disappointing. Maybe I'll rewrite it in Go to improve performance even more.
- recov 5y ago
  Virtually 0 chance of the functionality form Go being removed if you do.
pgcj_poster 5y ago
> CGI is deemed as inefficient because every incoming request is handled in a new process. This is why I keep every program I use on my laptop running in the background at all times. Imagine having to wait for a process to start before you can use it.
shadowofneptune 5y ago
It's good to see this happen. One concern I have with Python is that its standard library is large enough to make reimplementation impractical. It even requires another language, TCL, to be included. Python could be bound to CPython forever. Removing the 'dead batteries' should help somewhat with this problem.
mleonhard 5y ago
I'm happy to see old stuff removed. It frees up precious resources for better technologies.
exabrial 5y ago
I'm genuinely curious to see how this goes as a lot of languages have the same dead-battery problem. In Java for instance, StringBuffer and StringBuilder offer a very similar interface but one offers locking. Nowadays, most locking concerns are left to the caller, not the called. HashTable/HashMap are another example... The nice thing is, old libraries "just work". Java is trying to hide older parts of the API with Modules, and it remains to be seen whether or not this solution will take off and it will be adopted into other languages.

170 points by williamsmj 5y ago

ptx 5y ago

> A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage (e.g. BBC Micro:bit). It probably would, but the standard library is never going to be reduced to that size (I hope!), so how do these removals benefit those devices?

jjgreen 5y ago

Dead link: try https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/

tlb 5y ago
Fixed, thanks.

afandian 5y ago

CGI module deprecated. That got me strongly in the nostalgia.

CameronNemo 5y ago

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?

d0mine 5y ago
It is just unnecessary breakage for minuscule reward
- adtac 5y ago
  >miniscule reward how so? I see lower maintenance burden and vulnerability surface area as big rewards
  - johndfsgdgdfg 5y ago
    Internet is full of entitled narcissistic people. They can't imagine there're other important things in the world beside themselves and their needs.
    - phkahler 5y ago
      >> 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! ;-)
Beltalowda 5y ago
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.
- loeg 5y ago
  msilib and nis are probably Windows-only.
  - jandrese 5y ago
    NIS is definitely not a Windows thing. Maybe the python module would appear if you installed NIS support on your system?
    - loeg 5y ago
      Oh, you're right. I was thinking NDIS for some reason. Probably the distribution does not support NIS and/or does not enable it in their Python builds.
- Someone 5y ago
  > 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.

amoe_ 5y ago

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.

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

at_a_remove 5y ago

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 until you break it. "Modules in the standard library are generally favored and seen as the de facto solution for a problem. A majority of users only pick third-party modules to replace a stdlib module, when they have a compelling reason, e.g. lxml instead of xml. The removal of an unmaintained stdlib module increases the chances of a community-contributed module to become widely used." First, part of the appeal of Python is that de facto standard. Recall all of the XKCD comics about it. I don't have to make choices about which of seventeen different Perl libraries I can maybe find that exist on CPAN and try to decide between them. This is one of the reasons why I fled Perl. 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 could almost like "A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage ..." except that there ought to be a mechanism for cutting parts out of the standard library anyway if they aren't being used by your particular space-starved platform. This doesn't actually solve the problem being posed. It isn't the sunau module that is making or breaking the memory budget -- find a way to dis-include unused stdlib modules for projects. Listen to this: "The crypt module has fundamental flaws that are better solved outside the standard library." So either fix them or move whatever is being used into the standard library. Now, we can quibble about individual modules (I am rather fond of cgi, it's just so damned handy if you want to make something small without hauling in entire frameworks), but that misses the point -- the standard library exists to free us from the burden of sifting through N implementations of whatever it is we want to solve, where the complete coverage of the issue varies from "the happy path" to "eighty percent of the problem but sadly you need to do work in the twenty percent not covered."

tofflos 5y ago
> 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.

cuteboy19 5y ago

It might be better to upload all the modules to PyPI as third party repos. Maybe hand it off to some third party maintainers. This way if import cgi fails then you can at least pip install cgi to fix that

oblvious-earth 5y ago
No one has stepped up to maintain them in the standard library so who do they hand them over to maintain outside the standard library? This code is all open source, literally anyone could step up and do it themselves if they had the motivation.

codedokode 5y ago

I don't understand the motivation to remove MSI support. The document says: > Microsoft is slowly moving away from MSI in favor of Windows 10 Apps (AppX) as a new deployment model First, MSI has better OS support than AppX, second, many users are still using Windows 7 and won't be able to use AppX. MSI is not some 30-years old deprecated standard.

AdamN 5y ago
This PEP doesn't really stop functionality for nearly 3 years and even then it's only with the newest Python version so people can stay on the older version for another 2-3 years of further transition fully supported by the Python community. In 5 years, Windows 10 will be the bare minimum for a secure OS from MS.
qbasic_forever 5y ago
Why can't legacy MSI support be a standalone library? It looks like no one is maintaining it right now anyways so that should be some red flags right there.
mananaysiempre 5y ago
FWIW, CPython officially follows Microsoft’s support schedule on Windows systems, so versions ≥ 3.9 won’t even install on Windows 7. (Some reasonable people like it and some don’t, but this has been the official stance for a long time.) As for MSI, I’m torn: it is the most widely-supported and reliable packaging approach for Windows and, at the same time, a 20-year-old undocumented dumpster fire of an archive format spliced together with a scripting language forced into the mold of an allegedly-SQL relational database for which it is the sole user, and I can’t really find it in myself to blame Microsoft for wanting to kill that. (At the same time, they also cheerfully promote an admittedly documented 10-year-old metadata format [WinMD] grafted onto a bytecode+metadata format for a different platform [.NET] packed into a Win32 executable format [PE] that is built upon an early and obsolete SysV object file format [COFF] with a stub executable for DOS [MZ] prepended in contravention of the original spec—as a substitute for a 30-year-old undocumented metadata format [TLB] that is actually two different incompatible formats [SLGT or MSFT] but at least doesn’t have so many layers, so I can’t exactly promote them as a shining beacon of logic and sanity either.)

nrclark 5y ago

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 tricky about it. Why delete it? It'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. Uu is old, yes. But it's not broken either. Folks do still uuencode things from time to time. Why delete it? Telnetlib is personally useful to me, since telnet is one of the easiest ways to interact with a qemu VM's console. I hate that the answer is "Use something on Pypi instead", because that increases my dependency surface and adds no value for me. Why delete working, stable code?

qbasic_forever 5y ago
Nothing is stopping those libraries from being in a new 'legacy internet' package that motivated folks can maintain on pypi.
- nrclark 5y ago
  You're right, nothing is stopping anybody from putting these modules on Pypi. If somebody's already using Pypi dependencies, then another is no big deal. But there's a really big jump from "This tool is self-contained" to "This tool needs X from pypi". It ripples into deployment, source-control, everything. I try very hard to make tools that don't need anything except for Python's stdlib. That's based on a perception of trust: that the stdlib will be supported, and represents Python's only stable dependency. Once the team starts to erode that trust, Python's compatibility story will start to break.
  - qbasic_forever 5y ago
    cgi, nntp, telnet, etc. are old and obsolete. And not just in the 5 years out of fashion/not the trendy new thing--these things are decades out of date and have major or glaring security issues, etc. If you're publishing brand new code in 2022 that still depends on python's built-in cgi support, etc. you have far greater problems than having to pull in a third party dependency now. Python changes in breaking ways--just look at the python 2 to 3 change. You will have to learn to deal with it. There is no explicit guarantee that python will continue to work in exactly the way it has always worked for you forever.

renewiltord 5y ago

Surprised the ones without a replacement don't have PyPI modules available. I'm sure some enterprising fellow will simply extract the code and switch it into a PyPI module.

AdmiralAsshat 5y ago

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?

loloquwowndueo 5y ago
They are not deprecating xml.

tablespoon 5y ago

> For example, least controversial are 30-year-old multimedia formats like the sunau audio format, which was used on SPARC and NeXT workstations in the late 1980s Why would something like that add maintenance burden to the Python devs? I'd expect such code to be very, very stable.

michaelt 5y ago
Many software projects impose targets on themselves for things like 'software quality' that involves even stable code being checked and changed. For example, maybe they've received reports the code has bugs, but nobody thinks fixing is a good use of maintainers' time - or with such an old format, maybe no-one even knows what the correct behaviour should be. Maybe they have decided all file loading and network-interaction code should be fuzz-tested for security bugs. Or that every such module should have at least x% unit test coverage. Perhaps the the code uses deprecated methods and needs to be modernised. Or maybe they simply feel every file ought to have an owner, and nobody trusted has stepped up.

somat 5y ago

I feel that every release, the python team should do some soul searching and pick 5 modules to downgrade to external package(pypi) status, then pick 5 deserving external packages and elevate them to base status. This would, for one, add a bit of churn to the standard library leading to a more healthy ecosystem. And two, give everyone a target to complain about, I mean, people are going to complain about something, might as well focus their attention.

jphoward 5y ago
Because dependency hell isn't dreadful enough? Some entries will be completely missing from requirements.txt because the person assumes a certain version of python is present.
overgard 5y ago
That would make upgrading the interpreter version terrifying
MengerSponge 5y ago
Furthermore, imagine the joy of a package winning the Premier League just a year after returning from relegation?
selfhoster11 5y ago
That would result in a mini-Python 2/3 catastrophe every release. No, thank you. Maybe that's acceptable when you're the author of a piece of software, but as an ops engineer, that prospect makes my hair stand on end.
oblvious-earth 5y ago
Very few modules in the standard library actually get deprecated, that's why this PEP got put together. It also took 3 years of discussion to achieve consensus and the initial list was whittled down quite a bit and the reasoning became much stronger on the final list. And these aren't even being removed until Python 3.13! The SC have also said this is a one time event and they won't accept a similar PEP in the future, modules in the future most be handled on a case by case basis and the preferred outcome will not be to remove them.

dnsco 5y ago

> Post-History 21-May-2019, 04-Feb-2022 I would express all of the concerns being expressed here were debated ad nauseam over the three year political process of getting this proposal accepted. If you want to vent your fears and frustrations in a hopefully more productive way, you can get involved in Python's process. All that is to say, I'm thankful that the Python community gets things done, and people are willing to go through three year processes for changes such as this.

williamsmj 5y ago
Agreed. I also want to highlight these packages will be part of the stdlib for python 3.12, which will EOL in October 2028. In other words, if this change will affect you then you have up to 6.5 years to figure out and implement a plan.
oblvious-earth 5y ago
I am happy that people like Brett Cannon are in the Python Core Dev team getting things moving along. For reference here is the first discussions: https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704 https://discuss.python.org/t/pep-594-removing-dead-batteries... and https://mail.python.org/archives/list/python-dev@python.org/thread/NRSGCZKKICMR5DAF454I7CV3NWHGMU2Q/#KURMNB3JJDPI6DKLWOQ3HSW3PGUT7N3T https://mail.python.org/archives/list/python-dev@python.org/... And nearly 3 years later here is the second discussion: https://discuss.python.org/t/pep-594-take-2-removing-dead-batteries-from-the-standard-library/13508 https://discuss.python.org/t/pep-594-take-2-removing-dead-ba... I thought that feedback from the first discussion was carefully considered and I'm pretty happy with take 2. I have used the some of the modules being removed but largely agree now they are either legacy or there are significantly better third party options.

karmanyaahm 5y ago

As someone who has simple Python code for a CGI service that runs a couple of time a day (Golang vanity URL thing), that's disappointing. Maybe I'll rewrite it in Go to improve performance even more.

recov 5y ago
Virtually 0 chance of the functionality form Go being removed if you do.

pgcj_poster 5y ago

> CGI is deemed as inefficient because every incoming request is handled in a new process. This is why I keep every program I use on my laptop running in the background at all times. Imagine having to wait for a process to start before you can use it.

shadowofneptune 5y ago

It's good to see this happen. One concern I have with Python is that its standard library is large enough to make reimplementation impractical. It even requires another language, TCL, to be included. Python could be bound to CPython forever. Removing the 'dead batteries' should help somewhat with this problem.

mleonhard 5y ago

I'm happy to see old stuff removed. It frees up precious resources for better technologies.

exabrial 5y ago

I'm genuinely curious to see how this goes as a lot of languages have the same dead-battery problem. In Java for instance, StringBuffer and StringBuilder offer a very similar interface but one offers locking. Nowadays, most locking concerns are left to the caller, not the called. HashTable/HashMap are another example... The nice thing is, old libraries "just work". Java is trying to hide older parts of the API with Modules, and it remains to be seen whether or not this solution will take off and it will be adopted into other languages.