Python on the Web

[Phil]

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? Does it just spawn a new thread for each
request? 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?

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.

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

I realize there is a large number of questions, so thanks for any help.

 

[Robert Kern]

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

 

[Phil]

Thank you for the helpful and timely response.

My interest in Python 3.1 was actually to develop a framework. Again,
I can feel the flames. I understand there are enough frameworks but
I actually have no applications that I wish to develop. I enjoy
developing these kinds of things from scratch as a learning
experience.

I've been doing fine with 2.x and WSGI, even without understanding
half of this stuff. It is actually my first Python project. Haha. I
just have my own design philosophies that I wish to experiment with.
Python 3.x just makes everything nicer with UNICODE, etc.

Although you've been helpful with almost all of the mentioned
concerns, I am still looking for more details on some of the questions
I've asked. So, if others stumble upon this post, feel free to
contribute further.

Thanks again.

 

[Phil]

No offense intended, but that's probably the worst approach to take.

Frameworks created for the sake of creating a framework, as opposed to
those written to meet a defined need, tend to be the worst examples of
masturbatory coding.

No offense taken. I understand your concern. I actually do have some
important design decisions I wish to meet. It has sort of been a
process of evaluating the things I love and hate most from existing
frameworks.

 

[Graham Dumpleton]

No offense intended, but that's probably the worst approach to take.

Frameworks created for the sake of creating a framework, as opposed to
those written to meet a defined need, tend to be the worst examples of
masturbatory coding.

I would in part actually disagree with that.

The problem with people creating frameworks to meet some defined need
is that they often implement only just enough of that framework to
meet that need and nothing more. End result is that the framework is
more often than not ever fleshed out enough to be of much use to
anyone else. Its existence though just pollutes the Internet with more
crap that one has to wade through.

Since there is already a plethora of good frameworks out there, if
writing an application, you are better of using one of the existing
frameworks. If interested in working at the framework level, you would
still be much better off looking at the existing frameworks, first
learn how they work and then consider contributing to them, rather
than implementing your own.

For some related reading, see:

http://lucumr.pocoo.org/2009/7/30/nih-in-the-wsgi-world

As far as low level framework (or anti frameworks), suggest looking at
Werkzeug, Paste/Pylons and bobo.

I'll comment more on original message later.

Graham

 

[Graham Dumpleton]

A few additional comments on top of what others have said.

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?

Technically it receives and responses to request based on HTTP
specification, not WSGI specification. The underlying HTTP server
translates to and communicates with a Python web application using the
WSGI interface.

Does it just spawn a new thread for each
request? If so, then how is this any different than a production
server with FCGI?

I would describe there as being four major ways that WSGI can be
hosted. These are:

1. Custom build HTTP/WSGI server written in Python. Production quality
examples are CherryPy WSGI server and Paste HTTP server. You shouldn't
use wsgiref for anything but very simple stuff.

2. Per request process execution by way of CGI and a CGI/WSGI adapter.
This could be under Apache or any other web server which supports CGI.

3. Module that embeds Python interpreter into a C based web server.
Example are mod_wsgi and mod_python for Apache. Note that mod_python
would infrequently be used to host WSGI and doesn't include its own
WSGI adapter. These days mod_wsgi for Apache would be used. Processes
in this would be persistent.

4. Module in a web server that allows one to communicate using a
custom protocol with a separate persistent web application process
hosting the web application through a WSGI interface. This convers
FASTCGI, SCGI and AJP. The mod_wsgi module for Apache has a hybrid
mode which work in a similar way but uses an internal protocol.

Amongst these, there are many variations as far as number of process
and threads. For a bit of discussion about this in relation to
mod_wsgi read:

http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

The way I am understanding the 'Production' side of that picture is
that the web server (eg. lighttpd) creates a single FCGI process.

FASTCGI isn't restricted to a single process, nor single threading.
Whether a particular implementation allows for the variations depends
on the implementation.

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?

As I've read elsewhere, "These days, FastCGI is never used directly.

Even back in time, I don't think it was really ever used as a generic
interface that people worked with directly, there was always a more
usable layer built on top of it.

