Python on the Web

[Robert Kern]

On 2009-08-25 20:09 PM, Phil wrote:
> I've seen lots of web sites explaining everything, but for whatever
> reason I seem to not be picking something up.
> I am a graphical person, which is probably the reason I haven't found
> my answer.
> May somebody please confirm if my diagram accurately represents the
> stack, generally speaking.
>
> http://i26.tinypic.com/1fe82x.png
>
> Even if that is the case, I'm having a hard time understanding the
> differences. I guess wsgiref has absolutely nothing to do with FCGI/
> SCGI/CGI and simply receives and responds to HTTP requests following
> the WSGI specification?

Correct.

> Does it just spawn a new thread for each
> request?

No, it is single-threaded.

> If so, then how is this any different than a production
> server with FCGI?
>
> The way I am understanding the 'Production' side of that picture is
> that the web server (eg. lighttpd) creates a single FCGI process. The
> FCGI process is actually the entry point of the Framework/Application
> which sets up Flup's WSGIServer, being the interface between FCGI and
> the Framework/Application? What I mean is, it is just the code that
> the web server loads to start with, example...
>      from flup.server.fcgi import WSGIServer
>      from app import application
>      WSGIServer(application).run()
> ... Then for each HTTP request, Flup's WSGIServer creates a new thread
> to handle the request?

Something like that, yes.

> As I've read elsewhere, "These days, FastCGI is never used directly.
> Just like mod_python it is only used for the deployment of WSGI
> applications." As far as I understand, the main (or only?) reasoning
> for this is because WSGI makes Python applications easier to deploy
> without having to worry about whether using FCGI/SCGI/CGI.

Yes, that is the primary reason for WSGI, in my mind. There are other things 
like the composability of applications, but the decoupling of application 
authoring from deployment is the sine qua non, in my opinion.

> What would be involved to run Python on the web using FCGI without
> WSGI? I can feel the flames already. This isn't the only reason I want
> to know, but one reason is that I want to use Python 3.1 and as I
> understand, this will have to wait for the WSGI 2.0 specification to
> ensure time isn't wasted.

I am willing to bet that the FCGI libraries haven't been upgraded to Python 3.x, 
either. I suspect that the most 3.x-updating work will be going into WSGI and 
the adapters. E.g.

   http://www.saddi.com/software/news/archives/64-Dabbling-in-Python-3.0.html

You may want to rethink the Python 3.x requirement, though. It will probably be 
much less a waste of your time to write your app using a framework like Django 
or Pylons on Python 2.x and then upgrade to Python 3.x when they do.

> I apologize if the questions are ridiculous. I've just recently got
> into web programming and it seems that in order for me to use Python,
> I need a deep understanding of web servers, HTTP, FCGI, etc. I have
> more questions but they go more off topic, so I will save it for
> another thread, another day.

Knowing something about HTTP will certainly help get into the right mindset to 
know what limitations and capabilities web apps can have.

Typically, though, you use a framework that abstracts most of this stuff away 
from you. You usually only need to delve into the details in very specific 
circumstances.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco