Standard module for import hacks?

[Matthew Knepley]

>>>>> ">" == James Rauser <j.rauser at science-factory.com> writes:

  >> Hi, is imputil.py in the 2.2.1 distribution *really* a part of the standard library?  I would like to do some
  >> import hacks (see below), but the information I can find about the "right" way to do it is contradictory.  I've
  >> found references to __import__ (low-level), "ihooks" (no code) and imputil.py (in the library, but not documented).
  >> The Import-SIG seems to be inactive, but I found an old mail in which Guido says that imputil.py is still
  >> experimental, and other references which say that its performance is bad.

  >> Here's the task: we want to use Python as the scripting language for our bioinformatics software, which is
  >> organized as an (open-ended) collection of C++ shared libraries.  These libraries are *not* written as python
  >> extensions, but they contain meta-information on their exported names which I can use to automagically map the
  >> exported functions into python callable objects.  With this I can create and initialize a python module object.
  >> The code to do this is in an extension module 'pysf', in a function "sfimport". So, now I can write:

  >>   import pysf # get the root module for our python interface
  >>   pysf.sfimport("FOO") # map libFOO.so into a python module "pysf.FOO"
  >>   from pysf import FOO # I get tired of typing pysf.FOO all the time
  >>   FOO.bar("zot")

  >> What I'd like to do is eliminate the strange call to pysf.sfimport() and the nested module names and just be able
  >> to write

  >>   import pysf # get root module, set up import hook
  >>   import FOO # map libFOO.so onto python module FOO
  >>   FOO.bar("zot")

  >> I'd like to do it in a way that will coexist with any other packages that also hack the import mechanism.  What's
  >> the right mechanism?
  I believe the right way to go about doing this is to use ihooks.py. The functionality in __import__ is too high
  level. For instance, it will not allow you to override the search path, just the name binding in the importing
  space. Likewise, imp is too low-level and not modular enough. The ihooks stuff allows you to target exactly
  what you want to override (with Hooks() or by deriving a class from their basics).
       I have used ihooks in the computational PDEs project here. I made import

    a) Search the entire path for parts of a module, even if some of its is already found (nice for open ended modules)

    b) Consult a database and augment the search path during import

  In order to do this I made an 'importer' module which must be loaded first that overrides the default import
  mechanism, as shown in ihooks. Hope this helps.

             Matt

  >> TIA, Jim

  >> -- ------------------------------------------------------------------------ Jim Rauser Science Factory GmbH
  >> mailto:j.rauser at science-factory.com Unter Käster 1 Tel: +49 221 277 399 204 50667 Cologne, Germany

-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness