quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick <n...@dd.revealed.net>
Subject Re: Solving the import problem
Date Thu, 09 Jun 2005 13:15:12 GMT
Graham Dumpleton wrote:
>> module, from the document tree. Maybe the context of the directive
>> could be used for that ; if the directive is defined at the server or
>> virtual host level, then it's a top level handler, otherwise if it is
>> defined in a Location or Directory (or .htaccess file), then it's a
>> handler that should be loaded from the document tree (with a possible
>> fallback to sys.path if it is not found ?).

Aside from the potential security issues of storing your handler modules in 
the document tree, I just don't it's a good idea to traverse the document 
tree for a python module/package.  Even in a shared hosting situation, there 
are still ways to store your modules outside the accessible document tree. 
I can just see so many confused people wondering why module B was imported 
instead of module A, which reside in different parts of the document tree. 
And module B isn't even a handler, it's a support module.  Ugly.  Not to 
mention name collision problems that are bound to happen when per directory 
interpreters aren't being used in that situation.

> The big problem now is that if the __init__.py file uses standard
> import statement with the expectation that it will grab the module
> or package from within the same directory, it will not work. This is
> because to the Python import system it will not know that it is to
> be treated as a package and look in that local directory first.

Among other minor "gotchas" that crop up from time to time, but you've hit 
the big one.  mod_python itelf isn't a framework as such; I'm for making 
mod_python accessible and usable and all that, but isn't it fair to say that 
mod_python doesn't have to solve *all* import problems?  Handling imports 
automagically from your imported modules requires an import hook...

> I got past this problem in Vampire through the use of the import hook.
> Vampire would stash a special global object in the module so the import
> hook knew that it was a special Vampire managed module and would grab
> the module from the local directory and import it using the Vampire
> module importing system rather than standard Python module importer.
> At the moment though this only works at global scope and not when
> import is used in the handler code when executed, although can
> probably solve that.

We can probably do some checks to see if we're importing a single module or 
an entire package without resorting to import hooks.   Deal with the modules 
in __all__ (from __init__.py) like we'd handle single module imports, and 
any explicit "imports" in the package beyond that are not reloadable. 
Otherwise they can explicity call apache.import_module.  Document this 
behaviour and keep it simple, otherwise people are not going to be able to 
debug their problems easily.  Not to mention that the code will grow into a 

> Although from/import syntax also works, if it tried to import "a.b" from
> a subpackage, it will not work if "b" wasn't explicitly imported by "a"
> to begin with.

I haven't generally experience that with import hooks, although os (and 
therefore os.path) seems to peskily not import because of some sys.modules 
manipulation weirdness.

> The question thus is, if you understand what I am raving about, is
> whether it is reasonable that packages will not be supported by
> apache.import_module(). There is a slim chance some ones code may
> break as a result but the majority would work fine.

See above.


View raw message