Python on the Web
phily05 at gmail.com
Wed Aug 26 18:54:55 CEST 2009
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
More information about the Python-list