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/5e0d1bba5d6dab7b2121a... 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@gmail.com | Brisbane, Australia