[mod_python] Graham's New Importer

On 10/05/2006, at 12:57 PM, Graham Dumpleton wrote:

> Dan Eloff wrote ..
>> I think probably just:
>>
>> PythonOption importer.path "C:\Documents And Settings\..."  
>> "another path"
>>
>> I'm not sure the syntax allows for that, but something along those
>> lines is the idea. None of those paths should be on sys.path.
>>
>> You shouldn't be able to specify this more than once for each python
>> interpreter. I don't know how to enforce that, but it would prevent
>> any wierdness with the same module being imported under different
>> circumstances in the same interpreter.
>
> The only way you could enforce that it only be set once is to have it
> take two arguments, one being the interpreter name and the other the
> path, and only honour the option when it is set in the global Apache
> configuration. That is, read from:
>
>   apache.main_server.get_options()
>
> This is restrictive though, as makes it impossible to set it in a  
> local
> .htaccess file.

Now, FWIW, you can actually do sort of what you want now. It uses an  
aspect of
the module importer though for which how the interfaces will  
eventually be made
publically usable isn't finalised. That said, what you should be able  
to do is
put the following at the start of a module.

   from mod_python import apache
   __info__.path.extend(eval(apache.main_server.get_options().get 
('my_import_path','[]')))

The path you want to search has to be in global part of Apache  
configuration.
Its form should be like PythonPath, ie., Python list, but shouldn't  
reference
sys.path. Thus, just a list of directories.

   PythonOption my_import_path "['C:/Documents And Settings/...','C:/ 
Some/Other/Path']"

The '__info__.path' is a special attribute of data kept in module by  
the importer
and acts as an embedded search path for modules. Once you have set that
from code above run at global scope within module, it is possible to  
use "import"
or "apache.import_module()" after that point and the directories you  
added will
be searched for the module you want.

Now although it is the intention that this hook for a search path be  
able to be
used, a final name and means of accessing it haven't been worked out.
It would have been nice to be able to use "__path__" instead of  
"__info__.path",
but "__path__" is special to Python and stuffs up normal imports if  
specified in
non package contexts.

Overall, I have been thinking whether the following naming changes  
should be
made:

   __info__ --> __mp__

   __clone__ --> __mp_clone__
   __purge__ --> __mp_purge__

Ie., use "mp" designator to make it clear that this is mod_python stuff.

At the same time, could add:

   __mp_path__ == __mp__.path

Ie., "__mp_path__" would be an alias for "__mp__.path". You would  
need to
make sure though that you always appended, inserted or extended the path
through the alias as assignment would break the association and import
code would only look at "__mp__.path".

By a module explicitly adding items to the embedded search path, it  
would be
more predictable perhaps than blindly always using what the option  
may be set
to, as by adding the code in you are making a conscious decision that  
you want
it to work that way. You need not even use an option to obtain what  
the path
should be set to, you could also use hard coded paths, or a path  
determined by
taking a relative path and adding it to the dirname of the __file__  
attribute of the
module.

If you understand the feature above I am describing, will be  
interested in your
comments as to usability and also as to what naming conventions  
should be
used. It is because I hadn't worked out naming that I hadn't  
mentioned this
feature before.

Graham