[mod_python] RE: is mod_python borked?

Sells, Fred wrote ..
> I've just gotten started with mod_python, using it for about 2 weeks, and
> can offer these insights(?)
> 1. easy install and getting started
> 2. simple mods to apahce conf to "invoke" it
> 3. really cool code if using the publisher

As long as you don't run up against the trailing slash and base url issues. ;-)

Personally I don't like publisher as it is, but to fix it properly would most
likely break a lot of existing user code.

> 4. only limitation I've found is that you need to restart apache when you
> deploy .py changes.  There may be a way around this, but it wasn't worth
> the effort to me to explore.

In current versions of mod_python, although there are some fiddles you can do
to limit your need to do restarts, unless you use a particular third party
implementation of the publisher extension which embeds its own improved module
importer, often you still can't avoid the restarts.

The good news is that this improved module importer has been incorporated into
mod_python for 3.3, so practically all the problems most people encounter will
go away.

For more details see:

  http://www.dscpl.com.au/wiki/ModPython/Articles/ModuleImportingIsBroken

> 5. if you're using Session objects, take special note of the "lock" option.
> If you try to get the same session object twice during the same execution
> cycle (i.e. POST) it hangs with the default setting.  Some may argue that
> getting the same thing twice is just sloppy code, and they may be right,
> but when the wolf's at the door you gotta...

Best practice is to use code like:

  if not hasattr(req, 'session'):
    req.session = Session.Session(req)

  # then use req.session

This way if the session has already been created by an earlier handler, then
you will pick it up from req.session avoiding the creation of the session again
and a deadlock. PSP uses this convention, so if using PSP from inside of
publisher you will not have problems if the PSP pages use sessions.

Things can still get a bit tricky if you are using req.internal_redirect()
though. What you can do there depends on which version of mod_python you are
using.

> I was able to write a security handler that intercepts all .py and .html
> references and assures login before access is granted.  web site developers
> are unaware of my "intercept" so they cannot bypass it.
> a simple controller, that is the only file that is web specific, calling
> my backend logic that also runs from command line for debugging.
> none of the above was more than 1/4 page of code.

Hmmm, only a quarter of a page. Don't know how long your page is, but even if I
remove all the comments and blank lines from my forms based login/session
manager it is getting up around 100 lines. This doesn't even include the login
page itself which is outside of the handler. I also haven't updated it yet in
line with some recent changes in mod_python 3.3. I have though tried to make my
handler quite bullet proof, be generic and work in with Apache's auth
mechanisms properly so it is probably longer than what others may come up with.
The thing is that it is quite tricky to get correct and have it work in all
situations. Most implementations I have seen have some problem or limitation.

Anyway, important thing is that it sounds like you have at least not tried to
do it in the PythonHandler phase like most do, which to my mind is the wrong
way of going about it. It should be done in an earlier phase so that it can
cover non mod_python stuff as well, like you indicate your version does.

> There are (too?) many python web frameworks.

Agreed. What is also annoying is that none are really truly integrated with
mod_python and the Apache way of doing things. Instead they use the response
handler phase of mod_python as merely a jumping off point. A framework that
properly integrates with mod_python and Apache and harnesses the fact that
there are other modules for Apache which aren't written in Python and which can
be used would be quite powerful. Unfortunately, mod_python to date has had
various shortcomings which have made this hard to do. Changes in 3.3 improve
this situation immensely and some really good stuff should be able to be done
with it. Only thing which will be missing is the ability to use auth providers
in Apache 2.2 which is one thing we haven't got around to yet.

> > I am considering python, instead of php, for web-application
> > development. I often see mod_python.criticisized as being borked,
> > broken, or just plain sucking.
> > 
> > Any truth to any of that?

In answer to your question of whether mod_python is borked, the answer is yes
and no.

One sees various people complain about mod_python. In some cases their claims
are valid, but in other cases they are wrong and haven't bothered to work out
how it works. Even when their claims are valid, they often don't understand the
problem properly. To use mod_python properly also means in a lot of cases
understanding how Apache works, which many are too lazy to do. For example, the
difference between SetHandler and AddHandler and what happens when MultiViews
is enabled. 

One of the biggest problems is that a lot of ISPs still use Apache 1.3 and so
only mod_python 2.7.X is available on those platforms. This version is quite
old now and doesn't behave exactly the same as more recent versions, yet people
read the most recent documentation and complain it doesn't work as they expect.

Even where people are using Apache 2.0 and thus can use newer versions of
mod_python, they sometimes use RedHat enterprise versions of Linux which are
stuck in a time warp with only 3.1.X versions of mod_python available. Some of
the other Linux distributions haven't been much better until recently and with
people refusing to compile from source code and demanding RPMs, DEBs or other
prepackaged releases are only bringing it on themselves.

Version 3.2.X has been an improvement over older versions. Significantly it
fixed multithreading issues on Windows and with worker MPM on UNIX. For
publisher at least, it addressed some of the module importer issues, but not
all. It has also addressed some major memory leaks.

So in summary, if you use the most recent version you are obviously going to
have the least problems. Many still use older versions though and can't or
will not upgrade. Even the current version has known issues and you can get
a feel for what is known by going through issues at:

  http://issues.apache.org/jira/browse/MODPYTHON

In particular the number of separate issues which will be addressed in 3.3 is
getting up towards 100. These aren't all bug fixes, with many being new
features and improvements. The most important change will be the replacement of
the module importer, with the issues fixed by that being listed in the article
I referenced before.

So, use an older version of mod_python and the answer to the question of
whether it is borked is mostly yes. Use the current version and except for
module importer issues, the answer is mostly no. With version 3.3, the answer
should hopefully be a string no.

Anyway, that has satisfied by need for a Friday rant. :-)

Graham