Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 594 – Removing dead batteries from the standard library

peps.python.org

Post reply on HN
Print view View original

41–50 of 95 posts

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

#41

Post by munch117 »

nrclark wrote: post #32
qbasic_forever wrote: post #21

Earlier quoted context omitted.

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

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…

If you want to step up and be the maintainer of one or more of these modules in the standard library, I'm pretty sure you would be welcomed. PEP 594 is basically just a formalisation of the fact that no one has volunteered to do this yet.

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

#42

Post by ciupicri »

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…

For uuencode migrate to a2b_uu and b2a_uu from the binascii standard module.

[a2b_uu]: https://docs.python.org/3/library/binascii.html#binascii.a2b...

[b2a_uu]: https://docs.python.org/3/library/binascii.html#binascii.b2a...

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

#43

Post by [deleted] »

codedokode wrote: post #14

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.

[deleted]

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

#44

Post by jandrese »

loeg wrote: post #8
Beltalowda wrote: post #7

Earlier quoted context omitted.

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.

NIS is definitely not a Windows thing. Maybe the python module would appear if you installed NIS support on your system?

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

#45

Post by dnsco »

> 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.

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

#46

Post by overgard »

somat wrote: post #34

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, mi…

That would make upgrading the interpreter version terrifying

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

#47

Post by selfhoster11 »

qbasic_forever wrote: post #38
hannob wrote: post #35

Earlier quoted context omitted.

what's the major glaring security issue of cgi that you would consider a dealbreaker for a simple http-based service? (this is an honest question, because when I saw this list I actually have a python script running on an apache web server that is using the cgi module to access post variables, and I never saw any need to change that, as any other "more modern" solution would be much more bothersome to configure and m…

What is your auth and session story? Because I doubt you're implementing OIDC, JWT, etc. in a cgi script vs. relying on a modern framework that does all the work for you. HTTP basic auth? Well, there's your security issue right there. So presumably you are happy to have a web accessible endpoint running on your server that will pop a new process and start executing a local script (which might be reading/writing files…

Firstly, HTTP Basic auth is not a problem over HTTPS (and it will be HTTPS more often than not, given modern browsers are bound to criminalise HTTP soon). Even then, putting an authenticating reverse proxy in front of such a site is dead-simple, and that can use wherever auth is required.

Secondly, chances are that if you're building a CGI site, you won't be exposing it to the outside world at all because it's internal/personal jank that's built to do a single job, and not to look nice. If it's meant to look nice and and handle the stress of being used by a public userbase, then it won't be CGI in the first place.

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

#48

Post by MengerSponge »

somat wrote: post #34

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, mi…

Furthermore, imagine the joy of a package winning the Premier League just a year after returning from relegation?

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

#49

Post by qbasic_forever »

c0l0 wrote: post #40
qbasic_forever wrote: post #38

Earlier quoted context omitted.

What is your auth and session story? Because I doubt you're implementing OIDC, JWT, etc. in a cgi script vs. relying on a modern framework that does all the work for you. HTTP basic auth? Well, there's your security issue right there. So presumably you are happy to have a web accessible endpoint running on your server that will pop a new process and start executing a local script (which might be reading/writing files…

HTTP Basic Auth over a secure transport (i.e., TLS) is not a "security issue".

It's a massive footgun and no sane security review would let a production service pass with HTTP basic auth. You're one misconfigured TLS proxy away from major security breaches and issues.

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

#50

Post by selfhoster11 »

somat wrote: post #34

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, mi…

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