[Python-Dev] importlib is now bootstrapped (and what that means)

[Georg Brandl]

On 14.04.2012 20:12, Brett Cannon wrote:
> My multi-year project -- started in 2006 according to my blog -- to rewrite
> import in pure Python and then bootstrap it into CPython as *the* implementation
> of __import__() is finally over (mostly)! Hopefully I didn't break too much code
> in the process. =)
>
> Now this is "mostly" finished because the single incompatibility that importlib
> has is that it doesn't check the Windows registry for paths to search since I
> lack a Windows installation to develop and test on. If someone can tackle that
> issue that would be greatly appreciated (http://bugs.python.org/issue14578).
>
> Next up is how to maintain/develop for all of this. So the Makefile will
> regenerate Python/importlib.h whenever Lib/importlib/_bootstrap.py or
> Python/freeze_importlib.py changes.  So if you make a change to importlib make
> sure to get it working and tested before running 'make' again else you will
> generate a bad frozen importlib (if you do mess up you can also revert the
> changes to importlib.h and re-run make; a perk to having importlib.h checked
> in). Otherwise keep in mind that you can't use any module that isn't a builtin
> (sys.builtin_module_names) in importlib._bootstrap since you can't import
> something w/o import working. =)

We've just now talked on IRC about this regeneration.  Since both files --
_bootstrap.py and importlib.h -- are checked in, a make run can try to re-
generate importlib.h.  This depends on the timestamps of the two files, which I 
don't think Mercurial makes any guarantees about.

We have other instances of this (e.g. the Objects/typeslots.inc file is 
generated and checked in), but in the case of importlib, we have to use the
./python binary for freezing to avoid bytecode incompatibilities, which
obviously is a problem if ./python isn't built yet.

> And the only outstanding point of contention in all of this is that some people
> don't like having freeze_importlib.py in Python/ and instead want it in Tools/.
> I didn't leave it in Tools/ as I have always viewed that Python should build w/o
> the Tools directory, but maybe the Linux distros actually ship with it and thus
> this is an unneeded worry. Plus the scripts to generate the AST are in Parser so
> there is precedent for what I have done.

I would have no objections to Python/.  There is also e.g. Objects/typeslots.py.

Georg