[mod_python] Any thoughts on the import problems?

Graham Dumpleton grahamd at dscpl.com.au
Sun Oct 3 10:55:58 EDT 2004


On 03/10/2004, at 6:08 AM, Sean Reifschneider wrote:

> I just wanted to follow up on my previous message:
>
>     
> http://www.modpython.org/pipermail/mod_python/2004-September/ 
> 016289.html
>
> Any thoughts on what that problem is or how to approach it in
> mod_python?  I've looked at the mod_python code a bit, but really don't
> understand enough of it to be able to gain any traction.

Looking at your previous post, can't see why you are expecting not to  
get the
error:

    Mod_python error: "PythonHandler foo::handler"

    Traceback (most recent call last):

      File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line
    299, in HandlerDispatch
        result = object(req)

      File "/home/httpd/modpythonpublishertest/py/foo.py", line 5, in
    handler
        module.function(req)

      File "/home/httpd/modpythonpublishertest/py/package/module.py",  
line
    4, in function
        mod_python.util.FieldStorage(request)

    AttributeError: 'module' object has no attribute 'util'

I am sure others would have pointed out the obvious that module.py  
isn't self
contained as far as importing what it requires. Ie., in:

       import mod_python

       def function(request):
          mod_python.util.FieldStorage(request)

you should have:

   import mod_python.util

and not just:

   import mod_python

I am perhaps missing the point of what you are trying to demonstrate,  
but you
shouldn't rely on mod_python module to have automatically imported util  
as a
sub module or for some other module to have already loaded it as then  
you get
order dependencies.

That said, I have had strange problems with mod_python.publisher  
before, where
even though I had all the correct imports, it would come up with a  
similar error
for it, but only in the case where the handler had been modified and  
thus
mod_python had decided to reload it.

Note that the situtation was where I was using my own handler which so  
happened
to have:

   import mod_python.publisher

This was so I could use the authorisation mechanisms in that module  
explicitly in
my own handler.

It was a very strange situation that I could never work out and which  
may have been
complicated by the fact that mod_python.publisher was specified as a  
handler using
SetHandler in a different part of the directory hierarchy.

Because I had no control over the Apache web server and could not  
simply stop and
start it when I sometimes got this, I would add something like the  
following evil
lines into the start of the handler file which was the problem.

   import sys
   try: del sys.modules["mod_python.publisher"]
   except: pass

This would precede the import of mod_python.publisher and thus when the  
import was
reached, the fact that it had been explicitly removed out of  
sys.modules would
caused it to be reimported correctly.

Yes, I realise that deleting modules out of sys.modules isn't the most  
sensible
thing to do, but sometimes I find it quite useful. What I use is a  
special set of
functions callable by mod_python.publisher which give me things back  
like the
current sys.path and list of modules loaded under sys.modules. I then  
have a purge
method which I can use to add in code to delete any modules I want to  
delete
straight out of sys.modules. This might be used where you import a  
module but at
run time it has errors. Because "import" was used, your normal course  
of action
is normally to restart Apache, something which in the environment I am  
in I could
not do. Thus, instead of a restart of Apache, I delete the offending  
modules out
of sys.modules and then touch the handler module which uses the import  
so it gets
reloaded and import is rerun.

Okay, it is a hack, but if you are careful, can be a lifesaver. :-)

--
Graham Dumpleton (grahamd at dscpl.com.au)



More information about the Mod_python mailing list