Repository navigation
Conversation
Documentation build overview
|
| ) | ||
|
|
||
|
|
||
| def evaluate_type( |
There was a problem hiding this comment.
Should we allow plain strings to be passed, by using _make_forward_ref()? If so, what should we use for is_argument and is_class? I'd suggest we can infer the object type from owner, and if globals/locals/type params are manually provided instead, we pass is_argument=False, is_class=True as we can't assume anything on the owner and so we allow any type qualifier.
There was a problem hiding this comment.
I think we should, since plain strings are valid type expressions and this thing should ideally support any type expression.
| This is similar to calling :func:`evaluate_forward_ref`, but unlike that | ||
| method, :func:`evaluate_type` also supports arbitrary type hints. | ||
|
|
||
| See the documentation for :meth:`annotationlib.ForwardRef.evaluate` for |
There was a problem hiding this comment.
We can also properly document the behavior of each argument here, but this will introduce some repetition..
|
This PR is stale because it has been open for 90 days with no activity. |
JelleZijlstra
left a comment
JelleZijlstra
left a comment
There was a problem hiding this comment.
This also needs unit tests for the new function.
| ) | ||
|
|
||
|
|
||
| def evaluate_type( |
There was a problem hiding this comment.
I think we should, since plain strings are valid type expressions and this thing should ideally support any type expression.
github-actions
Bot
removed
the
stale
|
Added tests and support for string objects. |
2 participants
As per the discussion in https://discuss.python.org/t/100698.
With the new stuff since 3.14, we end up in a bit of an unfortunate situation, where we already have
typing.evaluate_forward_ref()as a public function that can do pretty much anything, expect it requires a forward ref instance. So with this PR we end up with the chainevaluate_type()which is likeevaluate_forward_ref()but allows arbitrary type hints, andevaluate_forward_ref()being likeannotationlib.ForwardRef.evaluate()but also recursively evaluates nested forward references; this may be a bit confusing for users.Once we agree on the expected behavior and signature for this new function, I'll add tests (wondering if I should keep the scope narrow,
_eval_type()is already extensively tested byget_type_hints()) and flesh out the code docstring of the function.This should also fix #87629.