Just like mod_python it is only used for the deployment of WSGI
applications.

The mod_python module isn't used just for WSGI applications and is
probably rarely used for them. This is because mod_python has its own
interface for building web applications. It also has abilities to hook
into Apache request handling phases, meaning it can do more than host
a a content handler/web application.

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.

WSGI provides for portability, it isn't necessarily easier to use than
mod_python.

What would be involved to run Python on the web using FCGI without
WSGI? I can feel the flames already.

No, you really don't want to do that.

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.

Then look at mod_wsgi. It already has support for Python 3.X. Some
aspects of how it implements WSGI 1.0 may change, but will not be too
much and details are being sorted out in the back rooms as we speak.
See:

http://code.google.com/p/modwsgi/wiki/ChangesInVersion0300

The other option is CherryPy WSGI server as that is close to a Python
3.X release as well, as I perceive it.

I wouldn't bother waiting for WSGI 2.0. That is more of a pipe dream.
There will be an updated WSGI 1.0 for Python 3.0.

Graham

 

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

 

[Phil]

Thanks to everybody. I believe I am understanding things better.

I have looked at the links that have been provided, although I have
seen most of them in the past month or so that I've been looking into
this stuff. I do agree with most of the things Armin stated in that
NIH post. I agree with everybody in this thread so far. If I wanted to
write an application, I would use an existing framework and wait for
it to be ported to 3.x. However, I do not have the need to write a web
application at this time, and creating blogs or other applications I
do not need for fun is getting old.

My reasoning for working on my own instead of following the 'NIH'
concept or contributing to an existing framework is because I have
experimented with many existing frameworks and I have figured out what
I like/dislike, and have envisioned my own design that I feel would
work potentially better for others, or at least newcomers. Things like
this are fun for me, and I do not mind the challenge. I don't want to
pollute the web with (sigh) 'another framework', but it would be fun
for me to write it and get some feedback. I would love for people like
you, Armin, and others who take a look at the various frameworks that
pop up seemingly every day, to look at my (hypothetical) framework and
just rip it apart with (constructive) criticism. That is just the way
I do things, whether the community agrees with it or not. The reason I
was asking about Python 3 on the web was just because I like some of
the changes that have been made, and would like to use it for my
framework. That is when I realized that I was absolutely clueless
about the details of how Python, or any language, works on the web.

Graham, regarding number 3 in your list of ways to host WSGI: I
haven't really looked into mod_wsgi at all, but basically it sounds
like the web server would be running this embedded module. That module
would then serve the function of both FCGI and the 'WSGI Server' in my
diagram? That actually sounds really neat. Unfortunately I missed this
because I've been hooked on lighttpd, as the minimalist I am.

Here are the things I am still confused with:

1) Why do I not want to consider running Python on the web with FCGI,
without WSGI? You said 'no' straight up, no questions asked. I would
imagine that there is a good reason of course, as you've been in this
field for a long time. I just feel more comfortable understanding why.
From my understanding, the only real purpose of WSGI is to remain
independent of FCGI/SCGI/CGI/AJP (whatever that is) and the web server
it is run on. However, 99.9% of the discussion I see with Python on
the web is around FCGI. So for example, lets say everybody used FCGI.
All that would be left to deal with is web server independence. Now
this is what I don't get, I thought that FCGI itself was supposed to
be the protocol that deals with web server independence. Maybe I just
need to re-read entire WSGI specification to understand, along with
all the details of FCGI. There are just so many details regarding web
servers, FCGI, and WSGI that it is hard to absorb it all and see how
it works together. That is why I tried to create the diagram, but it
doesn't provide enough details. And those are the details I am
missing. I've been trying to find a simple diagram or explaination of
the process a request takes to make a response, from HTTP all the way
up to the application, to the the user.

2) In the development stack, the 'WSGI Server' seems to take on the
role of the web server (dealing with HTTP specification), skips FCGI,
and deals with the WSGI specification. Then, the 'WSGI Server' in the
production stack (eg. Flup, CherryPy, etc) only deals with FCGI and
WSGI specification, because the HTTP is already taken care of by the
web server?

 

