Python on the Web

[Bruno Desthuilliers]

Phil a écrit :
> 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

Seems correct.

> 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?

Yeps.

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

Not AFAICT.


> 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?

I didn't bother reading Flup's source code, but I suppose this might be 
the case.

> 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.

Nor about which web server you use (Apache, lighthttpd, whatever).

> 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.

My humble opinion (based on years of experience in both Python and web 
programming) is that you're taking the wrong approach. I can only second 
  Robert Kern here: use an existing, well maintained wsgi-compliant 
framework like Django, Pylons etc, and wait for the framework to be 
ported to python 3.x. Any other solution will almost certainly end up 
needing a complete rewrite anytime soon.

> 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.

Programming for the web - whatever the language & techno - indeed 
require a deep (or at least correct) understanding of HTTP and web 
servers, yes. Even with the abstraction layers provided by frameworks, 
you still need to understand how the whole damn thing works, what's an 
HTTP resquest & response and quite a few other things as well.