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