A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://peps.python.org/pep-0587/ below:

PEP 587 – Python Initialization Configuration

PEP 587 – Python Initialization Configuration
Author:
Victor Stinner <vstinner at python.org>, Alyssa Coghlan <ncoghlan at gmail.com>
BDFL-Delegate:
Thomas Wouters <thomas at python.org>
Discussions-To:
Python-Dev list
Status:
Final
Type:
Standards Track
Created:
27-Mar-2019
Python-Version:
3.8
Table of Contents Abstract

Add a new C API to configure the Python Initialization providing finer control on the whole configuration and better error reporting.

It becomes possible to read the configuration and then override some computed parameters before it is applied. It also becomes possible to completely override how Python computes the module search paths (sys.path).

The new Isolated Configuration provides sane default values to isolate Python from the system. For example, to embed Python into an application. Using the environment are now opt-in options, rather than an opt-out options. For example, environment variables, command line arguments and global configuration variables are ignored by default.

Building a customized Python which behaves as the regular Python becomes easier using the new Py_RunMain() function. Moreover, using the Python Configuration, PyConfig.argv arguments are now parsed the same way the regular Python parses command line arguments, and PyConfig.xoptions are handled as -X opt command line options.

This extracts a subset of the API design from the PEP 432 development and refactoring work that is now considered sufficiently stable to make public (allowing 3rd party embedding applications access to the same configuration APIs that the native CPython CLI is now using).

Rationale

Python is highly configurable but its configuration evolved organically. The initialization configuration is scattered all around the code using different ways to set them: global configuration variables (ex: Py_IsolatedFlag), environment variables (ex: PYTHONPATH), command line arguments (ex: -b), configuration files (ex: pyvenv.cfg), function calls (ex: Py_SetProgramName()). A straightforward and reliable way to configure Python is needed.

Some configuration parameters are not accessible from the C API, or not easily. For example, there is no API to override the default values of sys.executable.

Some options like PYTHONPATH can only be set using an environment variable which has a side effect on Python child processes if not unset properly.

Some options also depends on other options: see Priority and Rules. Python 3.7 API does not provide a consistent view of the overall configuration.

The C API of Python 3.7 Initialization takes wchar_t* strings as input whereas the Python filesystem encoding is set during the initialization which can lead to mojibake.

Python 3.7 APIs like Py_Initialize() aborts the process on memory allocation failure which is not convenient when Python is embedded. Moreover, Py_Main() could exit directly the process rather than returning an exit code. Proposed new API reports the error or exit code to the caller which can decide how to handle it.

Implementing the PEP 540 (UTF-8 Mode) and the new -X dev correctly was almost impossible in Python 3.6. The code base has been deeply reworked in Python 3.7 and then in Python 3.8 to read the configuration into a structure with no side effect. It becomes possible to clear the configuration (release memory) and read again the configuration if the encoding changed . It is required to implement properly the UTF-8 which changes the encoding using -X utf8 command line option. Internally, bytes argv strings are decoded from the filesystem encoding. The -X dev changes the memory allocator (behaves as PYTHONMALLOC=debug), whereas it was not possible to change the memory allocation while parsing the command line arguments. The new design of the internal implementation not only allowed to implement properly -X utf8 and -X dev, it also allows to change the Python behavior way more easily, especially for corner cases like that, and ensure that the configuration remains consistent: see Priority and Rules.

This PEP is a partial implementation of PEP 432 which is the overall design. New fields can be added later to PyConfig structure to finish the implementation of the PEP 432 (e.g. by adding a new partial initialization API which allows to configure Python using Python objects to finish the full initialization). However, those features are omitted from this PEP as even the native CPython CLI doesn’t work that way - the public API proposal in this PEP is limited to features which have already been implemented and adopted as private APIs for us in the native CPython CLI.

Python Initialization C API

This PEP proposes to add the following new structures and functions.

New structures:

New functions:

This PEP also adds _PyRuntimeState.preconfig (PyPreConfig type) and PyInterpreterState.config (PyConfig type) fields to these internal structures. PyInterpreterState.config becomes the new reference configuration, replacing global configuration variables and other private variables.

PyWideStringList

PyWideStringList is a list of wchar_t* strings.

PyWideStringList structure fields:

Methods:

If length is non-zero, items must be non-NULL and all strings must be non-NULL.

PyStatus

PyStatus is a structure to store the status of an initialization function: success, error or exit. For an error, it can store the C function name which created the error.

