[Python-checkins] peps: Minor tweaks to PEP 432
nick.coghlan
python-checkins at python.org
Tue Apr 14 01:26:16 CEST 2015
https://hg.python.org/peps/rev/25433ed20352
changeset: 5753:25433ed20352
user: Nick Coghlan <ncoghlan at gmail.com>
date: Mon Apr 13 19:26:10 2015 -0400
summary:
Minor tweaks to PEP 432
files:
pep-0432.txt | 96 +++++++++++++++++++--------------------
1 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/pep-0432.txt b/pep-0432.txt
--- a/pep-0432.txt
+++ b/pep-0432.txt
@@ -37,12 +37,16 @@
the main module.
In the new design, the interpreter will move through the following
-well-defined phases during the startup sequence:
+well-defined phases during the initialization sequence:
* Pre-Initialization - no interpreter available
* Initializing - interpreter partially available
* Initialized - interpreter available, __main__ related metadata
incomplete
+
+With the interpreter itself fully initialised, main module execution will
+then proceed through two phases:
+
* Main Preparation - __main__ related metadata populated
* Main Execution - bytecode executing in the __main__ module namespace
@@ -71,14 +75,15 @@
once this PEP has been implemented.
-
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 as
-well as bootstrapping a pure Python implementation of the import system).
+(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_]).
Much of this complexity is formally accessible only through the ``Py_Main``
and ``Py_Initialize`` APIs, offering embedding applications little
@@ -88,18 +93,16 @@
API cannot be used safely.
A number of proposals are on the table for even *more* sophisticated
-startup behaviour, such as an isolated mode equivalent to that described in
-this PEP as a "system Python" [6_], better control over ``sys.path``
+startup behaviour, such as better control over ``sys.path``
initialization (easily adding additional directories on the command line
in a cross-platform fashion [7_], as well as controlling the configuration of
``sys.path[0]`` [8_]), easier configuration of utilities like coverage
-tracing when launching Python subprocesses [9_], and easier control of the
-encoding used for the standard IO streams when embedding CPython in a larger
-application [10_].
+tracing when launching Python subprocesses [9_].
-Rather than attempting to bolt such behaviour onto an already complicated
-system, this PEP proposes to instead simplify the status quo *first*, with
-the aim of making these further feature requests easier to implement.
+Rather than continuing to bolt such behaviour onto an already complicated
+system, this PEP proposes to start simplifying the status quo by introducing
+a more stuctured startup sequence, with the aim of making these further
+feature requests easier to implement.
Key Concerns
@@ -142,25 +145,12 @@
python3 -m timeit -s "from subprocess import call" "call(['./python', '-c', 'pass'])"
-Current numbers on my system for 2.7, 3.2 and 3.3 (using the 3.3
+Current numbers on my system for Python 3.5 (using the 3.4
subprocess and timeit modules to execute the check, all with non-debug
builds)::
- # Python 2.7
- $ py33/python -m timeit -s "from subprocess import call" "call(['py27/python', '-c', 'pass'])"
- 100 loops, best of 3: 17.8 msec per loop
- # Python 3.2
- $ py33/python -m timeit -s "from subprocess import call" "call(['py32/python', '-c', 'pass'])"
- 10 loops, best of 3: 39 msec per loop
- # Python 3.3
- $ py33/python -m timeit -s "from subprocess import call" "call(['py33/python', '-c', 'pass'])"
- 10 loops, best of 3: 25.3 msec per loop
-
-Improvements in the import system and the Unicode support already resulted
-in a more than 30% improvement in startup time in Python 3.3 relative to
-3.2. Python 3.3 is still slightly slower to start than Python 2.7 due to the
-additional infrastructure that needs to be put in place to support the
-Unicode based text model.
+ $ python3 -m timeit -s "from subprocess import call" "call(['./python', '-c', 'pass'])"
+ 10 loops, best of 3: 18.2 msec per loop
This PEP is not expected to have any significant effect on the startup time,
as it is aimed primarily at *reordering* the existing initialization
@@ -264,7 +254,7 @@
Interpreter Initialization Phases
---------------------------------
-Five distinct phases are proposed:
+Three distinct interpreter initialisation phases are proposed:
* Pre-Initialization:
@@ -290,23 +280,29 @@
``__main__`` related metadata is incomplete
* ``Py_IsInitializing()`` returns ``0``
* ``Py_IsInitialized()`` returns ``1``
- * Optionally, the embedding application may identify and begin
- executing code in the ``__main__`` module namespace by calling
- ``PyRun_PrepareMain`` and ``PyRun_ExecMain``.
+
+
+Main Execution Phases
+---------------------
+
+After initializing the interpreter, the embedding application may continue
+on to execute code in the ``__main__`` module namespace.
* Main Preparation:
* subphase of Initialized (not separately identified at runtime)
* fully populates ``__main__`` related metadata
* may execute code in ``__main__`` namespace (e.g. ``PYTHONSTARTUP``)
+ * invoked as ``PyRun_PrepareMain``
* Main Execution:
* subphase of Initialized (not separately identified at runtime)
* user supplied bytecode is being executed in the ``__main__`` namespace
+ * invoked as ``PyRun_ExecMain``
-As noted above, main module preparation and execution are optional subphases
-of Initialized rather than completely distinct phases.
+Invocation of Phases
+--------------------
All listed phases will be used by the standard CPython interpreter and the
proposed System Python interpreter. Other embedding applications may
@@ -344,7 +340,7 @@
The pre-initialization phase is where an embedding application determines
the settings which are absolutely required before the interpreter can be
-initialized at all. Currently, the only configuration settings in this
+initialized at all. Currently, the primary configuration settings in this
category are those related to the randomised hash algorithm - the hash
algorithms must be consistent for the lifetime of the process, and so they
must be in place before the core interpreter is created.
@@ -362,7 +358,8 @@
void Py_BeginInitialization(const PyCoreConfig *config);
-Like Py_Initialize, this part of the new API treats initialization failures
+Like ``Py_Initialize``, this part of the new API treats initialization
+failures
as fatal errors. While that's still not particularly embedding friendly,
the operations in this step *really* shouldn't be failing, and changing them
to return error codes instead of aborting would be an even larger task than
@@ -374,7 +371,7 @@
/* Note: if changing anything in PyCoreConfig, also update
* PyCoreConfig_INIT */
typedef struct {
- int ignore_environment; /* -E switch */
+ int ignore_environment; /* -E switch, -I switch */
int use_hash_seed; /* PYTHONHASHSEED */
unsigned long hash_seed; /* PYTHONHASHSEED */
int _disable_importlib; /* Needed by freeze_importlib */
@@ -404,12 +401,12 @@
case, then the randomised hashing is disabled completely.
If ``use_hash_seed`` is negative (and ``ignore_environment`` is zero),
-then CPython will inspect the ``PYTHONHASHSEED`` environment variable. If it
-is not set, is set to the empty string, or to the value ``"random"``, then
-randomised hashes with a random seed will be used. If it is set to the string
-``"0"`` the randomised hashing will be disabled. Otherwise, the hash seed is
-expected to be a string representation of an integer in the range
-``[0; 4294967295]``.
+then CPython will inspect the ``PYTHONHASHSEED`` environment variable. If the
+environment variable is not set, is set to the empty string, or to the value
+``"random"``, then randomised hashes with a random seed will be used. If the
+environment variable is set to the string ``"0"`` the randomised hashing will
+be disabled. Otherwise, the hash seed is expected to be a string
+representation of an integer in the range ``[0; 4294967295]``.
To make it easier for embedding applications to use the ``PYTHONHASHSEED``
processing with a different data source, the following helper function
@@ -437,7 +434,7 @@
The aim is to keep this initial level of configuration as small as possible
in order to keep the bootstrapping environment consistent across
different embedding applications. If we can create a valid interpreter state
-without the setting, then the setting should go in the config dict passed
+without the setting, then the setting should go in the configuration passed
to ``Py_EndInitialization()`` rather than in the core configuration.
A new query API will allow code to determine if the interpreter is in the
@@ -487,8 +484,8 @@
status quo).
In addition, the current thread will possess a valid Python thread state,
-allow any further configuration data to be stored on the interpreter object
-rather than in C process globals.
+allowing any further configuration data to be stored on the interpreter
+object rather than in C process globals.
Any call to ``Py_BeginInitialization()`` must have a matching call to
``Py_Finalize()``. It is acceptable to skip calling Py_EndInitialization() in
@@ -511,7 +508,7 @@
A struct is used rather than a Python dictionary as the struct is easier
to work with from C, the list of supported fields is fixed for a given
-CPython version and only a read-only view need to be exposed to Python
+CPython version and only a read-only view needs to be exposed to Python
code (which is relatively straightforward, thanks to the infrastructure
already put in place to expose ``sys.implementation``).
@@ -521,8 +518,9 @@
Any supported configuration setting which is not already set will be
populated appropriately in the supplied configuration struct. The default
-configuration can be overridden entirely by setting the value *before* calling ``Py_ReadConfiguration``. The provided value will then also be used in
-calculating any other settings derived from that value.
+configuration can be overridden entirely by setting the value *before*
+calling ``Py_ReadConfiguration``. The provided value will then also be used
+in calculating any other settings derived from that value.
Alternatively, settings may be overridden *after* the
``Py_ReadConfiguration`` call (this can be useful if an embedding
--
Repository URL: https://hg.python.org/peps
More information about the Python-checkins
mailing list