[Python-Dev] Import redesign [LONG]

[James C. Ahlstrom]

Greg Stein wrote:
> 
> I would suggest that both retain their *exact* meaning. We introduce
> sys.importers -- a list of importers to check, in sequence. The first
> importer on that list uses sys.path to look for and load modules. The
> second importer loads builtins and frozen code (i.e. modules not on
> sys.path).

We should retain the current order.  I think is is:
first builtin, next frozen, next sys.path.
I really think frozen modules should be loaded in preference
to sys.path.  After all, they are compiled in.
 
> Users can insert/append new importers or alter sys.path as before.

I agree with Greg that sys.path should remain as it is.  A list
of importers can add the extra functionality.  Users will
probably want to adjust the order of the list.

> > Implementation:
> > ---------------
> >
> > - There must clearly be some code in C that can import certain
> >   essential modules (to solve the chicken-or-egg problem), but I don't
> >   mind if the majority of the implementation is written in Python.
> >   Using Python makes it easy to subclass.
> 
> I posited once before that the cost of import is mostly I/O rather than
> CPU, so using Python should not be an issue. MAL demonstrated that a good
> design for the Importer classes is also required. Based on this, I'm a
> *strong* advocate of moving as much as possible into Python (to get
> Python's ease-of-coding with little relative cost).

Yes, I agree.  And I think the main() should be written in Python.  Lots
of Python should be written in Python.

> The (core) C code should be able to search a path for a module and import
> it. It does not require dynamic loading or packages. This will be used to
> import exceptions.py, then imputil.py, then site.py.

But these can be frozen in (as you mention below).  I dislike depending
on sys.path to load essential modules.  If they are not frozen in,
then we need a command line argument to specify their path, with
sys.path used otherwise.
 
Jim Ahlstrom