On 26/10/2012 10:58, Gilles wrote: > On Thu, 25 Oct 2012 14:24:16 +0100, Tim Golden <m...@timgolden.me.uk> > wrote: >>> But actually, I didn't mean one-shot scripts, where the Python >>> interpreter + script must be loaded each time, but rather: If I leave >>> a Python running in an endless loop, why not just use either CGI or >>> some other basic way to call the script instead of FastCGI? >> >> In essence, you're describing FastCGI. A Python program (or, indeed, any >> program) which uses FastCGI runs continuously and waits for the incoming >> request on a TCP socket (instead of as a sys.stdin stream + env vars >> immediately after process startup). > > Thanks for the clarification. > > Since, unlike PHP, the Python interpreter is not available in a > FastCGI-capable version, this explains why the www server must be told > which specific Python script to run through FastCGI.
I think that this is the distinction you're making: PHP: mod_php (fastcgi mode) runs myscript.php Python: <some python fcgi frontend>.py runs myscript.py which is, essentially, true, not least because PHP and web apps are pretty much synonymous in many people's minds. Both ways: the only thing PHP does is web; the simplest route to a web app is PHP. Certainly there are Python equivalents (mod_python, mod_wsgi, etc.) which can run in effectively the same way as mod_php, and they could be configured to run an fcgi frontend script, I presume. There's always a certain confusion here because you can often one mechanisms (say, mod_wsgi) to act as another (say legacy one-shot CGI) and because some things are both mechanism and protocol and it's not always easy to tease the two apart. > > The reason I ask for all this, is that I want to understand how things > work under the hood before relying on a Python framework to handle the > nitty-gritty. Good scheme. TJG -- http://mail.python.org/mailman/listinfo/python-list