[Python-ideas] PEP 432: Simplifying the CPython startup sequence

[Nick Coghlan]

On Sat, Dec 29, 2012 at 1:45 AM, Mark Shannon <mark at hotpy.org> wrote:
> On 27/12/12 15:10, Nick Coghlan wrote:
>
> Hi,
>
>
>> This PEP proposes that CPython move to an explicit 2-phase initialisation
>
>
> Why only two phases? I was thinking about the initialisation sequence a
> while ago and thought that a three or four phase sequence might be
> appropriate. What matters is that the state in between phases is well
> defined and simple to understand.

The "2-phase" term came from the fact that I'm trying to break
Py_Initialize() into two separate phase changes that roughly
correspond with the locations of the current calls to
_Py_Random_Init() and Py_Initialize() in Py_Main().

There's also at least a 3rd phase (even in the current design),
because there's a "get ready to start executing __main__" phase after
Py_Initialise finishes that changes various attributes on __main__ and
may also modify sys.path[0] and sys.argv[0]. This is the first phase
where user code may execute (Package __init__ modules may run in this
phase when the "-m" switch is used to execute a package or submodule)

So yeah, I need to lose the "2-phase" term, because it's simply wrong.
A more realistic description of the phases proposed in the PEP would
be:

PreInit Phase - No CPython infrastructure configured, only pure C code allowed
Initializing Phase - After Py_BeginInitialization() is called.
Limitations as described in the PEP.
PreMain Phase - After Py_EndInitialization() is called. __main__
attributes, sys.path[0], sys.argv[0] may still be inaccurate
Main Execution - Execution of the main module bytecode has started.
Interpreter has been fully configured.

> You might want to take a look at rubinius which implements most of its core
> components in Ruby, so needs a clearly defined startup sequence.
> http://rubini.us/doc/en/bootstrapping/
> (Rubinius using 7 phases, but that would be overkill for CPython)

Thanks for the reference. However, it looks like most of those seven
stages will still be handled in our preinit phase. It sounds like we
do a *lot* more in C than Rubinius does, so most of that code really
doesn't need much in the way of infrastructure. It's definitely not
*easy* to understand, but we also don't mess with it very often, and
it's the kind of code where having access to more of the Python C API
wouldn't really help all that much.

The key piece I think we're currently missing is the clearly phase
change between "PreInit" (can't safely use the Python C API) and
"Initializing" (can use most of the C API, with some restrictions).

Cheers,
Nick.

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