[mod_python] psp_site example doesn't work

Jorey Bump list at joreybump.com
Mon Jan 24 14:32:05 EST 2005

Nicolas Lehuen wrote:
> On Mon, 24 Jan 2005 16:28:47 +0100, Nicolas Lehuen
> <nicolas.lehuen at gmail.com> wrote:
>>On Mon, 24 Jan 2005 09:12:24 -0500, Jorey Bump <list at joreybump.com> wrote:
>>>Nicolas Lehuen wrote:

>>The problem is that mod_python.publisher does not follow the standard
>>Python way in that it imports published modules as root-level modules.

Yes, it's true that it strips away leading path information to put all 
modules on an even plane. I find this an easy adjustment to make. 
Imports done by published modules obey sys.path, so I don't see any 

>>It's as if mod_python.publisher changed sys.path for each and every
>>published module. This is not the standard Python way, and the source
>>for many errors.

The main effect is that the DocumentRoot might get prepended to sys.path 
instead of the directory containing the published module. But a single 
interpreter must have a single working directory, so I consider this an 
elegant solution.

If you modify the path with the PythonPath directive, this will no 
longer be the case. The DocumentRoot is not prepended to the path and 
you will be limited to the directories explicitly listed in PythonPath. 
This can lead to surprising behaviour if you created some modules and 
packages in the DocumentRoot, because they will no longer work properly.

To me, this seems very much like a feature, and not a bug, because it 
allows you to finetune your environment and offers some nice security 
capabilities. You are right that it's not expected, but it's not 
necessarily inconsistent, once you get used to it.

Fortunately, I tend to create packages that are available for my apps 
and put them in predictable locations in the module search path, so I'm 
not bit by this. You are right that this can be a serious problem for 
anyone expecting sys.path to be identical to python run from the command 
line, but it's really a mod_python configuration issue.

>>Note that the current package system in Python is way, way smarter
>>than mod_python.publisher : in a package, you can import fellow
>>modules by giving their local names. It's not recommended by
>>pychecker, but it works. The smart part is that if I have this :
>>     package1.py
>>     __init__.py
>>     package1.py
>>     package2.py
>>Then whatever I do, /subdir/package1.py is imported as subdir.package1
>>and does not collide with /package1.py. mod_python.publisher is not as
>>smart, this is very confusing and surprising, nearly everybody
>>complains about this and hence, I think this should be filed as a bug.

To be accurate, Python does not import fellow modules or packages -- it 
prepends the directory containing the main module to sys.path and limits 
imports to sys.path. As seen above, mod_python also obeys sys.path, so 
be sure your imported modules/packages are there.

>>So maybe apache.import_module should not be modified (except for
>>performance, but that's another issue which is already in the bugs
>>database), but mod_python.publisher sure has to be changed.

Its behaviour is consistent, once you understand it, so I don't see a 
need for the change.

> Or it could be the sign that mod_python.publisher should be completely
> erased from the project, since it poses much more problems than it
> solves. Maybe we should include both mpservlets and Vampire in
> mod_python, and forget about the default publisher (except maybe for
> compatibility issues).

Yikes! Publisher is simply the best web application framework I have 
ever used. I've never felt a need to move beyond it, and I'm not menaced 
by the issues that seem to bother others. I'd rather see it more heavily 
promoted and the intricacies explained in some more detail. Once you 
comprehend a few simple rules, it's incredibly powerful and productive. 
   Grisha created a thing of beauty in Publisher, but its simplicity is 
lost on many people. To remove it would be madness...

More information about the Mod_python mailing list