incorporate feedback

Author: ImogenBits

peps/pep-0849.rst

@@ -16,9 +16,15 @@ Post-History: `05-Nov-2025 <https://discuss.python.org/t/idea-simpler-and-more-e
 Abstract
 ********
 
-Currently, only a small subset of Python expressions can be used in type
-annotations, which greatly limits the expressiveness of the Python type system
-and its ease of use. This PEP proposes to expand annotate functions such that
+Currently, the Python interpreter allows any expression to be used as an
+annotation. But their most popular usage, type anntotations, are restricted to
+only a small subset of possible expressions. This is because type annotations
+need to be introspectable at runtime and many valid expressions produce
+values where that is not possible. This greatly limits which expressions can
+be assigned a meaning within the typing spec and limits the expressiveness and
+ease of use of type annotations.
+
+This PEP proposes to expand annotate functions such that
 any Python expression can be used in type annotations. It does this by creating
 a new annotation format which instructs annotate functions to return the
 annotation's AST and namespaces. Runtime consumers of type annotations can then
@@ -56,9 +62,9 @@ as ``Literal[1, 2, 3]``. Many users intuitively want to instead spell this as
 them, which also is what other languages such as TypeScript use. This is
 currently not possible in Python because the expression ``1 | 2 | 3`` evaluates
 simply to ``3`` because ``|`` is interpreted as the binary-or operation rather than
-the union of types. Further, constant folding completely eliminates this
+the union of types. Further, constant folding eliminates this
 expression from appearing anywhere in the generated bytecode, and it thus is
-completely impossible to retrieve the actual type annotation at runtime.
+impossible to retrieve the actual type annotation at runtime.
 
 The above example only prevents us from using slightly shorter spelling for
 already existing types. There also are many type annotations that either
@@ -192,7 +198,7 @@ Performance Impact
 ==================
 
 While every new feature has to be weighed against its impact on performance and
-complexity, typing related features deserve additional scrutiy because type
+complexity, typing related features deserve additional scrutiny because type
 annotations are an entirely optional part of the Python language. We thus need
 to consider three separate groups of users and its impact on them: users who
 do not use type annotations at all, users who annotate their code for type
@@ -210,7 +216,19 @@ Using our reference implementation, we have found no significant difference in
 import times of modules that do not use type annotations. For modules that do
 use annotations, import was moderately faster and the memory footprint slightly
 smaller using the proposed annotate functions, both by a few percent. But
-unfortunately, evaluation time increases by a lot, about seven times as long.
+unfortunately, evaluation time can increase significantly. In the worst case,
+when annotations are requested in the value format and every used named is
+defined, the increase is about sevenfold. However, when some names are not
+defined and the string or forwardref formats have to be used the current
+approach also is significantly slower and results in comparable times to the
+proposed annotate functions.
+
+A common situation where type annotations are evaluated is when tools like
+:py:mod:`dataclasses` or similar ORM packages analyze class or function
+definitions to synthesize additional behaviour. For these tools, the time to
+e.g. create a dataclass will be impacted by this proposal. But as mentioned
+above, there already are many situations where inspecting annotations takes
+a similar amount of time.
 
 In total, since the negative performance impacts only affect the smallest group
 of users, who also benefit from the newly possible type annotations, we consider
@@ -230,22 +248,21 @@ example in ``cast(<some complex expression>, value)``. Since the interpreter
 cannot differentiate these cases from other function calls, it is impossible
 for it to infer that it should use a mechanism like we suggest.
 
-We think that directly supporting these use cases is not needed. This would
-require new syntax, which we do not think is merited for this functionality.
-Instead, this problem can be avoided using an intermediate type alias.
-That is, one would write:
+This problem can be avoided using an intermediate type alias:
 
 .. code-block:: python
 
     type _TargetType = <some complex expression>
     cast(_TargetType, value)
 
 This lets you use any new type expression within ``<some complex expression>``
-since type aliases also are implemented using annotate functions. While this
-workaround is somewhat annoying, the fact that it is needed relatively
-infrequently makes us believe that it is the better solution at this moment.
-We recommend that this usage of intermediate type aliases is observed in the
-future and new syntax to avoid it considered should it be necessary.
+since type aliases also are implemented using annotate functions.
+
+While this solution only presents a workaround to this problem, a more
+comprehensive fix would require adding a new keyword to the Python language,
+which we do not think is necessary. This decision can be reconsidered in the
+future if using intermediate type aliases like this does present a significant
+problem in real-world code.
 
 
 *************