-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[ty] Add partial support for TypeIs
#18589
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
Conversation
|
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 pushed a commit that fixes the fuzzer-found panic here; it's a pre-existing issue that crops up here due to extra cycles created by the extra type inference now done in evaluate_name_expr
.
Otherwise, looks like some comments on the previous PR aren't yet addressed here? But I realize this is still in draft.
crates/ty_python_semantic/resources/mdtest/type_properties/is_assignable_to.md
Outdated
Show resolved
Hide resolved
crates/ty_python_semantic/resources/mdtest/type_properties/is_disjoint_from.md
Outdated
Show resolved
Hide resolved
@carljm Thanks for looking into the panic. The PR is ready for a full review now. |
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.
Looking good! A few comments.
crates/ty_python_semantic/resources/mdtest/narrow/type_guards.md
Outdated
Show resolved
Hide resolved
crates/ty_python_semantic/resources/mdtest/narrow/type_guards.md
Outdated
Show resolved
Hide resolved
crates/ty_python_semantic/resources/mdtest/narrow/type_guards.md
Outdated
Show resolved
Hide resolved
Now there's a new panic:
Line 104 is this one: from typing_extensions import TypeGuard, TypeIs |
You need to make sure you store a type for each subexpression when parsing the type annotation, even if you know that the types of the subexpressions will be irrelevant to the type of the outer expression. We made our tests more rigorous about catching this error recently (#18539). You can take a look at what I'm doing for |
Got it, thanks! |
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.
Thank you!
Summary
Redo of #16314 and #18294, part of #117.
TypeIs[]
is a special form that allows users to define their own narrowing functions. Despite the syntax,TypeIs
is not a generic and, on its own, it is meaningless as a type. Officially, a function annotated as returning aTypeIs[T]
is a type narrowing function, whereT
is called theTypeIs
return type.A
TypeIs[T]
may or may not be bound to a symbol. Only bound types have narrowing effect:Delayed usages of a bound type has no effect, however:
A
TypeIs[T]
type:T
is fully static.True
andFalse
.In other words, an unbound type have ambiguous truthiness.
It is possible to infer more precise truthiness for bound types; however, that is not part of this change.
TypeIs[T]
is a subtype of or otherwise assignable tobool
.TypeIs
is invariant with respect to theTypeIs
return type:TypeIs[int]
is neither a subtype nor a supertype ofTypeIs[bool]
. When ty sees a function marked as returningTypeIs[T]
, itsreturn
s will be checked againstbool
instead. ty will also report such functions if they don't accept a positional argument. Addtionally, a type narrowing function call with no positional arguments (e.g.,f()
in the example above) will be considered invalid.Test Plan
Markdown tests.