[Python-Dev] new imputil.py
Gordon McMillan
gmcm@hypernet.com
Mon, 3 Jan 2000 09:38:11 -0500
Greg Stein wrote:
> On Mon, 3 Jan 2000, M.-A. Lemburg wrote:
[big snip]
> > · Wish list: a distutils importer hooked to a list of standard
> > package repositories, a module to file location mapper to speed
> > up file system based imports,
> For a mapper, we can definitely have a custom Importer that knows
> where certain modules are found. However, I suspect you're
> looking for some kind of a cache, but there isn't a hook to say
> "I found <foo> at <this> location" (which would be used to build
> the mapping).
>
> Suggestions on both of these would be most welcome!
Haven't played with the new one yet. But for awhile I've been
considering a scheme where sys.path[0] has a cache of
known binary extensions { logicalname: fullpath, ... } and
sys.path[-1] is the brute force importer.
For standalones, sys.path[0] could be hardcoded. For normal
installations, sys.path[-1] could inform sys.path[0] when a .so
/ .dll / .pyd is found. So when a new one is installed, the first
use will be expensive, but subsequent sessions would import
it in 1 I/O.
I'd also like to point out that archives *can* be used in a
development situation. Obviously I wouldn't bother putting a
module under current development into an archive. But if the
source is still installed and you haven't mucked with the
__file__ attribute when you put it in the archive, then
tracebacks will show you what you need. IDLE doesn't know
the difference. So for most developers, the standard library
can be served from an archive with no effect (other than speed).
- Gordon