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

Closed
tyralla opened this issue Nov 9, 2024 · 2 comments · Fixed by #18163
Closed

==-based narrowing of Optional #18135

tyralla opened this issue Nov 9, 2024 · 2 comments · Fixed by #18163
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

tyralla added a commit to tyralla/mypy that referenced this issue Nov 18, 2024
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.
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

Successfully merging a pull request may close this issue.

2 participants