Python on the Web

[Graham Dumpleton]

On Aug 27, 2:54 am, Phil <phil... at gmail.com> wrote:
> 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