-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
==
-based narrowing of Optional
#18135
Comments
I think both 2 and 3 are fine. If we go with 3, we should look at presence of |
Did you mean we should check for If so, this could be an additional safety net for most cases. Then, the modified solution 2 would only result in wrong narrowing for subtypes that override class A: ...
class B(A):
def __eq__(self, o: object) -> bool:
return True
def f(x: A | None) -> None:
if x == None:
assert x is None
f(B()) # AssertionError I think, for complete safety, we would have to combine looking for from typing import final
@final
class A: ...
def f(x: A | None) -> None:
if x == None:
reveal_type(x) # must be None |
Closes python#18135 This change implements the third approach mentioned in python#18135, which is stricter than similar narrowings, as clarified by the new/modified code comments. Personally, I prefer this more stringent way but could also switch this PR to approach two if there is a consent that convenience is more important than type safety here.
This Mypy code comment seems to favour solution 2.
I am asking because if Mypy would follow solution 2 or 3,
in
-based narrowing of optional types could be implemented more consistently.Related pull requests: #15760 #17154 #17044.
The text was updated successfully, but these errors were encountered: