PEP 558: Make it clear tracing mode is being eliminated

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:
-
-* 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
-
-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.
-
-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
+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 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.
+
+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.
+
+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()``: