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:
parent
f096682452
commit
54a71cd7c3
42
pep-0558.rst
42
pep-0558.rst
|
@ -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()``:
|
||||
|
||||
|
|
Loading…
Reference in New Issue