PEP 667: add 709 impact, other tweaks (#3196)

pep-0667.rst

@@ -5,6 +5,7 @@ Status: Draft
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 30-Jul-2021
+Python-Version: 3.13
 Post-History: 20-Aug-2021
 
 
@@ -118,11 +119,16 @@ For example::
         y
         print(locals(), x)
 
-``test()`` will print ``{'x': 2, 'y': 4, 'z': 5} 2``
+``test()`` will print ``{'x': 2, 'y': 4, 'z': 5} 2``.
 
-In Python 3.10, the above will fail with a ``NameError``,
+In Python 3.10, the above will fail with an ``UnboundLocalError``,
 as the definition of ``y`` by ``l()['y'] = 4`` is lost.
 
+If the second-to-last line were changed from ``y`` to ``z``, this would be a
+``NameError``, as it is today. Keys added to ``frame.f_locals`` that are not
+lexically local variables remain visible in ``frame.f_locals``, but do not
+dynamically become local variables.
+
 C-API
 -----
 
@@ -152,7 +158,7 @@ The following C-API functions will be deprecated, as they return borrowed refere
    PyEval_GetGlobals()
    PyEval_GetBuiltins()
 
-They will be will be removed in 3.14.
+They will be removed in 3.15.
 
 The following functions should be used instead::
 
@@ -171,7 +177,7 @@ The following three functions will become no-ops, and will be deprecated::
     PyFrame_FastToLocals()
     PyFrame_LocalsToFast()
 
-They will be will be removed in 3.14.
+They will be removed in 3.15.
 
 Behavior of f_locals for optimized functions
 --------------------------------------------
@@ -225,7 +231,7 @@ should be replaced with::
 PyFrame_FastToLocals, etc.
 ''''''''''''''''''''''''''
 
-These functions were designed to convert the internal "fast" representation 
+These functions were designed to convert the internal "fast" representation
 of the locals variables of a function to a dictionary, and vice versa.
 
 Calls to them are no longer required. C code that directly accesses the
@@ -387,6 +393,21 @@ C API
 As with all functions that return a borrowed reference, care must be taken to
 ensure that the reference is not used beyond the lifetime of the object.
 
+Impact on PEP 709 inlined comprehensions
+========================================
+
+For inlined comprehensions within a function, ``locals()`` currently behaves the
+same inside or outside of the comprehension, and this will not change. The
+behavior of ``locals()`` inside functions will generally change as specified in
+the rest of this PEP.
+
+For inlined comprehensions at module or class scope, currently calling
+``locals()`` within the inlined comprehension returns a new dictionary for each
+call. This PEP will make ``locals()`` within a function also always return a new
+dictionary for each call, improving consistency; class or module scope inlined
+comprehensions will appear to behave as if the inlined comprehension is still a
+distinct function.
+
 Comparison with PEP 558
 =======================
 
@@ -414,8 +435,8 @@ An alternative way to define ``locals()`` would be simply as::
         return sys._getframe(1).f_locals
 
 This would be simpler and easier to understand. However,
-there would be backwards compatibility issues when ``locals`` is assigned
-to a local variable or when passed to ``eval`` or ``exec``.
+there would be backwards compatibility issues when ``locals()`` is assigned
+to a local variable or passed to ``eval`` or ``exec``.
 
 Lifetime of the mapping proxy
 -----------------------------