Hello, there’s a number of modules being deprecated in Python but not sure why.
Firstly, the cgi http.server in Python is surely a masterpiece. The arguments about cgi not being a good way to do things contradict the vast amount of websites running on cgi servers on the web today and e.g. AWS Lambda whose Firecracker VM creates an entire OS instance upon http invocation and remains to be economically favourable to a running server.
SMTPD - email is one of the functions on which “western” computing was built and can still be an important interface for human interaction. Cloudflare have developed email workers, Amazon SES and so on I think Python has a lot to offer in this space. So this includes all the email encoding things we need - email as a technological specification has not been deprecated!
telnetlib - I don’t use it but telnet is the core way in which one device can communicate with another. If the protocol is not known, telnet is the way to attempt to communicate! It’s a part of computing history at the very least, and a fundamental way of machine to machine negotiation at the other end of the spectrum
I appreciate we can split these out into optional PyPI packages but really these protocols and functions are so core to computing that it’s hard to imagine putting it anywhere other than the standard library.
You’re conflating the telnet client with the telnet protocol. Since telnet protocol is so simple, a telnet client can be used as a straight-forward socket client, which IS extremely useful. (Personally, I use a MUD client for that purpose; it’s a telnet client with some additional features, but again, it serves as a socket client.)
But Python’s telnetlib isn’t necessary for building a socket client. Its job is to handle telnet protocol - the “hey, please do this” // “hey, I can do this” negotiation between the server and client. Notably, this means that any time telnetlib.write sends data, it will transform b"\xFF" into b"\xFF\xFF" to prevent it from being misinterpreted as a command. It’s this protocol that is considered less significant now. I would say that, in the modern era, MUDs are about the only place where this is important - and if you’re making a MUD client, there’s a lot more to do than just TELNET protocol, so you’ll likely be fine with grabbing something from PyPI.
But Python’s telnetlib isn’t necessary for building a socket client. Its job is to handle telnet protocol - the “hey, please do this” // “hey, I can do this” negotiation between the server and client. Notably, this means that any time telnetlib.write sends data, it will transform b"\xFF" into b"\xFF\xFF" to prevent it from being misinterpreted as a command. It’s this protocol that is considered less significant now. I would say that, in the modern era, MUDs are about the only place where this is important - and if you’re making a MUD client, there’s a lot more to do than just TELNET protocol, so you’ll likely be fine with grabbing something from PyPI.
Being in exactly that situation myself, I determined long ago that there was little in stdlib’s telnetlib I wanted to rely on for the server, and implemented my own RFC-compliant Telnet protocol handler on top of raw sockets instead. When the telnetlib deprecation was announced, I ended up copying some integer definitions for the protocol commands and values (IAC/DO/DONT/WILL/WONT/ECHO/NAWS/et cetera) into a module in my project, and not even verbatim since some of them were ambiguous compared to BSD’s arpa/telnet.h anyway.
I did end up using a copy of telnet.py in the project’s scripted selftests though, simply because the telnetlib.Telnet() client implementation had convenient handling for option negotiations that I needed regression tests to exercise, and the project itself is a server so writing a client from scratch was not something I felt like investing a bunch of extra time into.
I think we should remain agnostic about green thread “async” implementations until we are fully sure of the future. As an example of implications Rust is now effectively tokio
nntplib - don’t use it myself but usenet groups do still exist.
spwd - doesn’t sound like this Linux functionality has been deprecated.
uu - emails from the 80s are important too!
asynchat - sounds like a nice introduction to client server communication
With cgi - the criticism is one of code quality from 2000. I believe the http.server --cgi invention came after
Wholesale copy & paste from the last published stdlib version is also a reasonable way to go.
The removals just make it clear that folks are completely on their own when it comes to making sure these modules are safe to use on the modern internet (Edit: or, as in the case of legacy-cgi, form new, more focused, collaborative communities around the specific libraries of interest).
CGI as an idea! When someone learning Python for the first time and computers, realises you can run a program on your machine via a http call, and respond to your computer, that’s a mind expanding experience, something it takes years to get over. I’m still not over it myself.
CGI also says, I want a system where all languages and programs can interoperate. The languages and programs have different domains, different things they are good at, and things they are not so good at.
Finally, CGI vs other GIs now represents small, beginner ideas vs large, cover the world large ideas.
CGI is also very real. If you look to purchase web hosting it is top of the list.
It’s not part of the legacy-cgi package either. But the form parsing in there is presumably worth someone’s time for the sake of a couple of files.
Yes it could be improved. For example, default serve the current folder unless it is the user’s home directory, add an argparse option to insert http headers, maybe provide http basic auth with a note about browser basic auth persistence. Just a little more documentation with it, such as making files executable and the Content type \n\n necessary.
Yes, but there are plenty of other things you can’t do with just the stdlib. Why is CGI so special? It’s a terrible way to build a web app and shouldn’t be elevated above all else.
In my experience, getting pip working is not an adventure, it’s a very basic step. Once you want to move beyond the stdlib, it is the single most important piece to master. It isn’t usually very difficult, and it empowers you with the entire ecosystem of packages. Again, why should CGI be elevated above the myriad other ways of building a web app?
Are you saying that there isn’t, or that there shouldn’t be? Because there is, and it’s already been linked to in this thread.
Clearly you prefer to use CGI over other options. That’s fine. But there are many ways to do that - copying the code in, using it off PyPI, etc. You haven’t shown why it should be in the stdlib.
That’s an oversimplification, as there will be some circumstances where you want to make an HTTP server on a closed LAN. But for those, http.server — HTTP servers — Python 3.13.2 documentation is probably sufficient, and in any case, I would NOT be recommending the use of CGI. Keep it simple.
I think anyone can flag a post and then it gets automatically hidden. I can’t see the hidden post so I don’t know why it was hidden and I also don’t know who flagged it but it was not necessarily a moderator.
This happens a lot and I am not sure if people actually intend for the posts to be hidden. There is a little flag icon on each post and if I hover over it then it says “privately flag this post for attention or send a personal message about it”. I’ve never clicked that button so I don’t know exactly what happens if you do but my understanding is that anyone can click it and if enough people (based on their “reputation”) click it then the post is immediately hidden. To me it often seems like there is not really a strong reason for the post to be hidden but the way that the forum software is designed means that small numbers of flag happy people can dictate the threshold for what actually gets hidden in practice.
I don’t think that github searching, without more in depth research, actually tells us anything. I see it frequently on this forum and it has started to become a bit of a personal goal to get folks to expand their view. How much of that code is abandoned? How much closed source code is being missed? There are a lot of elements of impact assessment for a deprecation or breaking change beyond just counting the usages.
I can tell you that I saw impact in exactly one project I work on, which relied on webob. The webob devs made a patch. All was well.
One of the ways any (mature) project thinks about breaking changes is to determine how costly it will be for broken projects to adapt. In the case of the cgi module, part of that assessment was[1] that users can
pip install legacy-cgi or other cgi libraries
or vendor those tools into their applications
You are fully entitled to that opinion! But the decision was made quite a while ago, so I’m not sure what you’re hoping for here.
Do you want to see a course reversal and for Python 3.14 or 3.15 reintroduce CGI support? If so, you need to make a very compelling argument that the decision making from the past was wrong, and that you have the evidence that large numbers of users are suffering from this change and aren’t able to meet their needs with the tools (like pip) which are available.
I see no strong need to try to convince you that the removal was a good idea – I disagree but I very happily work with lots of folks with whom I have technical disagreements. I even think it serves to our benefit.
But if you are trying to convince people to reverse a decision which was carefully made, I’m just not seeing very much compelling stuff in this thread.
to the best of my understanding – I wasn’t involved ↩︎
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).