PEP 741: remove Spawn process section (#3712)
This commit is contained in:
Victor Stinner
GitHub
parent
4352a4a56c
commit
a0e3011518
|
|
@ -12,16 +12,15 @@ Post-History: `19-Jan-2024 <https://discuss.python.org/t/pep-741-python-configur
|
|||
Abstract
|
||||
========
|
||||
|
||||
Add a C API to the limited C API to configure the Python initialization,
|
||||
and to get the current configuration. It can be used with the stable
|
||||
ABI.
|
||||
Add a C API to the limited C API to configure the Python initialization.
|
||||
It can be used with the stable ABI.
|
||||
|
||||
Complete :pep:`587` API by adding ``PyInitConfig_AddModule()`` which can be
|
||||
used to add a built-in extension module; feature previously referred to
|
||||
as the "inittab".
|
||||
|
||||
Add ``PyConfig_Get()`` and ``PyConfig_Set()`` functions to
|
||||
get and set the current configuration at runtime.
|
||||
get and set the current runtime configuration at runtime.
|
||||
|
||||
:pep:`587` "Python Initialization Configuration" unified all the ways to
|
||||
configure the Python **initialization**. This PEP (almost fully) unifies
|
||||
|
|
@ -100,11 +99,11 @@ application with the limited C API version 3.12 can still run with
|
|||
Python 3.13 stable ABI.
|
||||
|
||||
|
||||
Get the current configuration
|
||||
Get the runtime configuration
|
||||
-----------------------------
|
||||
|
||||
:pep:`587` has no API to **get** the **current** configuration, only to
|
||||
**configure** the Python **initialization**.
|
||||
:pep:`587` has no API to **get** the **current** runtime configuration,
|
||||
only to **configure** the Python **initialization**.
|
||||
|
||||
For example, the global configuration variable
|
||||
``Py_UnbufferedStdioFlag`` was deprecated in Python 3.12 and using
|
||||
|
|
@ -113,7 +112,7 @@ configure Python, there is no public API to get
|
|||
``PyConfig.buffered_stdio``.
|
||||
|
||||
Users of the limited C API are asking for a public API to get the
|
||||
current configuration.
|
||||
current runtime configuration.
|
||||
|
||||
Cython needs to access the ``optimization_level`` configuration option:
|
||||
`issue <https://github.com/python/cpython/issues/99872>`_.
|
||||
|
|
@ -319,47 +318,7 @@ Quotes of `Paul P. message <https://discuss.python.org/t/pep-741-python-configur
|
|||
with a **stable config runtime**, it would be just perfect way!
|
||||
|
||||
|
||||
Spawn a new Python process with the same configuration
|
||||
------------------------------------------------------
|
||||
|
||||
The Python test suite runner spawns test worker processes by creating a
|
||||
new command line with the same configuration options. For that, it calls
|
||||
the ``args_from_interpreter_flags()`` of ``test.support`` module which
|
||||
calls ``_args_from_interpreter_flags()`` of the ``subprocess`` module.
|
||||
These functions inspect ``sys.flags``, ``sys.warnoptions`` and
|
||||
``sys._xoptions``.
|
||||
|
||||
The problem is that every time a new configuration is added, it should
|
||||
be exposed to ``sys.flags``. Otherwise,
|
||||
``args_from_interpreter_flags()`` ignores the option and so the option
|
||||
is not inherited by child processes.
|
||||
|
||||
Another problem is that inspecting ``sys._xoptions`` doesn't take
|
||||
environment variables in account.
|
||||
|
||||
Python 3.10 added ``sys.orig_argv`` for a specific implementation: copy
|
||||
and then modify the original command line option to add or remove
|
||||
command line optioins. This method also has a limitation, it ignores
|
||||
environment variables.
|
||||
|
||||
Examples of ``-X`` options which are not exposed in ``sys.flags``:
|
||||
|
||||
* ``code_debug_ranges``,
|
||||
* ``cpu_count``,
|
||||
* ``import_time``,
|
||||
* ``int_max_str_digits``,
|
||||
* ``perf_profiling``,
|
||||
* ``pycache_prefix``,
|
||||
* ``run_presite`` (only on a Python debug build),
|
||||
* ``show_ref_count``.
|
||||
|
||||
Some of these options are inherited by inspecting ``sys._xoptions``
|
||||
which doesn't take in account environment variables.
|
||||
|
||||
The ``sys.get_int_max_str_digits()`` function can be used to get the
|
||||
``int_max_str_digits`` option.
|
||||
|
||||
Set the current configuration
|
||||
Set the runtime configuration
|
||||
-----------------------------
|
||||
|
||||
`Marc-André Lemburg requested
|
||||
|
|
@ -397,7 +356,7 @@ initialization:
|
|||
* ``PyInitConfig_GetWStrList(config, name, &length, &items)``.
|
||||
* ``PyInitConfig_FreeWStrList()``.
|
||||
|
||||
* Set optons:
|
||||
* Set options:
|
||||
|
||||
* ``PyInitConfig_SetInt(config, name, value)``.
|
||||
* ``PyInitConfig_SetStr(config, name, value)``.
|
||||
|
|
@ -417,7 +376,7 @@ initialization:
|
|||
|
||||
* ``PyInitConfig_GetError(config, &err_msg)``.
|
||||
|
||||
Add C API functions to get and set the current configuration:
|
||||
Add C API functions to get and set the current runtime configuration:
|
||||
|
||||
* ``PyConfig_Get(name)`` → ``object``.
|
||||
* ``PyConfig_GetInt(name, &value)``.
|
||||
|
|
@ -740,8 +699,8 @@ functions call ``Py_PreInitializeFromInitConfig()`` if Python is not
|
|||
already preinitialized.
|
||||
|
||||
|
||||
Create PyInitConfig
|
||||
-------------------
|
||||
Create Config
|
||||
-------------
|
||||
|
||||
``PyInitConfig`` structure:
|
||||
Opaque structure to configure the Python preinitialization and the
|
||||
|
|
@ -764,8 +723,8 @@ Create PyInitConfig
|
|||
``void PyInitConfig_Free(PyInitConfig *config)``:
|
||||
Free memory of an initialization configuration.
|
||||
|
||||
Get PyInitConfig Options
|
||||
------------------------
|
||||
Get Options
|
||||
-----------
|
||||
|
||||
The configuration option *name* parameter must be a non-NULL
|
||||
null-terminated UTF-8 encoded string.
|
||||
|
|
@ -827,8 +786,8 @@ null-terminated UTF-8 encoded string.
|
|||
``PyInitConfig_GetWStrList()``.
|
||||
|
||||
|
||||
Set PyInitConfig Options
|
||||
------------------------
|
||||
Set Options
|
||||
-----------
|
||||
|
||||
The configuration option *name* parameter must be a non-NULL
|
||||
null-terminated UTF-8 encoded string.
|
||||
|
|
@ -928,7 +887,7 @@ Initialize Python
|
|||
* Set an error in *config* and return ``-1`` on error.
|
||||
|
||||
|
||||
Error handling
|
||||
Error Handling
|
||||
--------------
|
||||
|
||||
``int PyInitConfig_GetError(PyInitConfig* config, const char **err_msg)``:
|
||||
|
|
@ -944,14 +903,15 @@ Error handling
|
|||
error message.
|
||||
|
||||
|
||||
Get and set the current configuration
|
||||
Get and Set the Runtime Configuration
|
||||
-------------------------------------
|
||||
|
||||
The configuration option *name* parameter must be a non-NULL
|
||||
null-terminated UTF-8 encoded string.
|
||||
|
||||
``PyObject* PyConfig_Get(const char *name)``:
|
||||
Get the current value of a configuration option as an object.
|
||||
Get the current runtime value of a configuration option as an
|
||||
object.
|
||||
|
||||
* Return a new reference on success.
|
||||
* Set an exception and return ``NULL`` on error.
|
||||
|
|
@ -978,12 +938,12 @@ null-terminated UTF-8 encoded string.
|
|||
The caller must hold the GIL.
|
||||
|
||||
``PyObject* PyConfig_Set(const char *name, PyObject *value)``:
|
||||
Set the value of a configuration option.
|
||||
Set the current runtime value of a configuration option.
|
||||
|
||||
* Raise a ``ValueError`` if there is no option *name*.
|
||||
* Raise a ``TypeError`` if *value* has not the proper type.
|
||||
* Raise a ``ValueError`` if *value* is an invalid value.
|
||||
* Raise a ``ValueError`` if the option is read-only: cannot be set.
|
||||
* Raise a ``TypeError`` if *value* has not the proper type.
|
||||
|
||||
`Read-only configuration options`_ cannot be set.
|
||||
|
||||
|
|
@ -1088,10 +1048,10 @@ configuration:
|
|||
}
|
||||
|
||||
|
||||
Get the current verbose option
|
||||
Get the runtime verbose option
|
||||
------------------------------
|
||||
|
||||
Example getting the current value of the configuration option
|
||||
Example getting the current runtime value of the configuration option
|
||||
``verbose``:
|
||||
|
||||
.. code-block:: c
|
||||
|
|
@ -1271,9 +1231,6 @@ them simpler (the opposite). Having multiple structures for similar
|
|||
purpose can lead to duplicate members, similar issue than duplicated
|
||||
members between existing ``PyPreConfig`` and ``PyConfig`` structures.
|
||||
|
||||
.. XXX Are the concerns still valid about the config currently not
|
||||
being complete before ``Py_InitializeFromConfig()`` is called?
|
||||
|
||||
|
||||
Discussions
|
||||
===========
|
||||
|
|
|
|||
Loading…
Reference in New Issue