[Graham Dumpleton]

Thanks to everybody. I believe I am understanding things better.

I have looked at the links that have been provided, although I have
seen most of them in the past month or so that I've been looking into
this stuff. I do agree with most of the things Armin stated in that
NIH post. I agree with everybody in this thread so far. If I wanted to
write an application, I would use an existing framework and wait for
it to be ported to 3.x. However, I do not have the need to write a web
application at this time, and creating blogs or other applications I
do not need for fun is getting old.

My reasoning for working on my own instead of following the 'NIH'
concept or contributing to an existing framework is because I have
experimented with many existing frameworks and I have figured out what
I like/dislike, and have envisioned my own design that I feel would
work potentially better for others, or at least newcomers. Things like
this are fun for me, and I do not mind the challenge. I don't want to
pollute the web with (sigh) 'another framework', but it would be fun
for me to write it and get some feedback. I would love for people like
you, Armin, and others who take a look at the various frameworks that
pop up seemingly every day, to look at my (hypothetical) framework and
just rip it apart with (constructive) criticism. That is just the way
I do things, whether the community agrees with it or not. The reason I
was asking about Python 3 on the web was just because I like some of
the changes that have been made, and would like to use it for my
framework. That is when I realized that I was absolutely clueless
about the details of how Python, or any language, works on the web.

Graham, regarding number 3 in your list of ways to host WSGI: I
haven't really looked into mod_wsgi at all, but basically it sounds
like the web server would be running this embedded module. That module
would then serve the function of both FCGI and the 'WSGI Server' in my
diagram? That actually sounds really neat. Unfortunately I missed this
because I've been hooked on lighttpd, as the minimalist I am.

Here are the things I am still confused with:

1) Why do I not want to consider running Python on the web with FCGI,
without WSGI? You said 'no' straight up, no questions asked. I would
imagine that there is a good reason of course, as you've been in this
field for a long time.

Because FASTCGI is a wire protocol for socket communications and not a
programming interface. As such, you would only be creating much more
work for your self as you would need to implement a whole lot of code
to handle the protocol and then still put a usable interface on top of
it. You would also have to come up with what that usable interface
should be as well. WSGI already provides that low level interface.

I just feel more comfortable understanding why.
From my understanding, the only real purpose of WSGI is to remain
independent of FCGI/SCGI/CGI/AJP (whatever that is) and the web server
it is run on. However, 99.9% of the discussion I see with Python on
the web is around FCGI.

99.9% of the discussion about Python on the web is not around FASTCGI.
Even if there is quite a bit of discussion, it is because
documentation on hosting Python on FASTCGI via flup is virtually non
existent and so many people have a lot of trouble getting it to work
due to peculiarities of different FASTCGI implementations. The
dicusssion is therefore because people have problems with it, or feel
the need to blog about how they finally got it to work. So, FASTCGI
may be the only way for commodity web hosting, but it certainly isn't
for self managed servers where mod_wsgi, mod_python and mod_proxy type
solutions are going to be preferred. The latter are better documented
or easier to setup and so why you possibly don't see as much
discussion. In other words, people who get things working easily don't
need to ask questions.

So for example, lets say everybody used FCGI.
All that would be left to deal with is web server independence. Now
this is what I don't get, I thought that FCGI itself was supposed to
be the protocol that deals with web server independence. Maybe I just
need to re-read entire WSGI specification to understand, along with
all the details of FCGI. There are just so many details regarding web
servers, FCGI, and WSGI that it is hard to absorb it all and see how
it works together. That is why I tried to create the diagram, but it
doesn't provide enough details. And those are the details I am
missing. I've been trying to find a simple diagram or explaination of
the process a request takes to make a response, from HTTP all the way
up to the application, to the the user.

FASTCGI fills a role, but is not essential. Personally I feel that
whole concept of FASTCGI/SCGI/AJP needs a refresh and modernised with
better hosting support for it.

2) In the development stack, the 'WSGI Server' seems to take on the
role of the web server (dealing with HTTP specification),

