Skip to content
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

Open
tyralla opened this issue Nov 9, 2024 · 2 comments
Open

==-based narrowing of Optional #18135

tyralla opened this issue Nov 9, 2024 · 2 comments
Labels
feature topic-type-narrowing Conditional type narrowing / binder

Comments

@tyralla
Copy link
Collaborator

tyralla commented Nov 9, 2024

  1. Mypy's current behaviour:
x: int | None
if x == None:
    x  # "Union[builtins.int, None]"
else:
    x  # "Union[builtins.int, None]"
  1. Pyright's current behaviour:
x: int | None
if x == None:
    x  # x is None
else:
    x  # x is int
  1. I think the ideal solution would be:
x: int | None
if x == None:
    x  # "Union[builtins.int, None]"
else:
    x  # "builtins.int"

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.

@tyralla tyralla added feature topic-type-narrowing Conditional type narrowing / binder labels Nov 9, 2024
@hauntsaninja
Copy link
Collaborator

hauntsaninja commented Nov 14, 2024

I think both 2 and 3 are fine. If we go with 3, we should look at presence of __eq__ (int has __eq__ defined, not sure why, dates back to 2015)

@tyralla
Copy link
Collaborator Author

tyralla commented Nov 14, 2024

Did you mean we should check for __eq__ when going for solution 2?

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 __eq__ strangely:

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 __eq__ with checking for final:

from typing import final

@final
class A: ...

def f(x: A | None) -> None:
    if x == None:
        reveal_type(x)  # must be None

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature topic-type-narrowing Conditional type narrowing / binder
Projects
None yet
Development

No branches or pull requests

2 participants