[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