mod_python

People coming from PHP often find it hard to grasp how to use Python in the web. Their first thought is mostly because they think that this is the equivalent to mod_php. Actually it is not really. It does embed the interpreter into the Apache process, thus speeding up requests by not having to start a Python interpreter every request. On the other hand, it is by far not “Python intermixed with HTML” as PHP often does. The Python equivalent of that is a template engine. mod_python itself is much more powerful and gives more access to Apache internals. It can emulate CGI, it can work an a “Python Server Pages” mode similar to JSP which is “HTML intermangled with Python” and it has a “Publisher” which destignates one file to accept all requests and decide on what to do then.

But mod_python has some problems. Unlike the PHP interpreter the Python interpreter uses caching when executing files, so when changing a file the whole web server needs to be re-started to update. Another problem ist the basic concept – Apache starts some child processes to handle the requests and unfortunately every child process needs to load the whole Python interpreter even if it does not use it. This makes the whole web server slower. Another problem is that as mod_python is linked against a specific version of libpython, it is not possible to switch from an older version to a newer (e.g. 2.4 to 2.5) without recompiling mod_python. mod_python is also bound to the Apache web server, so programs written for mod_python cannot easily run on other web servers.

These are the reasons why mod_python should be avoided when writing new programs. In some circumstances it might be still a good idea to use mod_python for deployment, but WSGI makes it possible to run WSGI programs under mod_python as well.