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

Type narrowing with identity check #9758

Open
hamdanal opened this issue Jan 25, 2025 · 2 comments
Open

Type narrowing with identity check #9758

hamdanal opened this issue Jan 25, 2025 · 2 comments
Labels
addressed in next version Issue is fixed and will appear in next published version enhancement request New feature or request

Comments

@hamdanal
Copy link

Is your feature request related to a problem? Please describe.

According to the pyright documentation https://microsoft.github.io/pyright/#/type-concepts-advanced?id=type-guards, narrowing with identity check using the is operator is supported for booleans and enumerations. It would be nice to also be able to narrow on identity checks with other literals.

Describe the solution you’d like

Currently pyright thinks that x could be None in the if branch:

from random import choice
from typing import Final

ONE: Final = 1
x: int | None = choice((1, None))
if x is ONE:
    reveal_type(x)  # mypy: "int", pyright: "Literal[1] | None"
else:
    reveal_type(x)  # mypy: "int | None", pyright: "Literal[1] | None"

I expect the type in the if branch to be narrowed to "Literal[1]". It should be safe to do this kind of narrowing here.

@hamdanal hamdanal added the enhancement request New feature or request label Jan 25, 2025
@erictraut
Copy link
Collaborator

The is operator checks whether the two operands are the same object, not whether the two objects have equal value. You should use == here instead if you want your code to be robust.

The code in your example happens to work because the Python runtime interns certain small int objects, effectively treating all 1 instances as the same object. It doesn't necessarily do this for all int values. It also interns some short string values. However, this behavior is an implementation detail that may not hold for other implementations or versions of Python. Your code should not rely on it. Use == instead.

The main purpose of a type checker is to help you write robust, maintainable code. This coding pattern does the opposite, so it's unlikely that we'd ever support the requested feature.

@erictraut erictraut closed this as not planned Won't fix, can't repro, duplicate, stale Jan 25, 2025
@erictraut erictraut added the as designed Not a bug, working as intended label Jan 25, 2025
@erictraut
Copy link
Collaborator

erictraut commented Jan 25, 2025

On second thought, if you change your code to choice(ONE, None), it would avoid the unsafe assumption.

I also initially missed the fact that mypy implements this type narrowing form.

Reopening for reconsideration.

@erictraut erictraut reopened this Jan 25, 2025
@erictraut erictraut removed the as designed Not a bug, working as intended label Jan 25, 2025
erictraut added a commit that referenced this issue Jan 25, 2025
…pattern. Previously, narrowing was performed only when `L` was an enum or bool literal. Narrowing is also now applied for other literal types but only in the positive (`if`) direction. This addresses #9758.
erictraut added a commit that referenced this issue Jan 25, 2025
…pattern. Previously, narrowing was performed only when `L` was an enum or bool literal. Narrowing is also now applied for other literal types but only in the positive (`if`) direction. This addresses #9758. (#9759)
@erictraut erictraut added the addressed in next version Issue is fixed and will appear in next published version label Jan 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version enhancement request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants