On Sat, Dec 29, 2012 at 1:45 AM, Mark Shannon <mark@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@gmail.com | Brisbane, Australia