Do python mains not know what FastCGI or mod_python are?

WSGI and mod_wsgi were designed as an improvement over mod_python which was pretty much an Apache only thing.

As for FastCGI, although it is language agnostic it didn't really get traction outside of PHP.

WSGI (same for ASGI) is a level above FastCGI (or CGI or whatever) in the stack; it exists so each Python web framework does not need implement ways to talk to CGI, FastCGI or whatever. Instead the framework implements a Python function, and the user can choose a WSGI server to wrap this Python function into whatever is needed to talk to any kind of language-agnostic gateways, including CGI, FastCGI, or even mod_python.

In practice most deployments I have seen use a WSGI server that directly speaks HTTP so that CGI, FastCGI, or mod_python are not even necessary.

mod_python is pretty much dead at this point. Ubuntu 22.04 ships a port of it to Python 3, but it is buggy. I ended up switching my code from mod_python to WSGI instead of debugging "apache segfaulting in mod_python" issues, on some ~20 year old mod_python code over the last year.

Pro tip: WSGI is pronounced like "whiskey". :-)

Is it?? I’ve been slaughtering that word for almost 15 years. Whether true or not, that’s what I’m calling it from now on.

Ian Bicking is the one who told me, so I feel like I can speak with some authority. :-)

layer below and dead, respectively.

The point of WSGI is for the server and application to speak the same python-level protocol. You can have a wsgi adapter on top of fcgi, though it’s really a waste of resources if you can skip fcgi entirely (which you usually can).

I have a loos story I can tell that links mod_python to WSGI (a bit).

One of the initial inspirations for creating the Django web framework back a the Lawrence Journal-World newspaper in ~2003 was that we wanted to start using Python on the web, but were concerned that mod_python didn't have quite enough existing users.

What if it turned out not to work for us?

So we designed a simple abstraction layer - a request and response object - as an insurance policy. If mod_python turned out not to work for us we could switch to something else without having to rewrite all of our code.

At around about the same time the Python Web SIG formed - https://simonwillison.net/2003/Oct/18/pythonWebSIG/ - and we joined it with the aim of helping define a standard similar to what we had been building for our own, private newspaper CMS.

WSGI was the eventual result of that SIG - I didn't participate in the working group nearly as actively as I had planned to, so I can't say that I had much if any impact on the result.

But hopefully this illustrates that yes, the people involved were very aware of mod_python back in 2003 when this work kicked off.

Thank you so much for your work! It really shaped a generation of web development, giving a shot to small players and startups.

PS That is why I love HN. You get to casually see creators of great projects.

Speaking on behalf of the basic python main community, we just do whatever `requests` does.

That's a HTTP client library.

One of the nice things about CGI was that by starting a new process per request it provided isolation between requests. Python's startup overhead obviously makes CGI untenable, but I find the new Web Assembly runtimes interesting because they are able to provide extremely fast startup by reseting state: https://bytecodealliance.org/articles/wasmtime-10-performanc...

PHP was built around this idea for decades %)

Theoretically one could produce ready-to-run, guaranteed clean Python request handlers very quickly. Run all the startup and imports stuff in a Python process, then freeze it. Fork a copy of it on a new request (with COW it's definitely fast), and terminate it normally after that. This would require some care, e.g. to not open sockets before the fork, so that handlers won't share it.

I bet it has been tried, but I'm too lazy to actually search for that.

Forking can be quite slow (milliseconds), though there are techniques to speed it up: https://www.cs.purdue.edu/homes/pfonseca/papers/eurosys21-od...

I believe wasmtime can be faster as it doesn’t need to create as many new OS resources and just resets some memory maps.

Only really meaningful for simple request handlers taking a few milliseconds.

boiler up

The thread: "The beauty of CGI and simple design (rubenerd.com)" | 320 points by susam 9 days ago | 215 comments | https://news.ycombinator.com/item?id=34286622