Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32k
gh-133960: Improve typing.evaluate_forward_ref#133961
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
As explained inpython#133960, this removes most of the behavior differences with ForwardRef.evaluate.The remaining difference is about recursive evaluation of forwardrefs; this is practically usefulin 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() toevaluate more ForwardRefs in the FORWARDREF format.This alsofixespython#133959 as a side effect, because the buggy behavior inpython#133959 derives fromevaluate_forward_ref().
| A = "str" | ||
| ref = ForwardRef('list[A]') | ||
| with self.assertRaises(NameError): | ||
| typing.evaluate_forward_ref(ref) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
remind me why this needs to raiseNameError? Does theglobals argument not default to the globals of the module callingevaluate_forward_ref? I think that's what I'd naively expect.
The docs fortyping.evaluate_forward_ref point me towardshttps://docs.python.org/3.14/library/annotationlib.html#annotationlib.ForwardRef.evaluate for information on these parameters, but the docs there are silent on what happens ifglobals isNone andowner isNone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
It eventually defaults to empty globals. I think that's right for most use cases; usually you'll be evaluating a ForwardRef in a library that came from some user code, and the globals of the module where you're doing the evaluating aren't a particularly good place to look for data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'll make a separate PR adding this to the annotationlib docs
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
57fef27 intopython:mainUh oh!
There was an error while loading.Please reload this page.
Thanks@JelleZijlstra for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14. |
As explained inpythonGH-133960, this removes most of the behavior differences with ForwardRef.evaluate.The remaining difference is about recursive evaluation of forwardrefs; this is practically usefulin 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() toevaluate more ForwardRefs in the FORWARDREF format.This alsofixespythonGH-133959 as a side effect, because the buggy behavior inpythonGH-133959 derives fromevaluate_forward_ref().(cherry picked from commit57fef27)Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
GH-134663 is a backport of this pull request to the3.14 branch. |
…34663)gh-133960: Improve typing.evaluate_forward_ref (GH-133961)As explained inGH-133960, this removes most of the behavior differences with ForwardRef.evaluate.The remaining difference is about recursive evaluation of forwardrefs; this is practically usefulin 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() toevaluate more ForwardRefs in the FORWARDREF format.This alsofixesGH-133959 as a side effect, because the buggy behavior inGH-133959 derives fromevaluate_forward_ref().(cherry picked from commit57fef27)Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Refer topython/cpython#133961I copied the tests from Python 3.14. Two don't pass but could probably bemade to pass by backporting more of annotationlib, but that's more thanI think we should do now.Fixespython#608
Refer topython/cpython#133961I copied the tests from Python 3.14. Two don't pass but could probably bemade to pass by backporting more of annotationlib, but that's more thanI think we should do now.Fixes#608
Uh oh!
There was an error while loading.Please reload this page.
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 alsofixes#133959 as a side effect, because the buggy behavior in#133959 derives from
evaluate_forward_ref().
typing.evaluate_forward_ref#133960📚 Documentation preview 📚:https://cpython-previews--133961.org.readthedocs.build/