In article <[EMAIL PROTECTED]>,
Steve Holden <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
