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

31–40 of 95 posts

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

#31

Post by at_a_remove »

kstrauser wrote: post #27
tofflos wrote: post #25

Earlier quoted context omitted.

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

Then wouldn't we want to Pythonify Requests a bit and move it into the standard library?

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

#32

Post by nrclark »

qbasic_forever wrote: post #21
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.

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.

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

#33

Post by qbasic_forever »

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…

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.

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

#34

Post by somat »

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.

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

#35

Post by hannob »

qbasic_forever wrote: post #33
nrclark wrote: post #32

Earlier quoted context omitted.

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…

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--ju…

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

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

#36

Post by michaelt »

tablespoon wrote: post #19

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

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.

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

#37

Post by jphoward »

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…

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.

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

#38

Post by qbasic_forever »

hannob wrote: post #35
qbasic_forever wrote: post #33

Earlier quoted context omitted.

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--ju…

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, other services, etc.) without checking any permissions, enforcing any cross site scripting or CSRF protections, etc. It might be fine for the most trivial appplication. For anything that actually changes state or has side effects, I would be very concerned and it would never pass a serious security review.

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

#39

Post by mananaysiempre »

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.

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

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

#40

Post by c0l0 »

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…

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