It doesn't have to. Some servers may have a clear line between the two
with WSGI being a properly distinct layer on top.

skips FCGI,
and deals with the WSGI specification. Then, the 'WSGI Server' in the
production stack (eg. Flup, CherryPy, etc) only deals with FCGI and
WSGI specification, because the HTTP is already taken care of by the
web server?

Graham

 

[Phil]

Thanks a lot for another response. I've never posted in groups like
this before but the results are amazing.

I will definitely consider trying mod_wsgi when I get a chance. I like
the approach taken with it. It is unfortunate that I completely missed
all Apache related material because I was using lighttpd. Is there no
mod_wsgi for lighttpd? I guess I could always just Google that myself.

Thanks again for the help.

 

[Graham Dumpleton]

Thanks a lot for another response. I've never posted in groups like
this before but the results are amazing.

I will definitely consider trying mod_wsgi when I get a chance. I like
the approach taken with it. It is unfortunate that I completely missed
all Apache related material because I was using lighttpd. Is there no
mod_wsgi for lighttpd? I guess I could always just Google that myself.

There is no mod_wsgi for lighttpd and suggest there never will be.
WSGI doesn't lend itself to working on top of an event driven system.
Someone did get a mod_wsgi going on nginx, which is also event driven,
but it has limitations due to possibility of blocking other traffic to
web server. See:

http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html

Graham

 

[Bruno Desthuilliers]

Phil a écrit :
(snip)

However, 99.9% of the discussion I see with Python on
the web is around FCGI.

May I suggest you spend some time reading django-users and django-dev on
google groups ? (and that's only *one* of the way-too-many Python web
frameworks).

 

[Phil]

Thanks Graham. I actually ended up reading that blog post from a
Google search last night before I saw your response. It was very
informative.

Bruno, I will take a look at those groups to expand my knowledge. When
I gave that arbitrary percentage, I was basing it off of the
information I had seen with regards to launching applications built
with existing frameworks using lighttpd. I do realize I was missing a
lot of information by looking up something that specific. I also
understand that there are enough frameworks. That still won't change
my mind. I do not want to write a web application, otherwise I would
use an existing framework as suggested. I just wanted to experiment
and see what kind of framework I could develop with some ideas I had
in mind. The original post was mostly just because I was having a
difficulty understanding some lower level concepts as a result of
trying to get Python 3 on the web before figuring out that it wasn't
quite ready for that. I just really like some of the new features of
Python 3, and most importantly, unicode compliance is just that much
straight forward in my opinion.

 

[Aahz]

My interest in Python 3.1 was actually to develop a framework. Again,
I can feel the flames. I understand there are enough frameworks but
I actually have no applications that I wish to develop. I enjoy
developing these kinds of things from scratch as a learning
experience.

Well, there's a standard joke that just as people learning Scheme write
a new language (following SICP), people learning Python write a new web
framework. That's why there are so many of them.

 

[Phil]

Haha. While I don't disagree with you, I seem to be under the
impression that you think I haven't been reading the web where nearly
every blog post complains about the abundance of Python frameworks.
The thing is, most of the frameworks being commented on in such a way
are 'microframeworks' that provide next to nothing. I'm do not mean to
say anything negative about them, but I strongly feel that my approach
will be much more functional without having to include, or at least a
good starting point for newcomers to both Python and web programming.
The ideas I had for mine lied somewhere in between a full stack
framework and a minimalist approach like said microframeworks.

 

[Bruno Desthuilliers]

Phil a écrit :

When
I gave that arbitrary percentage, I was basing it off of the
information I had seen with regards to launching applications built
with existing frameworks using lighttpd. I do realize I was missing a
lot of information by looking up something that specific.

Indeed !-)

I also
understand that there are enough frameworks. That still won't change
my mind. I do not want to write a web application, otherwise I would
use an existing framework as suggested. I just wanted to experiment
and see what kind of framework I could develop with some ideas I had
in mind.

I wrote quite a couple web and non web frameworks myself - all ending up
in the trash can FWIW, but it certainly has been a very educative
experience by itself.

