[Python-ideas] PEP 432 modular bootstrap status update

[Nick Coghlan]

I took some time today to resync my PEP 432 modular bootstrap branch
with the current default branch of CPython.

While it's still very much a work in progress (with outright test
failures for at least isolated mode and subinterpreter support at the
moment), https://bitbucket.org/ncoghlan/cpython_sandbox/commits/5e0d1bba5d6dab7b2121a0c0e8df47ce8df74126
represents a significant milestone, as for the first time I was able
to replace the current call in Py_Main that initialises the hash
randomisation with the new Py_BeginInitialization API and still build
an interpreter that at least basically works.

The full details of what that branch is about are in
https://www.python.org/dev/peps/pep-0432/, but the general idea is to
split the interpreter bootstrapping sequence up into two distinct
phases:

* Initializing: the eval loop works, builtin data types work, frozen
and builtin imports work, the compiler works, but most operating
system interfaces (including external module imports) don't work
* Initialized: fully configured interpreter

My main goal here is actually to make the startup code easier to hack
on, by having more of it take place with the interpreter in a
well-defined state, rather than having a lot of APIs that may or may
not work depending on exactly where we are in the bootstrapping
process.

The main potential benefit for end users these changes should make it
easier to embed the CPython runtime in other applications (including
command line applications), and *skip the initialisation steps you
don't need*.

A secondary potential benefit is this should make it easier to have
subinterpreters that are *configured differently* from the main
interpreter (so, for example, you could have a subinterpreter that had
no import system configured), which opens the door to various
improvements in the way subinterpreters work in general.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia