[mod_python] Subinterpreters and index.py

Nicolas Lehuen wrote:
> Jorey Bump wrote:
>
>>Modules are namespaces, regardless of their physical 
>>location. This is very important, even within subinterpreters.
> 
> I do understand this, and that's why I think that the module defined in
> /app/index.py should not be overwritten by the one defined in
> /app/subdir/index.py. Maybe the namespace of the module defined by
> /app/subdir/index.py should be created within the namespace of the module
> defined by /app/index.py, so that the latter would inherit names from the
> former ? It seems that the publisher load each .py file as modules based on
> the filename only, hence the name collisions. If directories or URIs could
> be taken into account, this collision problem would disappear.

Modules of the same name cause collisions. It's that simple. To avoid 
collisions, create packages and name them carefully. It's like 
indentation: It imposes a discipline that has enormous benefits that 
aren't immediately apparent.

The file hierarchy is important to the mechanics of creating your 
environment (setting the PYTHONPATH, creating packages, etc.), but plays 
no part in the logic of your application. Just as you can't give two 
files in the same directory the same name, you can't give two modules in 
the top level of your application the same name. If you want to reuse a 
name, you have to distinguish it by placing it within a package. There's 
no need to force mod_python to do this, when you can indicate this 
yourself by placing __init__.py in the directory you want to package. 
Automagic packaging could break a lot more than it fixes (you'd have to 
memorize every module or package in your path before creating directories).

>>mod_python already puts the directory at the front of the 
>>sys.path. You can determine this by creating a module:
> 
> [snip code]
> 
> Well, that's the first thing I tried a few month ago, but that's not the
> case on my installation (Apache2 + mod_python running on Windows 2000 SP4).

I'm currently developing on Debian Gnu/Linux, and it's likely that there 
are important configuration differences in my environment.

> Maybe this is due to the fact that I used the PythonPath directive ? I
> defined it like this (in httpd.conf) :
> 
> LoadModule python_module python/mod_python.so
> AddHandler mod_python .py .psp
> PythonPath
> "sys.path+['C:/apache/python/Lib','C:/apache/Subversion/python','C:/apache/t
> rac']"
> PythonHandler mod_python.publisher | .py
> PythonHandler mod_python.psp | .psp
> PythonDebug On

I use this, and nothing else (apache 1.3.26, mod_python 2.7.8):

<Directory /var/www/site>
   AddHandler python-program .py
   PythonHandler mod_python.publisher
   PythonDebug On
</Directory>

Obviously, this is an older, patched version and there will be 
differences. The main point is that it might be better to start with a 
simple configuration and find a Python-based solution, rather than 
trying to bend mod_python to your will.

> How can I benefit from the behaviour you describe while also declaring the
> libraries I need on the Python path ?

This depends on your environment and your privileges. First, try the 
test I outlined to verify your path under Apache/mod_python (remove your 
PythonPath directive for the test).

One solution is to create packages in your existing path. Anything you 
put in your installation's site-packages directory will be available to 
everyone on the system. In fact, that's why it was created.

If you don't like or have that option, see if the default path suggests 
a place for your packages. If not, you may want to specify a single 
location for convenience and security, and preface your path with it. 
The benefits of this are clearly dependent on your target environment.

Wherever you end up putting your packages and modules, remember that, 
unlike HTML, they don't need to be in your DocumentRoot, just your 
PYTHONPATH. This means that you can create a single interface for each 
application:

  /var/www/app/app1.py
  /var/www/app/app2.py
  ...

This encourages you to create generic packages that can be easily shared 
by all of your applications. Don't worry about index.py, unless you want 
to control *all* of your applications from that single file (just add a 
new function to launch each app). An index.html will serve the purpose 
just as well.

It's great to have power and exercise it, but it's even nicer to be 
waited on hand and foot. Let Python do some of the work for you.