Example:

PyStatus alloc(void **ptr, size_t size)
{
    *ptr = PyMem_RawMalloc(size);
    if (*ptr == NULL) {
        return PyStatus_NoMemory();
    }
    return PyStatus_Ok();
}

int main(int argc, char **argv)
{
    void *ptr;
    PyStatus status = alloc(&ptr, 16);
    if (PyStatus_Exception(status)) {
        Py_ExitStatusException(status);
    }
    PyMem_Free(ptr);
    return 0;
}

PyStatus fields:

Functions to create a status:

Functions to handle a status:

Note

Internally, Python uses macros which set PyStatus.func, whereas functions to create a status set func to NULL.

Preinitialization with PyPreConfig

The PyPreConfig structure is used to preinitialize Python:

Example using the preinitialization to enable the UTF-8 Mode:

PyStatus status;
PyPreConfig preconfig;

PyPreConfig_InitPythonConfig(&preconfig);

preconfig.utf8_mode = 1;

status = Py_PreInitialize(&preconfig);
if (PyStatus_Exception(status)) {
    Py_ExitStatusException(status);
}

/* at this point, Python will speak UTF-8 */

Py_Initialize();
/* ... use Python API here ... */
Py_Finalize();

Function to initialize a preconfiguration:

Functions to preinitialize Python:

The caller is responsible to handle exceptions (error or exit) using PyStatus_Exception() and Py_ExitStatusException().

For Python Configuration (PyPreConfig_InitPythonConfig()), if Python is initialized with command line arguments, the command line arguments must also be passed to preinitialize Python, since they have an effect on the pre-configuration like encodings. For example, the -X utf8 command line option enables the UTF-8 Mode.

PyPreConfig fields:

The legacy_windows_fs_encoding field is only available on Windows. #ifdef MS_WINDOWS macro can be used for Windows specific code.

PyPreConfig private fields, for internal use only:

PyMem_SetAllocator() can be called after Py_PreInitialize() and before Py_InitializeFromConfig() to install a custom memory allocator. It can be called before Py_PreInitialize() if allocator is set to PYMEM_ALLOCATOR_NOT_SET (default value).

Python memory allocation functions like PyMem_RawMalloc() must not be used before Python preinitialization, whereas calling directly malloc() and free() is always safe. Py_DecodeLocale() must not be called before the preinitialization.

Initialization with PyConfig

The PyConfig structure contains most parameters to configure Python.

Example setting the program name:

void init_python(void)
{
    PyStatus status;

    PyConfig config;
    PyConfig_InitPythonConfig(&config);

    /* Set the program name. Implicitly preinitialize Python. */
    status = PyConfig_SetString(&config, &config.program_name,
                                L"/path/to/my_program");
    if (PyStatus_Exception(status)) {
        goto fail;
    }

    status = Py_InitializeFromConfig(&config);
    if (PyStatus_Exception(status)) {
        goto fail;
    }
    PyConfig_Clear(&config);
    return;

fail:
    PyConfig_Clear(&config);
    Py_ExitStatusException(status);
}

PyConfig methods:

Most PyConfig methods preinitialize Python if needed. In that case, the Python preinitialization configuration in based on the PyConfig. If configuration fields which are in common with PyPreConfig are tuned, they must be set before calling a PyConfig method:

Moreover, if PyConfig_SetArgv() or PyConfig_SetBytesArgv() is used, this method must be called first, before other methods, since the preinitialization configuration depends on command line arguments (if parse_argv is non-zero).

Functions to initialize Python:

The caller of these methods and functions is responsible to handle exceptions (error or exit) using PyStatus_Exception() and Py_ExitStatusException().

PyConfig fields:

The legacy_windows_stdio field is only available on Windows. #ifdef MS_WINDOWS macro can be used for Windows specific code.

If parse_argv is non-zero, argv arguments are parsed the same way the regular Python parses command line arguments, and Python arguments are stripped from argv: see Command Line Arguments.

The xoptions options are parsed to set other options: see -X Options.

PyConfig private fields, for internal use only:

More complete example modifying the default configuration, read the configuration, and then override some parameters:

