[mod_python] mod_python and mod_wsgi

On 28/07/07, Evan Klitzke <evan at yelp.com> wrote:
> Hi everyone,
>
> I saw the announcement for the latest mod_wsgi release on
> python-announce today, and I'm curious to learn more about it,
> especially as it compares to mod_python. From what I can tell, the
> primary difference between the two is that while both can run in
> "embedded mode", only mod_wsgi can run in so called "daemon" mode. Are
> there any compelling reasons to use one over the other when using this
> embedded mode? Are there any other significant differences?

Reasons to use mod_wsgi in embedded mode in preference to mod_python.

* In mod_wsgi the SCRIPT_NAME variable required by WSGI applications
is able to be determined automatically, where as with the WSGI
adapters for mod_python you have to help them out and tell them what
SCRIPT_NAME is and they will adjust PATH_INFO correspondingly.

* There are various issues with mod_python documented at:

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

which have still not been fixed, but which are down correctly in
mod_wsgi. These include things related to main interpreter simplified
GIL state API use, atexit processing, reading of request content,
request content size restrictions etc etc. I can't remember them all
off the top of my head.

* Because mod_wsgi is all in C code and doesn't use any Python code
for dispatching or implementing the WSGI interface, it has lower
runtime overhead. It also doesn't need to drag in lots of Python
modules like mod_python so any memory use from Python modules is only
from your own application.

* There is an interpreter reload feature in mod_wsgi which can allow
you to reload a whole application without restarting Apache. Although,
the usefulness of this is limited if your application uses certain
third party C extension modules which have not been written properly
so as to be able to handle interpreters being recycled.

* It is much simpler to configure mod_wsgi for WSGI applications and
no third party adapter is required.

* It works on Apache 1.3 exactly the same.

* Various other things I can't remember at the moment.

Reasons to still use mod_python instead of embedded mode of mod_python.

* It is possible to hook into other phases of Apache such as
authentication/authorisation. This might be needed for example where
you want to use Django user/passwd database to control access to non
Python aspects of the web server such as Subversion repository access.

Although mod_wsgi can't provided this functionality now, a future
companion module to mod_wsgi will however provide some means of
allowing Python code to be used to implement an authentication
provider and/or authorisation control.

* Only WSGI applications can be hosted by mod_wsgi whereas mod_python
is a platform for developing web applications in its own right, giving
access to various internals of Apache as well as providing support for
forms handling, sessions, page templating, URL dispatching etc. If
used correctly mod_python also provides a module reloading
functionality which can also help to avoid having to restart Apache.

Although any interaction between mod_wsgi and Apache is currently
limited to what you can do with Apache directives, for example, using
Apache directives to insert input or output filters, a companion
module to mod_wsgi will in the future optionally provide access to a
full SWIG binding for the Apache API, thus allowing a lot of what
mod_python can currently do to be done, plus a lot of new stuff.

* Various other things I can't remember at the moment.

All up, it really depends on what you are wanting to do. If you are
only wanting to host an existing WSGI application or framework, or the
application you are writing is WSGI compliant and you want to be able
to target it at different hosting platforms, then mod_wsgi will most
likely be a better choice because it is purpose built for that. If you
want to explore using mod_python to control Apache at a lower level,
then mod_python is currently the only way of doing it using the Python
language.

In time mod_wsgi will branch into other areas by way of providing
companion modules which will provide facilities which only mod_python
currently provides, but not sure how long before that occurs. One
thing that has to happen first is that the internal APIs of mod_wsgi
have to be exposed and formalised. Once that is done then these
companion modules can also be written and made available.

Because there will be an API for harnessing the mod_wsgi internals for
Python interpreter creation and management, and for injecting special
Python objects into the WSGI application environment, it may even end
up serving as a platform used by independent parties to develop their
own Apache modules which extend on mod_wsgi and Apache/Python support.
This will make it much easier to develop new Python related stuff for
Apache than currently exists with mod_python as in most cases with
mod_python there isn't a choice but for the new functionality to be
added to mod_python core itself. A person wanting extensions is
therefore dependent on the mod_python developers. The intention is
that this will not be the case with mod_wsgi but that it will have
this open internal interface which can be hooked into without needed
to modify mod_wsgi itself.

Note, I may be a bit biased. ;-)

Graham