[Python-Dev] Re: .DLL vs .PYD search order

[Guido van Rossum]

[Greg]
> > I'd rather see the builtin machinery move to Python, regardless of what
> > system is used and/or what features are added.

[Marc]
> In the long run that's probably the right direction, but right now
> we are only talking a very small set of additional features,
> which can easily be added to the existing code without too much
> fuzz.

I disagree.  We should do the redisign right rather than tweaking the
existing code.

> Plus it won't slow things down, which is important since
> Python startup time is already an issue all by itself. The
> imputil.py approach of doing (a whole bunch of) recursive Python
> function calls to all kinds of importers will not speed this up,
> I'm afraid. A on-disk lookup table would speed this up, but
> it would also break the current logic in imputil.py, which
> puts importer independence above all.

I don't care about the current logic in imputil.  It's only a prototype!

> IMHO, we should retreat to a more centralized interface,
> one which more resembles a manager rather than the agent
> interface implemented in imputil.py. Add-ons can then
> register themselves to say "hey, I can handle pyz-archives"
> or "I know how to import .so modules" or "I provide a
> search function which you can call to have me scan
> my module container (directory, web-site, archive)".

This makes sense.

> The manager would take care of what to call and in which
> order, plus delegate requests to add-ons which implement
> the needed logic, e.g. add-ons for signature checking, unzipping
> archives, file system lookup tables, etc.
> 
> It could also trace its actions and then keep an on-disk
> knowledge base for what it did in the past to find certain
> modules under certain conditions.
> 
> Anyway, all this is extra magic for some future version of
> Python.

I would say the manager API design and a basic set of specific
handlers should go into 1.6.

--Guido van Rossum (home page: http://www.python.org/~guido/)