PEP 667: Clarify specification ambiguities and the expected impact

peps/pep-0667.rst

@@ -371,6 +371,70 @@ 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 ``exec()``
+====================
+
+Even though this PEP does not modify ``exec()`` directly, the semantic change
+to ``locals()`` impacts the behavior of ``exec()``.
+
+``exec(object)`` has been equivalent to ``exec(object, globals(), locals())``
+for a long time, but it's not officially documented. We plan to keep this
+relation, which means existing code using ``exec()`` will see some different
+behaviors.
+
+The core difference is that the current implementation returns the same dict
+when ``locals()`` is called multiple times in function scope, so the following
+code magically works::
+
+    def f():
+        exec('a = 0')  # equivalent to exec('a = 0', globals(), locals())
+        exec('print(a)')  # equivalent to exec('print(a)', globals(), locals())
+        print(locals())  # {'a': 0}
+        # However, print(a) will not work here
+    f()
+
+``locals()`` in a function currently returns the same persisted dict for every call. This allows stashing
+extra "fake locals" in that dict, which aren't real locals known by the compiler, but can still be seen in
+``locals()`` and shared between multiple ``exec()`` in the same function scope.
+
+This behavior gets harder to predict when the code in ``exec()`` tries to write
+to an existing local variable::
+
+    def f():
+        a = None
+        exec('a = 0')  # equivalent to exec('a = 0', globals(), locals())
+        exec('print(a)')  # equivalent to exec('print(a)', globals(), locals())
+        print(locals())  # {'a': None}
+    f()
+
+``print(a)`` will print ``None`` because the implicit ``locals()`` call in
+``exec()`` refreshes the cached dict with the actual values on the frame.
+So "real" locals, unlike "fake" locals created via ``exec()``, can't easily be
+modified by ``exec()``.
+
+With the semantic changes to ``locals()`` in this PEP, it's easier to explain the behavior
+of ``exec()`` - it will never affect local function scopes. Any assignment
+to the local variables will be discarded when ``exec()`` returns.
+
+However, you can still achieve a shared namespace across `exec()` calls with explicit namespaces::
+
+    def f():
+        scope = {}
+        exec('a = 0', locals=scope)
+        exec('print(a)', locals=scope)
+    f()
+
+You can even change the variables in the local scope by explicitly using
+``frame.f_locals``, which was not possible before::
+
+    def f():
+        a = None
+        exec('a = 0', locals=sys._getframe().f_locals)
+        print(a)  # 0
+    f()
+
+The behavior of ``exec()`` for module and class scopes is not changed.
+
 Impact on PEP 709 inlined comprehensions
 ========================================