[Python-Dev] Python initialization and embedded Python (original) (raw)

Serhiy Storchaka storchaka at gmail.com
Sat Nov 18 02:15:37 EST 2017

18.11.17 02:01, Victor Stinner пише:

Many global variables used by the "Python runtime" were move to a new single "PyRuntime" variable (big structure made of sub-structures). See Include/internal/pystate.h.

A side effect of moving variables from random files into header files is that it's not more possible to fully initialize PyRuntime at "compilation time". For example, previously, it was possible to refer to local C function (functions declared with "static", so only visible in the current file). Now a new "initialization function" is required to must be called. In short, it means that using the "Python runtime" before it's initialized by PyRuntimeInitialize() is now likely to crash. For example, calling PyMemRawMalloc(), before calling PyRuntimeInitialize(), now calls the function NULL: dereference a NULL pointer, and so immediately crash with a segmentation fault.

Wouldn't be better to revert (the part of) global variables moving? I still don't see a benefit of it.

To give a more concrete example: PyDecodeLocale() is the recommanded function to decode bytes from the operating system, but this function calls PyMemRawMalloc() which does crash before PyRuntimeInitialize() is called. Is PyDecodeLocale() used to initialize Python?

For example, "void PySetProgramName(wchart *);" expects a text string, whereas main() gives argv as bytes. Calling PySetProgramName() from argv requires to decode bytes... So use PyDecodeLocale()... Should we do something in PyDecodeLocale()? Maybe crash if PyRuntimeInitialize() wasn't called yet?

I think Py_DecodeLocale() should be usable before calling Py_Initialize(). In the example in Doc/extending/extending.rst it is used before Py_Initialize(). If the third-party code is based on this example, it will crash now.

More information about the Python-Dev mailing list