[mod_python] psp_site example doesn't work

Nicolas Lehuen wrote:

> A lot of the problem caused by import_module() and the
> mod_python.publisher come from two very simple mistakes :
> 
> 1) it is not necessary IMHO to have published moduled imported in the
> same namespace than other 'standard' modules.
> 
> 2) Using the 'import' keyword or the 'imp' modules are not the only
> ways to import modules. Like you wrote, import and imp use a dotted
> naming scheme for the modules, and have a rather complicated search
> path algorithm. This is NOT what should be used to import published
> modules whose place in the filesystem follows a publication scheme
> instead of a modularization scheme.
> 
> The daily message from a new puzzled user should remind us that
> publishing a module is NOT the same thing as importing it in standard
> Python parlance. mpservlets, Vampire and other publishers have shown
> that it's quite easy to import modules without using import or imp.
> Separating published modules from standard modules should be done
> ASAP, and I think everybody will save mental health when it will be
> done ;).

Your argument holds a lot of water, and you've described the situation 
very well. But I feel that Publisher is very simple, and a decent manual 
  would only be a few pages long. After reading it, a user could sit 
down with "Learning Python" and immediately start writing a web 
application. Little tweaks that start giving Publisher its own syntax 
could also interfere with good mental health.

> Another proof that mixing published and standard module is a bad
> design choice is that you end up putting constraints (through the path
> parameter in import_module) to make sure that only modules from the
> published filesystem are published. This is inefficient at best. Have
> a look at what CherryPy does, for example : function and object which
> can be published are just marked as such. Anything else can't be
> published. There's no need to worry about path restrictions and so on
> and so forth.

Yes, but I think that Publisher is meant to be more of a transparent 
interface between apache and Python, with some useful conveniences 
thrown in for web development. I don't find myself thinking much about 
Publisher internals when I'm developing an application. CherryPy 
requirements are a lot more prominent in the code.

> I'm sorry to be a little harsh on the subject, but for now, I think
> mod_python is far from being an user-friendly web development
> environment. 

True, especially if you're expecting something with a builtin for every 
purpose. But I find it to be a transparent, programmer-friendly 
environment, because I just need to use ordinary Python commands and 
packages. I immediately develop reusable code, including code that isn't 
restricted to mod_python or web applications (parsing an Excel file, for 
example). I've even written modules that can run as a standalone web 
application, a command line application, or imported into another 
module, all in one file. I'd hate to see special syntax added to 
Publisher that makes this impossible. I *like* using ordinary import 
statements. :)

> For power users who can wrap their head around the
> various bugs^H^H^H^Hfeatures, it's perfect, but judging from the
> volumes of "Can't make mptest.py to run" or "Can't import yada_yada
> module from index.py" messages, there's still a lot of things to cope
> with to get a bigger user base. I definitely think the import
> mechanism and mod_python.publisher need urgent and radical
> improvements.

I rarely encounter software that works reliably and predictably well, 
and I include Publisher in that category. When something "just works" 
for me, talk of improving, fixing, or eliminating it makes me nervous. 
I'm not terribly motivated by joining a larger herd (I've gotten used to 
all of my favorite TV shows being cancelled). But there *are* choices, 
including Publisher, CherryPy, Vampire, mpservlets, etc. My concern is 
that Publisher will be turned into something more like the others, 
thereby eliminating my choice.