quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Popowich <dpopow...@comcast.net>
Subject Re: [mod_python] psp_site example doesn't work
Date Tue, 25 Jan 2005 02:18:07 GMT

Responding mostly to Grisha's comments of what I wrote...

Gregory (Grisha) Trubetskoy writes:
> [I'm kinda answering Daniel's and Nicolas's point here at the same time, 
> so whatch the >> to see who said what. Also shifting this to 
> python-dev@httpd]
> On Mon, 24 Jan 2005, Nicolas Lehuen wrote:
> > On Mon, 24 Jan 2005 12:19:46 -0500, Daniel Popowich <dpopowich@comcast.net>
> >>
> >> Thank you Jorey for your detailed email, but I have to disagree with
> >> you when you wrote:
> >>
> >>     This is consistent with normal Python behaviour, where an
> >>     interpreter loads modules from the current directory or
> >>     PYTHONPATH. [1]
> >>
> >> I came to mod_python after *many* years of intensive python
> >> programming and as a newbie to mod_python was caught by this issue for
> >> days.
> Sure, blame it on the computers! :-)

Of course!!  ;-)  Actually, what took me days was figuring out that I
couldn't make it work the way I needed (wanted) it too.

> >> The way mod_python imports files
> Maintaining the subject distinction here is very important. The way
> "mod_python imports" != "Python import imports" != "publisher imports"

Agreed!  The thread was getting a bit fuzzy on this point.  (And I'm
partially to blame.)

> >> all at the same root level is very UN-pythonic.
> Mod_python imports modules using apache.import_module(), which tries to be 
> behaviorally very similar to the Python import statement, except it 
> supports autoreloading and error logging.
> It is also important to consider that apache.import_module() is 
> documented as part of the mod_python interface and is the rcommended 
> method for importing inderectly imported modules.
> The publisher handler uses apache.import_module() as well, and 
> specifically _this_ I think is the subject of the debate here. (I.e. 
> should the publisher use a different import?)

Yes, that's the issue!!  Sorry if I wasn't clear.  I think publisher
should use a mechanism similar to those discussed in this thread and
what you used for psp: cache the code, keyed on filename, using exec,
execfile, compile, etc.

> >>         code = {}
> >>         execfile(fname, code)
> >>         cache[fname] = code
> >>     # search code dictionary for what I'm after, e.g.:
> >>     handler = code.get('handler')
> There are three things that I see here that need some consideration:
> 1. execfile() does not support .pyc, .pyo or .so/DLL files. If we're only 
> talking publisher here this is not a big deal. In case of 
> apache.import_module() I think this would be too severe of a limitation.

Again, I have no problem with apache.import_module(), just publisher
using it.  So I'm only talking about publisher using such a mechanism.

> 2. modules imported indirectly would still clash. Assuming index.py 
> contains 'import x' below:
>    dira/index.py
>    dira/x.py
>    dirb/index.py
>    dirb/x.py
> x.py will only be imported once. This could be addressed by making it 
> clear that "clash immunity" only applies to the actually published 
> modules, but not the ones the reference. Still I can see this causing some 
> similar hair-pulling as what Daniel experienced :-)

Agreed.  But at some point the hand-holding has to stop, right?  :-)
As I said earlier today, I've always found python's (native python's)
importing mechanism a bit too Baroque for its own good and this only
gets compounded (with interest) when it's embedded in a process where
you don't have control over one of the importing mechanism's tools:
the CWD.  The newbie import questions won't truly go away until
there's a well written section in the manual about importing issues
and it should strongly suggest by example, in IMHO, putting business
logic in packages outside of DocumentRoot.

> 3. You need locking. (As Nicolas pointed out).


> >> Since publisher should "own" the modules it will import
> s/"own"/not add to sys.modules
> s/import/publish

I like your substitutions!

> ...
> ...

> >> There is an issue of both the python module infrastructure and 
> >> mod_python
> What's the difference between "python module infrastructure" and 
> "mod_python", or did you mean "mpservlets"?

Imagine a handler using an execfile() mechanism, but the files it's
publishing are named with .py extensions.  Meanwhile another source
file can import it using apache.import_module().  So the handler will
have a cached copy as well as sys.modules.   ...to be continued...

> >> With mpservlets I took the path of enforcing servlets to be in a file 
> >> that cannot be imported by other modules (they have to be named .mps); 
> >> this did two things: 1) prevents the double caching problem and
> I'm not very clear on point (1), or rather that having a module in 
> sys.modules and another copy in some cache is a problem to begin with.

...continued...yes, I think it a problem to have a module both in
sys.modules and in another cache, so I enforce naming servlet source
files with a mps extension so they can't be imported otherwise.

> >> 2) promotes the separation of interface code from business logic code.
> This sounds like something from a Java book, but I see the point. :-)

Touche.  Through the heart.  Mortal wound.  :-)

Truth hurts: I do require that the class in the file have the same
name as the file (sans mps extension).  But in my defense, this was
motivated less by java-like-styling and more by the practical issue of
finding the damn thing in the code.

> >> But if mpservlets was adopted into the main-stream distro...!  :-)
> >
> > I'd say, why not ? I think it's a good thing mod_python is designed
> > the way it is. mod_python.apache provides a very low-level interface
> > to the Apache mod API.
> This is something that has been brought up in the PMC I believe (or may be 
> I was just thinking of doing so), and basically we just need to all agree 
> that this is something that is well done and fits well.

When I donated mpservlets to the project some time ago I was told it
needed an ASF license (which I've applied to all my code) and
documentation in the format of the rest of mod_python's doc (which I
haven't gotten too yet, but is on my late winter list).  This was all
nearly a year ago, but I'm still game...

> I personally haven't had a chance to play with mpservlets to have an
> informed opinion.

It may be too much to download, install, etc. but there's a live
tutorial, complete with source viewing at:


> > We could even package in a WSGI implementation !
> That'd be a step backwards IMO :-)

Please, no WSGI!!!

> > However, I think mod_python should provide a default high level 
> > implementation, a little bit more convenient than mod_python.publisher.
> Well, my personal opinion is that mod_python lacks on the low-level end 
> (Apache API) more than it does on the high-level end, even though HL is 
> something that gets more publicity (which is quite natural). The raison 
> d'etre for mod_python is the Apache API, rather than a cool framework for 
> dynamic websites, though the latter is a nice compliment to the former.

I understand your sentiments.  Really.  And perhaps you don't want
mod_python to be co opted by HL fru-fru.  Very understandable.
However, there is a NEED out there in the python world for a
lightweight, extensible, HL framework.  After all these years there's
really nothing out there that doesn't tie you into some monolithic

If other python developers' stories are like mine then there's a small,
but ever-growing army of devotees to python trying to convince
management that python is the way to go...and in a desperate attempt
to prove their point (what ever happened to trust, anyway...jeesh)
they have to go out and find the python answer to php, or asp or jsp
or WebObjects, etc.  Along the way they eventually come upon
mod_python, the de facto python-in-apache tool, but there's nothing HL
that comes-with.  It's a hard sell.  (Except, perhaps, psp, but
code-inside-html is whole other ball of wax.)

Obviously, I'm biased, but I think one possible solution is a module
like mpservlets which is lightweight, extensible and requires no
buy-in to a theology.  Well, OK, you gotta name your files with the
mps ext and all that class naming crap, but it's a really, really,
tiny religion!  :-)

If would-be-python-web-programmers came to www.modpython.org and saw
the live servlet tutorial there (along with a number of other HL
handlers on demo) we just might help the python movement.

Then again, you may think this is all horse hockey and has nothing to
do with modpython's mission...


Daniel Popowich

View raw message