More updates

Author: JelleZijlstra

peps/pep-0749.rst

@@ -36,7 +36,8 @@ specification:
 * The ``SOURCE`` format is renamed to ``STRING`` to improve clarity and reduce the risk of
   user confusion.
 * Conditionally defined class and module annotations are handled correctly.
-* Accessing annotations on a partially executed module will raise :py:exc:`RuntimeError`.
+* If annotations are accessed a partially executed module, the annotations executed so far
+  are returned, but not cached.
 
 Motivation
 ==========
@@ -793,8 +794,8 @@ circumstances:
 * Module and class bodies are only executed once.
 * The annotations of a class are not externally visible until execution of the
   class body is complete. For modules, this is not quite true, because a partially
-  executed module can be visible to other imported modules, but this is an
-  unusual case that is problematic for other reasons (see the next section).
+  executed module can be visible to other imported modules, but this case is
+  problematic for other reasons (see the next section).
 
 This allows the following implementation strategy:
 
@@ -842,7 +843,7 @@ Consider this example:
    from . import a
    print("in b:", a.__annotations__)
 
-Note that while ``.py`` executes, the ``recmod.a`` module is defined,
+Note that while ``recmod/b.py`` executes, the ``recmod.a`` module is defined,
 but has not yet finished execution.
 
 On 3.13, this produces:
@@ -866,14 +867,12 @@ Specification
 -------------
 
 Accessing ``__annotations__`` on a partially executed module will
-raise :py:exc:`RuntimeError`. After module execution is complete,
-accessing ``__annotations__`` will execute and cache the annotations as
-normal.
-
-This is technically a compatibility break for code that introspects
-annotations on partially executed modules, but that should be a rare
-case. It is better to couple this compatibility break with the other
-changes in annotations behavior introduced by this PEP and :pep:`649`.
+continue to return the annotations that have been executed so far,
+similar to the behavior in earlier versions in Python. However, in this
+case the ``__annotations__`` dictionary will not be cached, so later
+accesses to the ``__annotations__`` attribute will return a fresh dictionary.
+This is necessary because ``__annotate__`` must be called again in order to
+incorporate additional annotations.
 
 
 Miscellaneous implementation details
@@ -964,16 +963,28 @@ to be supported by third-party libraries. Nevertheless, it is a serious issue fo
 that perform introspection, and it is important that we make it as easy as possible for
 libraries to support the new semantics in a straightforward, user-friendly way.
 
-We will update those parts of the standard library that are affected by this problem,
-and we propose to add commonly useful functionality to the new ``annotationlib`` module,
-so third-party tools can use the same set of tools.
+Several pieces of functionality in the standard library are affected by this issue,
+including :mod:`dataclasses`, :class:`typing.TypedDict` and :class:`typing.NamedTuple`.
+These have been updated to support this pattern using the functionality in the new
+``annotationlib`` module.
 
 
 Security Implications
 =====================
 
-None.
-
+One consequence of :pep:`649` is that accessing annotations on an object, even if
+the object is a function or a module, may now execute arbitrary code. This is true
+even if the STRING format is used, because the stringifier mechanism only overrides
+the global namespace, and that is not enough to sandbox Python code completely.
+
+In previous Python versions, accessing the annotations of functions or modules
+could not execute arbitrary code, but classes and other objects could already
+execute arbitrary code on access of the ``__annotations__`` attribute.
+Similarly, almost any further introspection on the annotations (e.g.,
+using ``isinstance()``, calling functions like ``typing.get_origin``, or even
+displaying the annotations with ``repr()``) could already execute arbitrary code.
+And of course, accessing annotations from untrusted code implies that the untrusted
+code has already been imported.
 
 How to Teach This
 =================