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

51–60 of 95 posts

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

#51

Post by themadsens »

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.

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.

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

#52

Post by a-dub »

mjw1007 wrote: post #24
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…

The cgi module didn't actually contain the Python standard library's CGI support. That's in wsgiref.handlers.CGIHandler, and isn't going away. What the cgi module did contain was some occasionally-useful support for working with HTML forms. As far as I can tell they're throwing that away for no good reason.

isn't that basically the bulk of the CGI standard? parsing environment variables and stdin for http get/post data?

what else is left? emitting mime type headers and such and two newlines?

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

#54

Post by pgcj_poster »

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

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

#55

Post by jcranmer »

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…

Since NNTP was my gateway to open source, I'm somewhat sad to see Python's nntplib module die... but NNTP is quite well advanced in its way out. If you were asking a decade ago, NNTP would be a relatively niche community that potentially had some relevance, but posting volumes not associated with alt.binaries has declined precipitously in the past decade alone (judging from aioe.org's statistics, it's a third of in 2022 of what it was in 2012, and even that feels generous).

I can understand some concern about the impact of removal of support for deprecated things where it potentially impacts archival scenarios (e.g., uuencoded text), but dropping NNTP from the standard library is probably the right call for Python. It's not like the protocol is so complicated you need a library to do it for you, anyways. ;-) (To be fair, I often use NNTP as my example protocol for implementing stuff because of its simplicity.)

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

#56

Post by munch117 »

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.

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.

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

#57

Post by X-Istence »

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…

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.

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

#58

Post by qbasic_forever »

munch117 wrote: post #56
themadsens wrote: post #51

Earlier quoted context omitted.

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.

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.

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

#59

Post by qbasic_forever »

X-Istence wrote: post #57
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…

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.

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

#60

Post by recov »

karmanyaahm wrote: post #53

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.

Virtually 0 chance of the functionality form Go being removed if you do.
Post reply on HN