You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The behavior in this example was changed in #18538:
defany():
return1deff() ->None:
x="a"x=any()
assertisinstance(x, int)
reveal_type(x) # "Never", but used to be unreachable (no message)
In the past, the code after isinstance was silently unchecked. Now the inferred type is Never, which will likely generate false positives. Neither behavior is great, but users may consider the switch from false negatives to false positives to be a regression. I'm not sure what we should do here. If we'd allow variables to be redefined freely, there would be no issue.
cc @ilevkivskyi who authored the PR that changed the behavior
The text was updated successfully, but these errors were encountered:
In #18707 I changed things such that narrowing to Never (or assigning it in any way, really) would mark a block as unreachable. That seemed to work decently well.
I would be fine to extract that if it's a good idea.
Marking this code unreachable is a possible solution, but it may cause undesired behavior in other cases. Another possible option would be to replace Never with known restriction (i.e. int in this example), it will likely have a more limited impact. I can try this now, and see if there any adverse effects.
The behavior in this example was changed in #18538:
In the past, the code after
isinstance
was silently unchecked. Now the inferred type isNever
, which will likely generate false positives. Neither behavior is great, but users may consider the switch from false negatives to false positives to be a regression. I'm not sure what we should do here. If we'd allow variables to be redefined freely, there would be no issue.cc @ilevkivskyi who authored the PR that changed the behavior
The text was updated successfully, but these errors were encountered: