One last thing that we should prepare is a clear and definite answer to the zillion users who need to import a custom utility module. Today, we have 4 ways of importing code :
a) the standard "import" keyword. Today, it works unchanged (mod_python doesn't install any import hook). The consequence is that the only modules that can be imported this way are those found on the PYTHONPATH. Importing custom code is easy if you can manipulate this variable (either directly or through the PythonPath configuration directive), but not everybody has this luxury (think shared hosting, although not being able to change the PythonPath through an .htaccess file seems pretty restrictive to me.). b) the PythonImport directive, which ensure that a module is imported (hence its initialization code is ran), but doesn't really import it into the handler's or published module's namespace. c) the apache.import_module() function, which is frankly a strange beast. It knows how to approximately reload some modules, but has many tricks that makes it frankly dangerous, namely the one that causes modules with the same name but residing in different directories to collide. I really think that mixing dynamic (re)loading of code with the usual import mechanisms is a recipe for disaster. Anyway, today, it's the only way our users can import some shared code, using a strange idiom like apache.import_module('mymodule',[dirname(__file__)]). d) the new publisher.get_page(req,path), which is not really an answer since it is designed to allow a published object to call another published object from another page (not to call some shared code). This mess should be sorted out. As a baseline, I'd say that we have 4 kinds of code in mod_python : 1) the standard Python code that should be imported using the "import" keyword 2) handlers, which are dynamically loaded through apache.import_module (so they are declared in sys.module, with all the problem that can cause when sharing a single setup with multiple handlers that have the same name, "publisher" for example) - this should be fixed. 3) published modules, which are dynamically loaded by the mod_python.publisher handler (so now they don't have any problems that were previously caused by apache.import_module). An important thing to notice is that published module are usually stored in a directory which is visible by Apache (handlers don't need to reside in a public directory), amongst .html and image files. Hence, people can legitimately be reluctant to put their core application code (including DB passwords etc.) in published modules, for security and code/presentation separation issues. 4) custom library code, AKA core application code. This code should reside somewhere, preferably in a private directory (at least direct access to this code from the web should be denied) and be easily imported and reloaded into published modules, without having to tinker too much with the PYTHONPATH variable or the PythonPath directive. What would be nice is a clear and definite way to handle those 4 kinds of code. To me, layers 2, 3 and 4 could be handled by the same dynamic code cache, except that a careful directory structure or naming scheme would prevent the layer 4 to be visible from the web. I know Vampire solves a lot of these problems, so we have two alternatives : A) We decide that we won't solve the whole problem into mod_python. We take apache.import_module out and shoot it. Handlers are loaded in a real dynamic code cache maybe the same as the one now used by mod_python.publisher), which solves a lot of problems. Custom library code is not handled : if you want to import some code, you put it wherever you like and make sure PYTHONPATH or the PythonPath directive point to it, so you can import it like a standard module. You'll never use apache.import_module anymore, it will blissfully dissolve into oblivion (and be removed from the module, anyway). If you need to reload your core application code without restarting Apache, then too bad, mod_python doesn't know how to do this. Check out Vampire. B) We decide to solve the whole problem into mod_python. apache.import_module is not much luckier this time, it is still taken out and shot in the head. We solve the handlers loading problem. But now, with a little help from Graham, custom application code can be dynamically loaded and reloaded from any place without having to tinker with the PYTHONPATH variable and/or the PythonPath directive. Everything can be done from the source code with a little help from an .htaccess file. So, sorry for this long mail, but I had to get this out. The current situation is pretty bad, zillions of people need to do this simple thing, and when they notice it's not that simple (or it's buggy), they decide to build the nth application framework on mod_python. So, either we reckon it's None of our business, that users should turn to higher level frameworks like Vampire, and we remove apache.import_module, or we decide to tackle the issue, and we remove apache.import_module. Either way, it must leave :). What do you think ? Regards, Nicolas