StianSøiland
stian at soiland.no
Mon Jul 7 18:15:16 EST 2003
On 1970-01-01 01:00:00, Sean Reifschneider wrote: ~~~~ (.. importing the mail archives appearantly does not work that well anymore :=) ) > On Tue, Jun 10, 2003 at 09:12:46AM +0200, David Fraser wrote: > >Do you mean you're using this import mechanism when you have the problem > >with jotweb.input.Request below? > > I mean that the imp module call is loading a module which then does an > "import jotweb.input". If in the jotweb I don't have the __init__.py > import all sub-packages or sub-modules, I will get an AttributeError > such as: > > AttributeError: 'module' object has no attribute 'input' I can confirm the very same problem. We've been scratching our heads today. [ in this post I'll be quoting python code like /print "Python example"/ ] We're using mod_python.publisher as PythonHandler, and have some library functions in /usr/local/nav/navme/lib/python. As our PythonPath seems to be totally mucked up, refering to /usr/lib/python and so on, we .. as a quickfix.. set it manually PythonPath "['', '/usr/local/lib/python2.2/site-packages', '/usr/lib/apache/python/lib/python2.2', '/usr/lib/apache/python/lib/python2.2/plat-linux2', '/usr/lib/apache/python/lib/python2.2/lib-tk', '/usr/lib/apache/python/lib/python2.2/lib-dynload', '/usr/lib/apache/python/lib/python2.2/site-packages', '/usr/local/nav/navme/lib/python', '/usr/local/lib/python2.2/site-packages', '.']" (/usr/lib/apache/python/lib/python2.2 is our threadless installation, this is Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_python/2.7.8 Python/2.2.2 mod_ssl/2.8.12 OpenSSL/0.9.6b PHP/4.1.2) The problem was weird, in a method logout() in index.py, we try /from nav.web import state/. This always fail, both if we do it on a module level or inside the function. However, /from nav.web import auth/ works fine. The permissions are perfect, there are no .pyc-files hanging around, and there is really no big differences between the two files. Actually we found out that symlinking nav/web to nav/webb - and trying /from nav.webb import auth/ WORKED, suggesting some problems with caching. Several apache-restarts gives no more help. Using /usr/lib/apache/python/lib/python2.2/bin/python from the shell, running as httpd, with the same PythonPath as above (verified by req.write("%s" % sys.path) ), from nav import auth works perfect. The 'fix' you suggested, using import auth in nav/web/__init__.py - DID work, however, as in your case, there is no reason why this should be neccessary. In SOME of the cases in this testing, the error message is not from /usr/local/nav/navme/apache/webroot/index.py (where the import actually happens), but from mod_python/apache.py in the function import_module. This function looks pretty weird to me, I tried adding some debug sentences to follow the execution paths. However, it turns out that our trouble-module nav.web.state is used as a fixup handler as well, PythonFixupHandler nav.web.state. Renaming to /PythonFixupHandler nav.webb.state/ removes the bug, /from nav.web import state/ suddenly works again. So in our case, the problem is related to the module being used both in handlers and imported by submodules. Appearently the errors from mod_python.apache.import_module appears only those times the PythonFixupHandler won't load. (debug messages reveal that import_module is NOT called by the normal import sentence - that's good, as I couldn't understand how it could have been called at that time :=) ) However, the problem is still unsolved, although the __init__.py-import is a working workaround (the symlink magic is NOT! :=) ) Is your problem-module a part of other headers (or imports) as well? (our team is also very pissed of by the need to restart apache every minute to force reloading of all modules. It's seems like a boring job to do like in 3.1 - as it still does not assure that modules are reloaded only once and in the correct order. A simple-but-stupid reload-all-modules-known-to-python fix did NOT work, as subclasses in different modules get totally confused being subclassed by some class that no longer exist. The problem is reloading in the correct order, and only once per request. Is there a nice way to UNLOAD all classes? I'm thinking of something like /del sys.modules['mymodule']/ - but.. I'll have to check the module to see if it's mine or some internal python module first :=) ) -- Stian Søiland Work toward win-win situation. Win-lose Trondheim, Norway is where you win and the other lose. http://www.soiland.no/ Lose-lose and lose-win are left as an exercise to the reader. [Limoncelli/Hogan]
|