-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
Simplify typing.evaluate_forward_ref
#133960
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
3.14
bugs and security fixes
3.15
new features, bugs and security fixes
stdlib
Python modules in the Lib dir
topic-typing
type-bug
An unexpected behavior, bug, or error
Comments
JelleZijlstra
added a commit
to JelleZijlstra/cpython
that referenced
this issue
May 13, 2025
As explained in python#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 python#133959 as a side effect, because the buggy behavior in python#133959 derives from evaluate_forward_ref().
JelleZijlstra
added a commit
that referenced
this issue
May 25, 2025
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().
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
May 25, 2025
As explained in pythonGH-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 pythonGH-133959 as a side effect, because the buggy behavior in pythonGH-133959 derives from evaluate_forward_ref(). (cherry picked from commit 57fef27) Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
JelleZijlstra
added a commit
that referenced
this issue
May 25, 2025
…34663) gh-133960: Improve typing.evaluate_forward_ref (GH-133961) As explained in GH-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 GH-133959 as a side effect, because the buggy behavior in GH-133959 derives from evaluate_forward_ref(). (cherry picked from commit 57fef27) Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
3.14
bugs and security fixes
3.15
new features, bugs and security fixes
stdlib
Python modules in the Lib dir
topic-typing
type-bug
An unexpected behavior, bug, or error
Uh oh!
There was an error while loading. Please reload this page.
Bug report
In PEP-749 I added
typing.evaluate_forward_ref
to replace the privatetyping.ForwardRef._evaluate
, which is being used by some external users.The current documentation claims these differences from
annotationlib.ForwardRef.evaluate
:(1) is useful and fits well with the typing module; annotationlib can't do this because it requires introspecting into typing-specific objects. (2) I feel is not useful (compare #133959): the type check is not particularly thorough, and it's generally better for callers to allow more objects through that callers can handle on their own terms. (3) is sort of harmless but not particularly useful. (4) is not true any more since I also added support for these formats to
ForwardRef.evaluate
.So I'd like to drop differences 2 through 4, leaving the function focused on recursively evaluating nested ForwardRefs.
Linked PRs
The text was updated successfully, but these errors were encountered: