This issue appears specifically for TypedDicts because the TypedDict constructor
code converts string annotations to ForwardRef objects, and those are not evaluated
properly by the get_type_hints() stack because of other shenanigans with type
parameters.
This issue does not affect normal generic classes because their annotations are not
pre-converted to ForwardRefs.
The fix attempts to restore the pre- #137227 behavior in the narrow scenario where
the issue manifests. It mostly makes changes only in the paths accessible from get_type_hints(),
ensuring that newer APIs (such as evaluate_forward_ref() and annotationlib) are not affected
by get_type_hints()'s past odd choices. This PR does not fix issue #138949, an older issue I
discovered while playing around with this one; we'll need a separate and perhaps more
invasive fix for that, but it should wait until after 3.14.0.
The previous behavior was copied from earlier typing code. It works around the way
typing.get_type_hints passes its namespaces, but I don't think the behavior is logical
or correct.
As explained in #133960, this removes most of the behavior differences with ForwardRef.evaluate.
The remaining difference is about recursive evaluation of forwardrefs; this is practically useful
in cases where an annotation refers to a type alias that itself is string-valued.
This also improves several edge cases that were previously not handled optimally. For example,
the function now takes advantage of the partial evaluation behavior of ForwardRef.evaluate() to
evaluate more ForwardRefs in the FORWARDREF format.
This also fixes#133959 as a side effect, because the buggy behavior in #133959 derives from
evaluate_forward_ref().
Remove unnecessary strings, use of Union[], use of List[], and reliance
on implicit Optional.
These type annotations are not actually used for anything but I feel
we should set a good example.
As noted on the issue, making get_annotate_function() support both types and
mappings is problematic because one object may be both. So let's add a new one
that works with any mapping.
This leaves get_annotate_function() not very useful, so remove it.
annotationlib is used quite a few times in typing.py, but I think the
usages are just rare enough that this makes sense.
The import would get triggered by:
- Using get_type_hints(), evaluate_forward_ref(), and similar introspection
functions
- Using a string annotation anywhere that goes through _type_convert (e.g.,
"Final['x']" will trigger an annotationlib import in order to access the
ForwardRef class).
- Creating a TypedDict or NamedTuple (unless it's empty or PEP 563 is on).
Lots of programs will want to use typing without any of these, so the tradeoff
seems worth it.
It doesn't make sense to use a deprecation for evaluate_forward_ref,
as it is a new function in Python 3.14 and doesn't have compatibility
guarantees.
I considered making it throw an error if type_params it not passed and
there is no owner. However, I think this is too unfriendly for users. The
case where this param is really needed is fairly esoteric and I don't think
this case is worth the pain of forcing users to write "type_params=()".
Unfortunately, released versions of typing_extensions
monkeypatch this function without the extra parameter, which makes
it so things break badly if current main is used with typing_extensions.
Fortunately, the monkeypatching is not needed on Python 3.13, because CPython
now implements PEP 696. By renaming the function, we prevent the monkeypatch
from breaking typing.py internals.
We keep the old name (raising a DeprecationWarning) to help other external users who call it.