PyStatus init_python(const char *program_name)
{
    PyStatus status;

    PyConfig config;
    PyConfig_InitPythonConfig(&config);

    /* Set the program name before reading the configuration
       (decode byte string from the locale encoding).

       Implicitly preinitialize Python. */
    status = PyConfig_SetBytesString(&config, &config.program_name,
                                  program_name);
    if (PyStatus_Exception(status)) {
        goto done;
    }

    /* Read all configuration at once */
    status = PyConfig_Read(&config);
    if (PyStatus_Exception(status)) {
        goto done;
    }

    /* Append our custom search path to sys.path */
    status = PyWideStringList_Append(&config.module_search_paths,
                                  L"/path/to/more/modules");
    if (PyStatus_Exception(status)) {
        goto done;
    }

    /* Override executable computed by PyConfig_Read() */
    status = PyConfig_SetString(&config, &config.executable,
                                L"/path/to/my_executable");
    if (PyStatus_Exception(status)) {
        goto done;
    }

    status = Py_InitializeFromConfig(&config);

done:
    PyConfig_Clear(&config);
    return status;
}

Note

PyImport_FrozenModules, PyImport_AppendInittab() and PyImport_ExtendInittab() functions are still relevant and continue to work as previously. They should be set or called after Python preinitialization and before the Python initialization.

Isolated Configuration

PyPreConfig_InitIsolatedConfig() and PyConfig_InitIsolatedConfig() functions create a configuration to isolate Python from the system. For example, to embed Python into an application.

This configuration ignores global configuration variables, environments variables and command line arguments (argv is not parsed). The C standard streams (ex: stdout) and the LC_CTYPE locale are left unchanged by default.

Configuration files are still used with this configuration. Set the Path Configuration (“output fields”) to ignore these configuration files and avoid the function computing the default path configuration.

Python Configuration

PyPreConfig_InitPythonConfig() and PyConfig_InitPythonConfig() functions create a configuration to build a customized Python which behaves as the regular Python.

Environments variables and command line arguments are used to configure Python, whereas global configuration variables are ignored.

This function enables C locale coercion (PEP 538) and UTF-8 Mode (PEP 540) depending on the LC_CTYPE locale, PYTHONUTF8 and PYTHONCOERCECLOCALE environment variables.

Example of customized Python always running in isolated mode:

int main(int argc, char **argv)
{
    PyStatus status;

    PyConfig config;
    PyConfig_InitPythonConfig(&config);

    config.isolated = 1;

    /* Decode command line arguments.
       Implicitly preinitialize Python (in isolated mode). */
    status = PyConfig_SetBytesArgv(&config, argc, argv);
    if (PyStatus_Exception(status)) {
        goto fail;
    }

    status = Py_InitializeFromConfig(&config);
    if (PyStatus_Exception(status)) {
        goto fail;
    }
    PyConfig_Clear(&config);

    return Py_RunMain();

fail:
    PyConfig_Clear(&config);
    if (PyStatus_IsExit(status)) {
        return status.exitcode;
    }
    /* Display the error message and exit the process with
       non-zero exit code */
    Py_ExitStatusException(status);
}

This example is a basic implementation of the “System Python Executable” discussed in PEP 432.

Path Configuration

PyConfig contains multiple fields for the path configuration:

If at least one “output field” is not set, Python computes the path configuration to fill unset fields. If module_search_paths_set is equal to 0, module_search_paths is overridden and module_search_paths_set is set to 1.

It is possible to completely ignore the function computing the default path configuration by setting explicitly all path configuration output fields listed above. A string is considered as set even if it is non-empty. module_search_paths is considered as set if module_search_paths_set is set to 1. In this case, path configuration input fields are ignored as well.

Set pathconfig_warnings to 0 to suppress warnings when computing the path configuration (Unix only, Windows does not log any warning).

If base_prefix or base_exec_prefix fields are not set, they inherit their value from prefix and exec_prefix respectively.

Py_RunMain() and Py_Main() modify sys.path:

If site_import is non-zero, sys.path can be modified by the site module. If user_site_directory is non-zero and the user’s site-package directory exists, the site module appends the user’s site-package directory to sys.path.

See also Configuration Files used by the path configuration.

Py_BytesMain()

Python 3.7 provides a high-level Py_Main() function which requires to pass command line arguments as wchar_t* strings. It is non-trivial to use the correct encoding to decode bytes. Python has its own set of issues with C locale coercion and UTF-8 Mode.

This PEP adds a new Py_BytesMain() function which takes command line arguments as bytes:

int Py_BytesMain(int argc, char **argv)
Py_RunMain()

The new Py_RunMain() function executes the command (PyConfig.run_command), the script (PyConfig.run_filename) or the module (PyConfig.run_module) specified on the command line or in the configuration, and then finalizes Python. It returns an exit status that can be passed to the exit() function.

See Python Configuration for an example of customized Python always running in isolated mode using Py_RunMain().

Multi-Phase Initialization Private Provisional API

This section is a private provisional API introducing multi-phase initialization, the core feature of the PEP 432:

Private provisional API:

No module is imported during the “Core” phase and the importlib module is not configured: the Path Configuration is only applied during the “Main” phase. It may allow to customize Python in Python to override or tune the Path Configuration, maybe install a custom sys.meta_path importer or an import hook, etc.

It may become possible to compute the Path Configuration in Python, after the Core phase and before the Main phase, which is one of the PEP 432 motivation.

The “Core” phase is not properly defined: what should be and what should not be available at this phase is not specified yet. The API is marked as private and provisional: the API can be modified or even be removed anytime until a proper public API is designed.

Example running Python code between “Core” and “Main” initialization phases:

void init_python(void)
{
    PyStatus status;

    PyConfig config;
    PyConfig_InitPythonConfig(&config);

    config._init_main = 0;

    /* ... customize 'config' configuration ... */

    status = Py_InitializeFromConfig(&config);
    PyConfig_Clear(&config);
    if (PyStatus_Exception(status)) {
        Py_ExitStatusException(status);
    }

    /* Use sys.stderr because sys.stdout is only created
       by _Py_InitializeMain() */
    int res = PyRun_SimpleString(
        "import sys; "
        "print('Run Python code before _Py_InitializeMain', "
               "file=sys.stderr)");
    if (res < 0) {
        exit(1);
    }

    /* ... put more configuration code here ... */

    status = _Py_InitializeMain();
    if (PyStatus_Exception(status)) {
        Py_ExitStatusException(status);
    }
}
Backwards Compatibility

This PEP only adds a new API: it leaves the existing API unchanged and has no impact on the backwards compatibility.

The Python 3.7 Py_Initialize() function now disable the C locale coercion (PEP 538) and the UTF-8 Mode (PEP 540) by default to prevent mojibake. The new API using the Python Configuration is needed to enable them automatically.

Annexes Comparison of Python and Isolated Configurations

Differences between PyPreConfig_InitPythonConfig() and PyPreConfig_InitIsolatedConfig():

PyPreConfig Python Isolated coerce_c_locale_warn -1 0 coerce_c_locale -1 0 configure_locale 1 0 dev_mode -1 0 isolated 0 1 legacy_windows_fs_encoding -1 0 use_environment 0 0 parse_argv 1 0 utf8_mode -1 0

Differences between PyConfig_InitPythonConfig() and PyConfig_InitIsolatedConfig():

PyConfig Python Isolated configure_c_stdio 1 0 install_signal_handlers 1 0 isolated 0 1 parse_argv 1 0 pathconfig_warnings 1 0 use_environment 1 0 user_site_directory 1 0 Priority and Rules

Priority of configuration parameters, highest to lowest:

Priority of warning options, highest to lowest:

Rules on PyConfig parameters:

Rules on PyConfig and PyPreConfig parameters:

Configuration Files

Python configuration files used by the Path Configuration:

Global Configuration Variables

Global configuration variables mapped to PyPreConfig fields:

Variable Field Py_IgnoreEnvironmentFlag use_environment (NOT) Py_IsolatedFlag isolated Py_LegacyWindowsFSEncodingFlag legacy_windows_fs_encoding Py_UTF8Mode utf8_mode

(NOT) means that the PyPreConfig value is the opposite of the global configuration variable value. Py_LegacyWindowsFSEncodingFlag is only available on Windows.

Global configuration variables mapped to PyConfig fields:

Variable Field Py_BytesWarningFlag bytes_warning Py_DebugFlag parser_debug Py_DontWriteBytecodeFlag write_bytecode (NOT) Py_FileSystemDefaultEncodeErrors filesystem_errors Py_FileSystemDefaultEncoding filesystem_encoding Py_FrozenFlag pathconfig_warnings (NOT) Py_HasFileSystemDefaultEncoding filesystem_encoding Py_HashRandomizationFlag use_hash_seed, hash_seed Py_IgnoreEnvironmentFlag use_environment (NOT) Py_InspectFlag inspect Py_InteractiveFlag interactive Py_IsolatedFlag isolated Py_LegacyWindowsStdioFlag legacy_windows_stdio Py_NoSiteFlag site_import (NOT) Py_NoUserSiteDirectory user_site_directory (NOT) Py_OptimizeFlag optimization_level Py_QuietFlag quiet Py_UnbufferedStdioFlag buffered_stdio (NOT) Py_VerboseFlag verbose _Py_HasFileSystemDefaultEncodeErrors filesystem_errors

