bpo-35713: Rework Python initialization#11647
Conversation
|
@scoder, @ericsnowcurrently: Do you think that it's ok to remove "PyXXX_Init()" from the C API? I don't see why anyone would call them explicitly? |
Sorry, something went wrong.
Ignore my questions. In fact, these functions are prefixed by "_Py": they are private, and we don't provide any stability warranty for the private API. |
Sorry, something went wrong.
* The PyByteArray_Init() and PyByteArray_Fini() functions have been
removed. They did nothing since Python 2.7.4 and Python 3.2.0, were
excluded from the limited API (stable ABI), and were not
documented.
* Move "_PyXXX_Init()" and "_PyXXX_Fini()" declarations from
Include/cpython/pylifecycle.h to
Include/internal/pycore_pylifecycle.h. Replace
"PyAPI_FUNC(TYPE)" with "extern TYPE".
* _PyExc_Init() now returns an error on failure rather than calling
Py_FatalError(). Move macros inside _PyExc_Init() and undefine them
when done. Rewrite macros to make them look more like statement:
add ";" when using them, add "do { ... } while (0)".
* _PyUnicode_Init() now returns a _PyInitError error rather than call
Py_FatalError().
* Move stdin check from _PySys_BeginInit() to init_sys_streams().
* _Py_ReadyTypes() now returns a _PyInitError error rather than
calling Py_FatalError().
|
I modified my PR to document properly the removal of PyByteArray_Init() and PyByteArray_Fini() functions: documented in the Porting section of What's New in Python 3.8 and in a NEWS entry. |
Sorry, something went wrong.
did nothing since Python 2.7.4 and Python 3.2.0.
Py_FatalError(). Move macros inside _PyExc_Init() and undefine them
when done. Rewrite macros to make them look more like statement:
add ";" when using them, add "do { ... } while (0)".
Py_FatalError().
calling Py_FatalError().
Include/cpython/pylifecycle.h to
Include/internal/pycore_pylifecycle.h. Replace
"PyAPI_FUNC(TYPE)" with "extern TYPE".
https://bugs.python.org/issue35713