> urllib too? Spoiler: no
How can you have urllib2 without urllib? That would be silly
Python finally offloads some batteries
11–20 of 67 posts
Re: Python finally offloads some batteries
#12What is the alternative to “cgi”?
wsgi, or more realistically AWS Lambda or other modern FaaS platforms that runs even simpler python scripts than cgi.
You're missing the point (and the hundreds of comments in the three years this pep has been open and debated)--the cgi library never would have been included in python if it were proposed today. It doesn't meet the bar for including in the core just like modules to handle json-rpc, grpc, etc. aren't included today. If you want cgi support pull in a high quality third party library to do it.
Re: Python finally offloads some batteries
#13What is the alternative to “cgi”?
You don't have to find an alternative. Just copy the parts you need into your own code: https://github.com/python/cpython/blob/main/Lib/cgi.py
Re: Python finally offloads some batteries
#14What is the alternative to “cgi”?
wsgi, or more realistically AWS Lambda or other modern FaaS platforms that runs even simpler python scripts than cgi. You're missing the point (and the hundreds of comments in the three years this pep has been open and debated)--the cgi library never would have been included in python if it were proposed today. It doesn't meet the bar for including in the core just like modules to handle json-rpc, grpc, etc. aren't i…
Honestly it's kinda disappointing that the CGI library would not be included in Python if proposed today. Why would wsgiref get included then?
I get the arguments for a small standard library in theory, but given how absolutely nightmarish it is to deal with python requirements in a "will work every time" way, I don't know where we end up with the Python standard library in general.
Not making a slippery slope argument for the list of packages in this change. Just like, even when languages like Rust build for the ground up with good package management, everything requires 1000 different packages and it's a whole thing.
So if you don't have a great way of shipping dependencies, and on top of that the standard library is in "please don't let me get bigger", it makes me a bit sad.
Re: Python finally offloads some batteries
#15What's the exact motivation for this. Just ask for more money, no reason Dropbox or Amazon can't pay for development. I'm worried this is going to break some use cases, not everyone has network access to install random pip packages
Then they won’t be able to - and in any case won’t be forced to - install this new version of Python. This is silly. If we rejected any change because 3 people might have some farfetched problem, there would never be any progress.
The reality is that it’s acceptable for a few people in absurdly rare edge cases to have a bit of trouble, when it’s justified by much greater gain for everyone else.
Re: Python finally offloads some batteries
#16Earlier quoted context omitted.
wsgi, or more realistically AWS Lambda or other modern FaaS platforms that runs even simpler python scripts than cgi. You're missing the point (and the hundreds of comments in the three years this pep has been open and debated)--the cgi library never would have been included in python if it were proposed today. It doesn't meet the bar for including in the core just like modules to handle json-rpc, grpc, etc. aren't i…
Honestly it's kinda disappointing that the CGI library would not be included in Python if proposed today. Why would wsgiref get included then? I get the arguments for a small standard library in theory, but given how absolutely nightmarish it is to deal with python requirements in a "will work every time" way, I don't know where we end up with the Python standard library in general. Not making a slippery slope argume…
This is an argument for good package management. There’s no way around it. You can’t add everything anyone could ever hypothetically need into the standard library, just because Pip is rubbish.
(I mean, I don’t care. I use Rust. I’m just arguing on behalf of the poor people who are still abused by their employers, or wacky enough to voluntarily choose to use Python.)
Re: Python finally offloads some batteries
#17What's the exact motivation for this. Just ask for more money, no reason Dropbox or Amazon can't pay for development. I'm worried this is going to break some use cases, not everyone has network access to install random pip packages
They don’t provide more money. The PSF is mostly funded by PyCon( approximately $1 million) and they had to cancel one of them (also PyCon is run by volunteers. Also, it has lots of contributors who are volunteers. If people wanted these packages to remain someone needed to actually do the work in maintaining them.
Re: Python finally offloads some batteries
#18What is the alternative to “cgi”?
There seems to be overlap with wsgiref, and that ships with Python. There's a CGIHandler class that can use stdin/stdout.
Most of the examples show spinning up and listening to a port, but you can google around to find examples that work with just stdin/stdout.
Re: Python finally offloads some batteries
#19What's the exact motivation for this. Just ask for more money, no reason Dropbox or Amazon can't pay for development. I'm worried this is going to break some use cases, not everyone has network access to install random pip packages
> not everyone has network access to install random pip packages
Lucky that the lack of network access will prevent these new versions of Python just as well.
Re: Python finally offloads some batteries
#20PEP 594 – Removing dead batteries from the standard library - https://news.ycombinator.com/item?id=30673597 - March 2022 (90 comments)