(NOT) means that the PyConfig value is the opposite of the global configuration variable value. Py_LegacyWindowsStdioFlag is only available on Windows.

Command Line Arguments

Usage:

python3 [options]
python3 [options] -c COMMAND
python3 [options] -m MODULE
python3 [options] SCRIPT

Command line options mapped to pseudo-action on PyPreConfig fields:

Option PyConfig field -E use_environment = 0 -I isolated = 1 -X dev dev_mode = 1 -X utf8 utf8_mode = 1 -X utf8=VALUE utf8_mode = VALUE

Command line options mapped to pseudo-action on PyConfig fields:

Option PyConfig field -b bytes_warning++ -B write_bytecode = 0 -c COMMAND run_command = COMMAND --check-hash-based-pycs=MODE check_hash_pycs_mode = MODE -d parser_debug++ -E use_environment = 0 -i inspect++ and interactive++ -I isolated = 1 -m MODULE run_module = MODULE -O optimization_level++ -q quiet++ -R use_hash_seed = 0 -s user_site_directory = 0 -S site_import -t ignored (kept for backwards compatibility) -u buffered_stdio = 0 -v verbose++ -W WARNING add WARNING to warnoptions -x skip_source_first_line = 1 -X OPTION add OPTION to xoptions

-h, -? and -V options are handled without PyConfig.

-X Options

-X options mapped to pseudo-action on PyConfig fields:

Option PyConfig field -X dev dev_mode = 1 -X faulthandler faulthandler = 1 -X importtime import_time = 1 -X pycache_prefix=PREFIX pycache_prefix = PREFIX -X showalloccount show_alloc_count = 1 -X showrefcount show_ref_count = 1 -X tracemalloc=N tracemalloc = N Environment Variables

Environment variables mapped to PyPreConfig fields:

Variable PyPreConfig field PYTHONCOERCECLOCALE coerce_c_locale, coerce_c_locale_warn PYTHONDEVMODE dev_mode PYTHONLEGACYWINDOWSFSENCODING legacy_windows_fs_encoding PYTHONMALLOC allocator PYTHONUTF8 utf8_mode

Environment variables mapped to PyConfig fields:

Variable PyConfig field PYTHONDEBUG parser_debug PYTHONDEVMODE dev_mode PYTHONDONTWRITEBYTECODE write_bytecode PYTHONDUMPREFS dump_refs PYTHONEXECUTABLE program_name PYTHONFAULTHANDLER faulthandler PYTHONHASHSEED use_hash_seed, hash_seed PYTHONHOME home PYTHONINSPECT inspect PYTHONIOENCODING stdio_encoding, stdio_errors PYTHONLEGACYWINDOWSSTDIO legacy_windows_stdio PYTHONMALLOCSTATS malloc_stats PYTHONNOUSERSITE user_site_directory PYTHONOPTIMIZE optimization_level PYTHONPATH pythonpath_env PYTHONPROFILEIMPORTTIME import_time PYTHONPYCACHEPREFIX, pycache_prefix PYTHONTRACEMALLOC tracemalloc PYTHONUNBUFFERED buffered_stdio PYTHONVERBOSE verbose PYTHONWARNINGS warnoptions

PYTHONLEGACYWINDOWSFSENCODING and PYTHONLEGACYWINDOWSSTDIO are specific to Windows.

Default Python Configuration

PyPreConfig_InitPythonConfig():

PyConfig_InitPythonConfig():

Default Isolated Configuration

PyPreConfig_InitIsolatedConfig():

PyConfig_InitIsolatedConfig():

Python 3.7 API

Python 3.7 has 4 functions in its C API to initialize and finalize Python:

Python 3.7 can be configured using Global Configuration Variables, Environment Variables, and the following functions:

There is also a high-level Py_Main() function and PyImport_FrozenModules variable which can be overridden.

See Initialization, Finalization, and Threads documentation.

Python Issues

Issues that will be fixed by this PEP, directly or indirectly:

Issues of the PEP implementation:

Issues related to this PEP:

Discussions Version History Acceptance

PEP 587 was accepted by Thomas Wouters on May 26, 2019.

Copyright

This document has been placed in the public domain.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4