the decision was made quite a while ago
In fact so long ago that it was subsequently carried out, so at this point arguing against the decision is rather pointless. At best someone would need to start a discussion about reintroducing modules to the stdlib which were removed from it and are no longer included in current stable CPython releases (3.13+, or even earlier in the case of some of the “dead batteries” removals).
Sure. And if you search for a Python-2-style print statement (this quite strict regex search: /^\s+print\s[^(]/ language:Python) you will find 2.5 million files. These results are a tiny fraction of that result, and Python 2 has been EOL for five years now.
To a first approximation, you’ve shown that nobody is using any of these modules.
Or more precisely: Nobody is using any of these modules with Python 3.13. There’s plenty of places out there where older Pythons are used, for various reasons.
Sure, hence “to a first approximation” (and I’d say “with Python 3”, not just 3.13[1]).
When discussing the possibility of reintroducing removed modules, we’re talking about a something that occurs in Python 3.14. People who haven’t been willing or able to update their Python version this decade just can’t be considered relevant to whether it’s a worthwhile change.
again, to a first approximation! ↩︎
I disagree that “there isn’t much use for a web server”. Having a local intranet, running CGI is excellent for both teaching “how the internet works”, and making a useful, local server. That will serve any OS connected on that intranet.
(And often in a training environment, the intranet is isolated from the internet, and installing packages impossible.)
That it is not efficient, and that it is not secure, lead to useful discussions about efficiency and security. And are not a problem on a low-volume, isolated network.
Agreed, but as mentioned, there are other ways to make a quick and easy web server - and they’re not going away. CGI is a poor choice for teaching, and a poor choice for making a useful local server. We have better alternatives in the stdlib, and if those aren’t sufficient, you should probably be looking at tools like Django and Flask.
Yes, thanks @Rosuav .
I might have not been clear about the CGI module (yes, aware deprecated, to be removed, and for which there are stdlib alternatives). And the http.server -cgi option, which (according to the docs) is deprecated in 3.13 and to be removed in 3.15.
I find that feature useful (both in a training environment and to spin up something simple on an isolated network.)
I am not aware of a stdlib alternative to that? Can you illuminate?
(While I professionally am an avid user of Flask, my comments about not being able to install during a training session apply to it and any other non-std modules)
Hmm. Normally I would expect that, in both training and quick-and-simple servers, http.server.HTTPServer is the better choice. Can you elaborate on what makes CGI in particular more suitable?
I use the --cgi option to teach using Python as the backend for a website, generating a “hot” live page. With that option, the server runs the Python code and delivers the resulting html for rendering by the browser. Super exciting for learners to see how the coding they have learnt can be used to create “the internet”. Without that option, the http.server simply delivers the Python code as text.
I am unaware how this can be done without the --cgi option, using the stdlib.
(Note I previously typoed that option. It does require a double-dash)
from http.server import BaseHTTPRequestHandler, HTTPServer
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
# put your CGI-like code in here instead of an external program
self.wfile.write(...)
with HTTPServer(("", 8080), Handler) as server:
server.serve_forever()
Instead of all the magic of setting up environment variables and launching a subprocess, you write the code right there in the handler. Much MUCH cleaner.
I might have not been clear about the CGI module (yes, aware deprecated, to be removed, and for which there are stdlib alternatives).
It was “deprecated to be removed” three years ago when PEP 594 was accepted by the SC (2022-03-11), during the development of CPython 3.11 prior to the 3.11.0 alpha 7 release. It is no longer deprecated, it was (past tense) entirely removed during the development of CPython 3.13, and 3.13.0 final was released 4 months ago now. So not deprecated any longer, completely gone, for months at this point. That ship has, as they say, already sailed.
Oh that’s great! Thank you. I was familiar with do_GET from my Perl days, but hadn’t thought of approaching the problem here the same way.
I had to add a few other bits - send_response and send_header etc, but working like a charm.
Would a snippet of code like this, or even just a note about the approach, be appropriate to put into the docs for CGIHTTPRequestHandler?
Ah yes, removed now. Noted.
The RealPython http tutorial from 2023 teaches how to use the CGIHTTPRequestHandler.
Removing code from the CPython repo just means it needs to be re-done somewhere else, by someone else, many times over.
Instead you have people running their code after upgrading one day and finding that it is not working. And every single one of those people has to go through the process of fixing it or rewriting it somehow.
Because the files have been removed there is no dependency within cpython.
They can be restored safely.
The real question is: WHY does it use CGI? Is it simply because it’s available, or would CGI be actually a good choice even without that? With CGI being removed from the standard library, will the tutorial have to reimplement it, or would it be changed to use a superior method such as subclassing http.server.HTTPServer?
Also - I did a quick search on RealPython and couldn’t find it, so I don’t know what you mean by “the http tutorial”. You may need to link to it. I’ve no idea how relevant that site even is.
Yes, it is a Platonic idea. There are even attempts to make it working (complicated history by its supporter in Comments on Scripting, CGI, and FastCGI), but nothing makes me persuaded that such attempt should be in the Python standard library.
From that page:
It’s two processes either way — it’s just a matter of where you draw the boundary, and what protocol is at the boundary.
Very true, and in fact, I wouldn’t want it any other way. It is very helpful to have a separation between the web server and the application server. It’s just a question of how you draw that separation. CGI (in its original form - FastCGI is different) does that by spawning a new process for every request, giving high isolation and protection but low performance. A more common model (the article mentions nginx as the server and gunicorn as the app, but the same can be done in various other ways) has a single persistent application process and it communicates via HTTP. There are other options, too, but you’ll always want that separation.