I just really like some of the new features of
Python 3, and most importantly, unicode compliance is just that much
straight forward in my opinion.

If you're only writing your framework for learning purposes, you could
as well go with Python 3, and implement everything from the ground up
(not a trivial task FWIW).

 

[John Nagle]

A few additional comments on top of what others have said.

Actually, FCGI works quite well. Sitetruth's AdRater
(http://www.sitetruth.com/downloads/adrater.html) uses
FCGI and Python on the server.

FCGI is basically CGI with process reusability. Each
app gets its own process in its own address space with its
own global interpreter lock. mod_fcgi in Apache keeps a
supply of such processes around, launching additional ones if there's
heavy request traffic and shutting down existing ones when there
isn't. Each process handles one transaction after another,
so, unlike CGI, you're not spending all your time loading Python
and its modules.

Here's the main loop of a real FCGI application. This uses a small
WSGI library on the Python side. No "framework" is involved.


#!/usr/local/bin/python
....
from fcgi import WSGIServer
import MySQLdb
db = None # database connection, held open for life of FCGI
#
# The application
#
def QuickSitetruthQuery(environ, start_response):
global db # static global - active database handle
try:
if db : # if previously attached
try :
db.ping() # test whether connection is still up
# handle loss of database connection
except MySQLdb.OperationalError, message:
db = None # we lost database connection
if db is None : # if no valid database handle
db = miscutils.dbattach(kdbfile) # connect to database
status = '200 OK' # normal status
headers = [('Content-type','text/xml'), ('charset','utf-8')]
reqlist = cgi.parse_qsl(environ['QUERY_STRING']) # Parse params
priority = 1 # priority of request
sourceip = environ['REMOTE_ADDR'] # get IP address of client
urls = [] # list of URLs to check
for item in reqlist : # for all items
(key, value) = item # extract item
if key.lower() == 'url' : # want all "url" items
urls.append(value)
elif key.lower() == 'priority' : # if priority
priority = int(value) # get priority value
# Make request; no waiting, no details
outstr = InfoDisplay.getratingXMLquick(db, kdbfile, urls,
priority, sourceip) # get the rating XML, never wait
start_response(status, headers) # compose result
s = kprefixxml + outstr + ksuffixxml # construct output XML
return [s.encode('utf8')] # encode as UTF8
except Exception, message: # if trouble, report to user
# Error handling
status = "500 Internal Error on Server"
response_headers = [("Content-type","text/html")]
start_response(status, response_headers)
s = "<h1>Internal error - request not processed.</h1>\n\n"
+ traceback.format_exc()
s = s.replace("\n","<br>") # convert to HTML
return
#
# Main FCGI program
#
WSGIServer(QuickSitetruthQuery).run()

 

[Bruno Desthuilliers]

John Nagle a écrit :

Python 3 isn't ready for prime time on web servers. Too many major
modules,
haven't been ported yet.

Which ones (sorry, still using 2.5 at work so I didn't bother that much
with 2.6 so far) ?

MySQLdb is available only up to Python 2.5. So the basics
for web work aren't
ready yet.

I wouldn't label MySQLdb as "a basic for web work" - I mean, something
you just can't do without !-)

 

[John Nagle]

If you're only writing your framework for learning purposes, you could
as well go with Python 3, and implement everything from the ground up
(not a trivial task FWIW).

Python 3 isn't ready for prime time on web servers. Too many major modules,
haven't been ported yet. Twisted and Django are now available up to Python 2.6;
MySQLdb is available only up to Python 2.5. So the basics for web work aren't
ready yet.

Python 2.5 is more or less the "stable" version of Python for production
use at the moment. 2.6 is a transition version to 3.0.

John Nagle

 

[Ed Singleton]

Frameworks created for the sake of creating a framework, as opposed to
those written to meet a defined need, tend to be the worst examples of
masturbatory coding.

Indeed, but masturbation is perfectly healthy and acceptable, and we
all do it every now and then. It is however, much like the framework
in question, best kept private and not made public.

Ed