Hey, get this!

[Steve Holden]

Just wrote:
> In article <s9zr7jx213w.fsf at salmakis.intevation.de>,
>  Bernhard Herzog <bh at intevation.de> wrote:
> 
> 
>>Bernhard Herzog <bh at intevation.de> writes:
>>
>>
>>>Steve Holden <steve at holdenweb.com> writes:
>>>
>>>>         if package:
>>>>             module.__path__ = sys.path
>>>
>>>You usually should initialize a package's __path__ to an empty list.
>>
>>Actually, normally it's a list that contains the name of the package
>>directory as its only item.  I'm not sure what you should do when you do
>>not import from a file system.
> 
> 
> If it's a path importer, it could be a cookie, specific to the importer. 
> I think in Steve's case initializing __path__ to ["*db*"] should work.
> 
> Just

And that's exactly the conclusion I came to when import of the package's 
submodules didn't work as anticipated.

Coming to the question of writing a customer importer from the 
documentation I discovered there is a huge amount of layered cruft in 
the import scheme going all the way back to the days of the "ni" module. 
It took me two aborted attempts just to realize I should be using PEP 
302 and not ihooks or some wrapper around __import__().

While this may be interesting history it's very confusing, and I'm 
encouraging Alex Martelli to describe the current PEP-302-based scheme a 
little more fully in his forthcoming revision to the Nutshell. The PEP 
is just a little terse in places, I feel.

I'm also wondering if the inspect module shouldn't have a facility to 
hook into custom importers, since its code is pretty much filestore 
based at present. This should probably be via an *optional* API to avoid 
breakage in existing custom importers.

regards
  Steve
-- 
Meet the Python developers and your c.l.py favorites March 23-25
Come to PyCon DC 2005                      http://www.pycon.org/
Steve Holden                           http://www.holdenweb.com/