Python/import.c should be replaced by the implementation under
development contained in the py3k-importlib branch.

OK, so first step is to simply replace __import__ w/ importlib.__import__ using builtins.__import__ in order to make sure that all tests pass as expected. Can probably do this by doing the switch in Py_Initialize() somewhere.

Next step after that will be seeing if _io can be used by importlib w/ the import of os postponed until after importlib is bootstrapped.

Just some notes on the branch:

The FAILING file contains tests known to fail. There is a comment explaining the failure and possible fixes. If something makes it here and stays for a while it probably means upstream changes are needed (eg. test_pydoc needs ImportError to grow an attribute as to what import failed).

Python/pythonrun.c contains XXX markers of what is left to be done (although currently the zipimport comment is out-of-date and there needs to be one for exposing some APIs created in importlib.__init__). If you are looking for something to do, just search for XXX and try to tackle one of the comments.

AFAICT, #1559549 is the ImportError attribute ticket.

OK, I'm down to a single bug to be solved to call this work a "success" (there are other test failures, but they are not overtly difficult to solve).

At this point the bootstrapping is failing in the face of sub-interpreters. Specifically, when I try to load the frozen importlib code in Py_NewInterpreter() it leads to an assertion failure in the GC code when handling references in a GC generation. I have zero experience with sub-interpreters and my GC experience is rusty, so if anyone can have a look at the code I would appreciate it to see if they can figure out why loading a frozen module (while in marshal) is leading to a GC assertion error.

Thanks to Benjamin, the test_capi assert failure is fixed. At this point the only failures are listed in the FAILING file and are (probably) minor.

Is there a benchmark for import? How slow is importlib? :)

On Mon, Feb 6, 2012 at 17:06, STINNER Victor <report@bugs.python.org> wrote:

>
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
>
> Is there a benchmark for import? How slow is importlib? :)
>

importlib.test.benchmark

bench_startup.py: short script to compute the best startup time (I wrote the original script for the hash collision issue, #13703). Result on my PC:
 - original: 22.2 ms
 - importlib: 27.9 ms

So importlib adds an overhead of 25.7% in startup time.