PEP 432: Fix footnotes and syntax highlighting (#2716)

This commit is contained in:
Hugo van Kemenade 2022-07-21 00:55:12 +03:00 committed by GitHub
parent 99c0bda3df
commit dae379c91c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 18 additions and 13 deletions

View File

@ -13,6 +13,7 @@ Requires: 587
Created: 28-Dec-2012
Post-History: 28-Dec-2012, 02-Jan-2013, 30-Mar-2019, 28-Jun-2020
.. highlight:: c
PEP Withdrawal
==============
@ -151,10 +152,10 @@ Background
Over time, CPython's initialization sequence has become progressively more
complicated, offering more options, as well as performing more complex tasks
(such as configuring the Unicode settings for OS interfaces in Python 3 [10_],
(such as configuring the Unicode settings for OS interfaces in Python 3 [10]_,
bootstrapping a pure Python implementation of the import system, and
implementing an isolated mode more suitable for system applications that run
with elevated privileges [6_]).
with elevated privileges [6]_).
Much of this complexity is formally accessible only through the ``Py_Main``
and ``Py_Initialize`` APIs, offering embedding applications little
@ -166,9 +167,9 @@ API cannot be used safely.
A number of proposals are on the table for even *more* sophisticated
startup behaviour, such as better control over ``sys.path``
initialization (e.g. easily adding additional directories on the command line
in a cross-platform fashion [7_], controlling the configuration of
``sys.path[0]`` [8_]), easier configuration of utilities like coverage
tracing when launching Python subprocesses [9_]).
in a cross-platform fashion [7]_, controlling the configuration of
``sys.path[0]`` [8]_), easier configuration of utilities like coverage
tracing when launching Python subprocesses [9]_).
Rather than continuing to bolt such behaviour onto an already complicated
system indefinitely, this PEP proposes to start simplifying the status quo by
@ -195,7 +196,7 @@ The CPython startup sequence as of Python 3.6 was difficult to understand, and
even more difficult to modify. It was not clear what state the interpreter was
in while much of the initialization code executed, leading to behaviour such
as lists, dictionaries and Unicode values being created prior to the call
to ``Py_Initialize`` when the ``-X`` or ``-W`` options are used [1_].
to ``Py_Initialize`` when the ``-X`` or ``-W`` options are used [1]_.
By moving to an explicitly multi-phase startup sequence, developers should
only need to understand:
@ -238,11 +239,15 @@ should minimise their impact on the startup overhead.
Experience with the importlib migration suggests that the startup time is
dominated by IO operations. However, to monitor the impact of any changes,
a simple benchmark can be used to check how long it takes to start and then
tear down the interpreter::
tear down the interpreter:
.. code-block:: bash
python3 -m timeit -s "from subprocess import call" "call(['./python', '-Sc', 'pass'])"
Current numbers on my system for Python 3.7 (as built by the Fedora project)::
Current numbers on my system for Python 3.7 (as built by the Fedora project):
.. code-block:: shell
$ python3 -m timeit -s "from subprocess import call" "call(['python3', '-Sc', 'pass'])"
50 loops, best of 5: 6.48 msec per loop
@ -269,7 +274,7 @@ Implementation Strategy
=======================
An initial attempt was made at implementing an earlier version of this PEP for
Python 3.4 [2_], with one of the significant problems encountered being merge
Python 3.4 [2]_, with one of the significant problems encountered being merge
conflicts after the initial structural changes were put in place to start the
refactoring process. Unlike some other previous major changes, such as the
switch to an AST-based compiler in Python 2.5, or the switch to the importlib
@ -1069,7 +1074,7 @@ aspects are the fact that user site directories are enabled,
environment variables are trusted and that the directory containing the
executed file is placed at the beginning of the import path.
Issue 16499 [6_] added a ``-I`` option to change the behaviour of
Issue 16499 [6]_ added a ``-I`` option to change the behaviour of
the normal CPython executable, but this is a hard to discover solution (and
adds yet another option to an already complex CLI). This PEP proposes to
instead add a separate ``system-python`` executable
@ -1173,7 +1178,7 @@ Locating Python and the standard library
The location of the Python binary and the standard library is influenced
by several elements. The algorithm used to perform the calculation is
not documented anywhere other than in the source code [3_,4_]. Even that
not documented anywhere other than in the source code [3]_, [4]_. Even that
description is incomplete, as it failed to be updated for the virtual
environment support added in Python 3.3 (detailed in :pep:`405`).
@ -1213,7 +1218,7 @@ the ``PYTHONPATH`` environment variable.
The ``site`` module, which is implicitly imported at startup (unless
disabled via the ``-S`` option) adds additional paths to this initial
set of paths, as described in its documentation [5_].
set of paths, as described in its documentation [5]_.
The ``-s`` command line option can be used to exclude the user site
directory from the list of directories added. Embedding applications
@ -1372,7 +1377,7 @@ connection by the operating system.
TBD: Document how the "-x" option is handled (skips processing of the
first comment line in the main script)
Also see detailed sequence of operations notes at [1_]
Also see detailed sequence of operations notes at [1]_.
References