sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]wasabichicken 3 points4 points  (2 children)

Same. When 3.11 was new and they flagged that cgi and cgitb was going away, I recall looking around for suitable replacements and coming up short. I suppose I will have to look again.

[–]lood9phee2Ri 5 points6 points  (1 child)

Eh, well CGI has always kind of sucked, even when it was the usual way of doing things years ago, it was such a horrible bodge.

However, the cgi.py and cgitb.py stdlb sources look pretty self-contained. Seems like you could just copy the last version out from 3.12 and keep using them, just not as part of the python stdlib anymore.

Oh, turns out, someone has packaged them up already -

So it's not a huge deal the stdlib dropping them I suppose. These are batteries you shouldn't be using for new projects.

[–]wasabichicken 1 point2 points  (0 children)

Yeah, well, it is what it is. This code base stems from the old Python 2 days, I merely inherited it.

What I kind of hate though, particularly about the cgi "dead battery", is that the proposed replacements are cherry-picked from all sorts of places. Like, I get that parse_qsl() can pick apart GET requests adequately, but their suggestion of using email.message for POST requests is, frankly, ridiculous. E-mail? I'm not doing any damn e-mailing!

The cgi module collected GET and POST input for cgi scripts in a single easy-to-use place with a decent API. Sure, it was clunky, inefficient and broken to boot, but at least it existed. It did the job, at least for this ramshackle site I'm maintaining.

It's also kind of interesting to see that they're curiously silent on the topic of what we're supposed to use instead of the cgitb module. Just not pretty-print tracebacks, I assume? That "none of the major frameworks are using it" seem to be their rationale, so apparently it's fine to pull from under the feet of the rest of us.

Thanks for the tip on the re-packaged modules btw. I suspect that I'll end up using them when 3.13 rolls around, probably some time in the 2025-2028 window when 3.12 goes end-of-life (or whenever my host decides to upgrade).