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

61–70 of 95 posts

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

#61

Post by [deleted] »

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…

[deleted]

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

#62

Post by shadowofneptune »

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.

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

#63

Post by hannob »

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…

I don't really see the connection between cgi and http basic auth. These seem orthogonal issues.

(And fwiw the usecase I have does not have any authentication and doesn't need any. It's taking a POST var and doing things with it, but there are no secrets involved.)

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

#64

Post by williamsmj »

at_a_remove wrote: post #31
kstrauser wrote: post #27

Earlier quoted context omitted.

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?

This exact possibility was discussed and decided against back in 2015. See https://lwn.net/Articles/640838/.

The tl;dr is that if you move a package into the standard library then you are restricted by the python feature release schedule (was every 18 months, now annual) and backwards compatibility requirements (see https://peps.python.org/pep-0387/).

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

#65

Post by mjw1007 »

munch117 wrote: post #41
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…

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.

Looking at

https://discuss.python.org/t/pep-594-removing-dead-batteries...

someone did volunteer to maintain cgi and cgitb.

But nonetheless those modules remained listed in the PEP.

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

#66

Post by pas »

themadsens wrote: post #51
munch117 wrote: post #41

Earlier quoted context omitted.

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.

Arguing that opponents to removal "can just step up as maintainers" are completely bogus. As mentioned elsewhere, this is more about eroding trust in stdlib as a stable baseline. This is just the kind of thing that will teach people to not trust Python as a stable foundation. Also. If maintenance of aging modules becomes tiresome, maybe it is a strong hint to keep backwards compatibility in Python proper.

> maybe it is a strong hint to keep backwards compatibility in Python proper.

Or.. or, just consider that the community looked at the relevant trade offs and decided what it decided.

If someone wants an old built-in module they can use an old python version.

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

#67

Post by nitrogen »

qbasic_forever wrote: post #58
munch117 wrote: post #56

Earlier quoted context omitted.

Not at all bogus. If "eroding trust in stdlib as a stable baseline" is an important issue to you, then you can do something about it by helping provide the resources that allows old modules to be kept. Core language backwards compatibility is a non-issue. Approximately zero percent of maintenance costs go towards that.

Not to mention python has an entirely open proposal process where anyone at any point could have commented and expressed a desire to keep these libraries in the standard library. It seems after this entire process not enough people need them in the standard library.

> It seems after this entire process not enough people need them in the standard library.

I'm reminded of the Hitchhiker's Guide to the Galaxy:

"It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard."

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

#68

Post by nitrogen »

qbasic_forever wrote: post #59
X-Istence wrote: post #57

Earlier quoted context omitted.

WebOb uses cgi for parsing multipart uploads/forms... It's not obsolete, and it is heavily used, it's working software that works well. Ripping it out just means now there will be N copies floating around that will all need to get patched/fixed instead of just a single version included with Python.

Well apparently it's not heavily enough used that any of its current users were motivated enough to discuss the PEP and make a strong case for keeping it in the standard library. The discussion was open for _three years_ and had hundreds of comments: https://discuss.python.org/t/pep-594-removing-dead-batteries... The outcome is that there isn't enough usage to merit this being in the standard library.

I suspect there's very little overlap between users of development software and participants in the bureaucracy that designs the software. The requisite personality types are very different.

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

#69

Post by williamsmj »

dnsco wrote: post #45

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

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.

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

#70

Post by joshcryer »

mananaysiempre wrote: post #39
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…

Python > 3.9 works just fine on Windows 7 with the api-ms-win-core-path-l1-1-0.dll Wine hack: https://github.com/nalexandru/api-ms-win-core-path-HACK

It's interesting because once Win 10 support drops there will no longer be any x86 Windows path for Python, but there's still a lot of x86 Windows hardware that still works.

I suppose that's more an argument to move to Linux/FreeBSD though on that hardware... I can understand dropping support for something but single breaking changes shouldn't merit it.

Post reply on HN