Mod_python vs. application server like CherryPy?

[Graham Dumpleton]

Vincent Delporte wrote:
> On 5 Dec 2006 17:05:06 -0800, "fumanchu" <fumanchu at amor.org> wrote:
> >In a nutshell, mod_python gives you
> >access from Python to the Apache API, whereas CherryPy and friends give
> >you their own API.
>
> I didn't know Apache had an API of its own, or that it was even needed
> when writing a web application in Python. What does it provide in
> addition to Python/mod_python?

Although Apache does have a quite considerable underlying API of its
own, mod_python doesn't actually provide direct access to much of it
from Python code. What mod_python does provide is still adequate for
getting basic stuff done, but Apache could perhaps be better harnessed
if all the Apache API were exposed and available.

Where the power of Apache comes into play is the ability to compose
together the functionality of different Apache modules to build up an
application. That is, you aren't just doing everything in Python code.
That said though, this doesn't mean you have to go off and write code
in another language such as C. This is because the Apache modules are
glued together through the Apache configuration files with some
features also being able to be enabled from Python code running under
mod_python.

In some respects you need to see the whole of Apache as being a
platform for building a web application. Unfortunately, most Python web
application developers don't see that and simply use Apache as a
convenient hopping off point for the main content handling phase of a
request. Even where people do write stuff which makes use of mod_python
as more than just a hopping off point, more often than not they still
work within just mod_python and don't bring in other parts of Apache to
any degree.

For example, consider an extreme case such as WSGI. Through a goal of
WSGI being portability it effectively ignores practically everything
that Apache has to offer. Thus although Apache offers support for
authentication and authorisation, a WSGI user would have to implement
this functionality themselves or use a third party WSGI component that
does it for them. Another example is Apache's support for enabling
compression of content returned to a client. The WSGI approach is again
to duplicate that functionality. Similarly with other Apache features
such as URL rewriting, proxying, caching etc etc.

Although WSGI is an extreme case because of the level it pitches at,
other systems such as CherryPy and Django aren't much different as they
effectively duplicate a lot of stuff that could be achieved using more
basic functionality of Apache as well. Once one starts to make use of
the underlying Apache functionality, you are binding yourself to Apache
though and your stuff isn't portable to other web servers. Also, your
job in part becomes more about integrating stuff to come up with a
solution, rather than just writing pure Python code, something that
many Python coders possibly wouldn't find appealing. :-)

Graham