Hey, get this!

[Just]

In article <42023B66.9020309 at holdenweb.com>,
 Steve Holden <steve at holdenweb.com> wrote:

> > 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__().

Yes. PEP 302 came about when I tried to reimplement PEP 273 (zip import) 
in a "sane" way ("saner" is probably as far as I got...).

Import is indeed very confusing, especially because of packages. I tried 
to convince Guido at some point to simplfy package imports by getting 
rid of __path__ altogether (and then simply search for 
"packagename/submodule.py" on sys.path) but he disliked the idea of 
widening submodule imports that much. On the other hand, __path__ is a 
mutable list so people can get the same effect by adding stuff to it.

> 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.

Yeah, it's a PEP, not official documentation, but since there isn't any 
official documentation, all you've got is the PEP :(

> 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.

Probably.

Just