Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The Python maintainers are removing the module _named_ cgi, but they're not removing the support for implementing CGI scripts, which is CGIHTTPRequestHandler in the http.server module.

All that was in the cgi module was a few functions for parsing HTML form data.



It would be very difficult indeed to make it impossible to implement CGI scripts in Python; you'd have to remove its ability to either read environment variables or perform stdio, crippling it for many other purposes, so I didn't think they had done that. Even if they removed the whole http package, you could just copy its contents into your codebase. It's not about making Python less powerful.

As a side note, though, CGIHTTPRequestHandler is for launching CGI programs (perhaps written in Rust) from a Python web server, not for writing CGI programs in Python, which is what the cgi module is for. And CGIHTTPRequestHandler is slated for removal in Python 3.15.

The problem is gratuitous changes that break existing code, so you have to debug your code base and fix the new problems introduced by each new Python release. It's usually fairly straightforward and quick, but it means you can't ship the code to someone who has Python installed but doesn't know it (they're dependent on you for continued fixes), and you can't count on being able to run code you wrote yourself on an earlier Python version without a half-hour interruption to fix it. Which may break it on the older Python version.


My mistake.

The support for writing CGI programs in Python is in wsgiref.handlers.CGIHandler .


Yes, thanks.


[flagged]


I can't wait to live in the world where openly admitting your mistakes is considered evidence of disingenuousness.



with the rise of docker, I assume the current gen of progress just assumes you're going to containerise your solutions. How many projects are you actively upgrading python for?


On the other hand, you can't carry old stuff to infinity.


You can't carry anything to infinity, by definition. Please argue constructively.


Then remove the hyperbole and be merry.

You can't carry everything to very long term horizons, especially for categories of "everything" whose user base is 2 people and 1 squirrel.

People who want otherwise should volunteer to maintain what they want kept.


The social problem is that maintaining backward compatibility with boring technology is considered harmful by the current Python community. There was an active campaign to extract pledges from popular Python library authors to break compatibility with Python 2 by a certain date. This means that if you are volunteering to maintain what you want kept, you had better not tell anyone about it.


Do you have any URIs or back up links? Encouragement to actively break compatibility sounds like "inciting murder" vs. a more tame "don't expend effort (go to medical school)" to save folks.

{ Oh, and before anyone jumps on me, this is only an analogy as it relates to freshman moral philosophy courses, not an attempt by me to over-dramatize - that is more the fault of said courses trying to engage 18 year olds. :-) I'm mostly interested in the active-passive details of the pledge campaign. }



Thanks!


Sure!


Why not? Was it broken? If it was, is it easily fixable?


Well, for one, security concerns, especially for an internet oriented component.

Secondly, you have to find a reliable maintainer or several.

A lot of people want stuff to be maintained indefinitely for them by unspecified "others".


You don't have to find a maintainer.

Not updating the system is usually a solution to such problems.

At best there is a nginx or an API in front that acts a reverse proxy to clean-up/normalize the incoming requests and prevent directly exposing the service.

Example: banks, airlines, hospitals, air traffic controllers, electricity companies, etc

All critical services that nobody wants to touch, as it works +/-


Guess what, all those places can just use Python 3.12 for as long as it's maintained and if they REALLY can't update, they can:

a) make the system air gapped

b) pay a Python consulting company to back port security fixes

c) hire a Python core dev to do the system, directly

OOOOR, they can just update to Python 3.13 and migrate to the equivalent Python package that's not part of the core. For sure they already use other Python packages already.

We're making a mountain out of a molehill, also on behalf of places that have plenty of money to spend if push comes to shove.


I think it may be easier to backport CGI to a new version of Python rather than backport security fixes


I agree.


It takes time, and this means that instead of working on something else, their time is locked on this.


The CGI standard hasn't changed… what changes did the module need?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: