

Don't use mod_python - rams
http://wiki.python.org/moin/PoundPythonWeb/mod_python

======
rcoder
This of course disregards the #1 reason to use mod_python (or mod_perl,
mod_ruby, or any other fully-integrated scripting language Apache module):
namely, because you're not just limited to generating dynamic content.

The Apache request-handling chain is much richer than simply passing off
incoming requests to a CGI or PHP script. Using mod_{perl,python,ruby,etc.},
you can implement authenticators, URL-rewriting modules, log handlers, output
filters, etc., and take advantage of the mature Apache infrastructure for such
code.

Basically, if you want to be able to slice and dice HTTP requests at every
stage of processing, not just the content-generation one, the Apache mod_*
add-ons are a pretty powerful tool for doing just that.

~~~
hobbs
You can get all of that by using mod_rewrite/mod_fastcgi/mod_wsgi to
passthrough to a full-blown Python app server running behind the web server as
a separate process. All of the other mod_* authentication and authorization
hurdles will still be evaluated first.

~~~
rcoder
While it may be _possible_ to get the same level of control over the request
lifecycle using mod_rewrite and simple dynamic content generation, it can
often be awkward and slow compared to doing the same thing via a full-blown
Apache scripting module like mod_python.

Case in point: I'm currently working on an application that uses mod_auth_kerb
to perform Kerberos password authentication on behalf of users, then fork a
background server which has access to that user's Kerberos credentials, and
proxy future connections from that user to the dedicated backend.

Doing that using mod_rewrite requires using the RewriteMap 'prg:' map type,
which introduces a single choke-point in the application: namely, the single
script responsible for spawning the backend servers. That script also runs in
the _one_ Apache master listener, which means that no other incoming requests
will be answered until the rewrite script returns its output.

If I were instead using mod_perl (as I suspect I will be, before this moves
into production) I would be able to have each Apache child process handle its
own forking of backends for requests it was handling.

------
alexk
Mod_python seems to be very promising and robust from the first sight. I've
tried mod_python and it left me delighted for several reasons; some of them:

1\. You can get total control over the request.

2\. Mod_python provides a set of wrappers to mimic standart python CGI objects
what greatly simplifies your life

3\. Basic load tests say that mod_python is robust and fast

4\. Installation is easy

The only thing that I've found confusing is unicode support (take a look at
[http://www.modpython.org/pipermail/mod_python/2004-June/0158...](http://www.modpython.org/pipermail/mod_python/2004-June/015825.html))

The only thing that I need to know about mod_python - is the list of
successful commercial deployments.

What about the cons, I would also like to know who are these guys from this
PoundPythonWeb, they look like someone official, but I'm always feel
suspicious when someone says: "Don't use this" (except the case when the
person is the author :))

------
davidmathers
A very unconvincing list.

1\. That's what package managers are for.

2\. If you're in the position of configuring your own web server then this
probably doesn't matter to you.

3\. See #1.

4\. True, but your /usr/bin/python processes will be lighter because they
won't exist.

5\. I have no idea if this is true, but no evidence is provided.

6\. My personal experience with mod_proxy has been...unhappy.

7\. ???

8\. See #5.

------
tlrobinson
I'm currently just using mod_python for my Trac installation, but it's
ridiculously slow. Any suggestions?

Edit: I switched to using fcgi and it's _wayyyy_ faster. So there's reason #9.

------
wave
Is there any merit to this wiki? The author isn't known but does the stated
reason worth abandoning mod_python? I don't think so.

~~~
j2d2
The wiki is primarily discussing theory of administering a web system with a
little bit about resource distribution. The ideas all have merit, but you need
to decide how important they are. I, for example, don't mind having to upgrade
a webserver, language and module simultaneously. I don't do this on production
systems, so my services won't go down. I'll build the new system, test it,
replace the old one and that's that. It's not really an issue to upgrade a few
pieces of software together in the full scope of my testing processes.

------
DanielH
Basically you should use mod_wsgi these days...

~~~
simonw
Yup. mod_wsgi is written by one of the core mod_python maintainers and is
essentially a much more modern take on the whole problem of running Python
code within Apache. It's powerful, flexible, easy to configure and it even
works well with shared hosting (you can give each user their own process group
which restarts when they "touch" a file in their home directory). I'm a total
convert.

------
clintavo
I thought the whole point of mod_python was performance. Since it runs inside
the apache process it doesn't have to spawn a new python interpreter for every
page request. Am I mistaken? Does fastcgi and/or mod_wsgi solve the same
issue?

~~~
rcoder
All three work if your goal is simply to avoid forking a new Python
interpreter for each incoming request, ala CGI.

The difference is in where they hook into the request-handling workflow within
Apache. Both FastCGI and WSGI apps only receive the request after Apache (or
lighttpd, nginx, et. al.) have finished doing access control checks, URL
rewriting, header parsing, etc.

Code inside the mod_python interpreter, on the other hand, can hook in to any
of those earlier stages of request processing, which allows it to do things
like block a request, alter the Apache log format, or look up a vhost docroot
in a database, all before any content is generated.

The downside is that each and every Apache process on your server has a full
copy of the Python interpreter embedded inside, which can cost you a pretty
serious chunk of RAM when you start dealing with servers running 25-50 (or
more) httpd processes.

------
smoody
"...which makes wsgi applications (which can be deployed through several ways)
very flexible..."

What are the preferred ways to deploy wsgi apps?

