list at joreybump.com
Mon Jan 24 23:29:39 EST 2005
Graham Dumpleton wrote: > Graham Dumpleton wrote .. > >>Do we need to document properly first the perceived problems and some >>examples of errornous behaviour? This will help to ensure we fix >>everything and provide a basis for some tests of any new implementation. Good idea. A battery of tests helps to demonstrate what is really happening. Thanks for the examples. > Continual reloading of modules > ------------------------------ > [Tue Jan 25 09:04:40 2005] [notice] mod_python: (Re)importing module 'index' > with path set to '['/Users/grahamd/Sites/publisher/subdir-2']' > > You will see how as one cycles between the two URLs corresponding to the > modules, that the modules are reimported everytime. > > Overall what is returned is correct, but it isn't efficient because each > request is triggering a module import. Isn't this consistent with published modules requiring unique names? The important thing is that the os module is not being reimported. As you say, it's correct, and should be emphasized in the documentation, but not necessarily "fixed". > Cross contamination of modules > ------------------------------ > Because modules of the same name are reimported on top of the existing > module you can end up with cross contamination of modules in respect of > global variables, functions, class definitions, module imports etc. > > The most obvious problem this causes with publisher, is that one can > suddenly have appear in a module a function from a different module. This > function then becomes accessible using an appropriate URL via the module > in which it doesn't belong. > > Overall this is annoying and could be problematic for those unaware. Once again, stress this limitation in the docs: Don't reuse published module names. > Sticky modules obscuring real module > ------------------------------------ > > Create and "index.py", "subdir-1/index.py" and "subdir-2/index.py" all > containing: > > import os > def index(): > return os.getpid(),__file__ > > Now cycle through accessing these in the order: > > index.py > subdir-1/index.py > index.py > subdir-2/index.py > index.py > subdir-1/index.py > index.py > subdir-2/index.py > ... > > In my case this is: > > /~grahamd/publisher > /~grahamd/publisher/subdir-1 > /~grahamd/publisher > /~grahamd/publisher/subdir-2 > /~grahamd/publisher > /~grahamd/publisher/subdir-1 > /~grahamd/publisher > /~grahamd/publisher/subdir-2 > /~grahamd/publisher > ... > > The result for this is: > > (521, '/Users/grahamd/Sites/publisher/index.py') > (521, '/Users/grahamd/Sites/publisher/subdir-1/index.py') > (521, '/Users/grahamd/Sites/publisher/subdir-1/index.py') > (521, '/Users/grahamd/Sites/publisher/subdir-2/index.py') > (521, '/Users/grahamd/Sites/publisher/subdir-2/index.py') > (521, '/Users/grahamd/Sites/publisher/subdir-1/index.pyc') > (521, '/Users/grahamd/Sites/publisher/subdir-1/index.pyc') > (521, '/Users/grahamd/Sites/publisher/subdir-2/index.pyc') > (521, '/Users/grahamd/Sites/publisher/subdir-2/index.pyc') > > One can see that once one of the "index.py" files in the subdirectories is > accessed, they become sticky and the latest one accessed from a subdirectory > is returned instead of the top level one when it is accessed. > > This one has got to be a bug. Hmmm, yet there is a pattern. I wonder if there is some method to this madness. In any case, all of your examples reuse published module names, which shouldn't be done in Publisher. When you abandon that practice, what bugs are actually left? Here's something that misled me a few months ago (with apologies to Nicolas): Create 2 modules, in the same directory, named master.py and slave.py: master.py: import slave def hello(req): return slave.hello slave.py: hello = "Hello, world!" Access http://host/master/hello and "Hello, world!" appears in the browser. Now move the files into a subdirectory and access http://host/subdir/master/hello. It throws up an error: ImportError: No module named slave What happened? It originally appeared as though a module could import adjacent modules, but this failed in a subdirectory. The reason is that the original directory was where the interpreter was defined (with no PythonPath), and so was prepended to the module search path. It doesn't matter where master.py is (as long as it accessible by the defined interpreter), but slave.py must be in sys.path if it is to be imported by a published module. This falls under the "perceived problem" category, in that it's not a bug, but sure looks like one at first. My own practice for coping with this is to set a PythonPath directive, appending a directory outside the DocumentRoot from which I can reliably import modules and packages specific to that interpreter or VirtualHost.