iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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