PEP 558: Make it clear tracing mode is being eliminated (#1783)

The initial version of the PEP entrenched the tracing mode distinction,
and was worded accordingly.

Now that tracing mode is only relevant as a historical artifact that is
being eliminated, the wording should make that clear.

Also removes a stale mention of Python 3.9.
This commit is contained in:
Nick Coghlan 2021-01-27 23:59:56 +10:00 committed by GitHub
parent f096682452
commit 54a71cd7c3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 25 deletions

View File

@ -74,27 +74,25 @@ execution scope. For this purpose, the defined scopes of execution are:
or any other construct that creates an optimized code block in CPython (e.g.
comprehensions, lambda functions)
We also allow interpreters to define two "modes" of execution, with only the
first mode being considered part of the language specification itself:
This PEP proposes elevating most of the current behaviour of the CPython
reference implementation to become part of the language specification, *except*
that each call to ``locals()`` at function scope will create a new dictionary
object, rather than caching a common dict instance in the frame object that
each invocation will update and return.
* regular operation: the way the interpreter behaves by default
* tracing mode: the way the interpreter behaves when a trace hook has been
registered in one or more threads via an implementation dependent mechanism
like ``sys.settrace`` ([4]_) in CPython's ``sys`` module or
``PyEval_SetTrace`` ([5]_) in CPython's C API
This PEP also proposes to largely eliminate the concept of a separate "tracing"
mode from the CPython reference implementation. In releases up to and including
Python 3.9, the CPython interpreter behaves differently when a trace hook has
been registered in one or more threads via an implementation dependent mechanism
like ``sys.settrace`` ([4]_) in CPython's ``sys`` module or
``PyEval_SetTrace`` ([5]_) in CPython's C API.
For regular operation, this PEP proposes elevating most of the current behaviour
of the CPython reference implementation to become part of the language
specification, *except* that each call to ``locals()`` at function scope will
create a new dictionary object, rather than caching a common dict instance in
the frame object that each invocation will update and return.
This PEP proposes changes to CPython's behaviour at function scope that make
the ``locals()`` builtin semantics when a trace hook is registered identical to
those used when no trace hook is registered, while also making the related frame
API semantics clearer and easier for interactive debuggers to rely on.
For tracing mode, this PEP proposes changes to CPython's behaviour at function
scope that make the ``locals()`` builtin semantics identical to those used in
regular operation, while also making the related frame API semantics clearer
and easier for interactive debuggers to rely on.
The proposed tracing mode changes also affect the semantics of frame object
The proposed elimination of tracing mode affects the semantics of frame object
references obtained through other means, such as via a traceback, or via the
``sys._getframe()`` API.
@ -135,7 +133,7 @@ builtin to read as follows:
dictionaries.
There would also be a versionchanged note for Python 3.9:
There would also be a versionchanged note for the release making this change:
In prior versions, the semantics of mutating the mapping object returned
from ``locals()`` were formally undefined. In CPython specifically,
@ -177,9 +175,6 @@ dynamically change the contents of the returned mapping, and changes to the
returned mapping must change the values bound to local variable names in the
execution environment.
The semantics at module scope are required to be the same in both tracing
mode (if provided by the implementation) and in regular operation.
To capture this expectation as part of the language specification, the following
paragraph will be added to the documentation for ``locals()``:
@ -214,9 +209,6 @@ class machinery).
For nested classes defined inside a function, any nonlocal cells referenced from
the class scope are *not* included in the ``locals()`` mapping.
The semantics at class scope are required to be the same in both tracing
mode (if provided by the implementation) and in regular operation.
To capture this expectation as part of the language specification, the following
two paragraphs will be added to the documentation for ``locals()``: