Skip to content

Better support for SomeEnum.item == some_literal #19594

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.

Sign up for GitHub

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

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from
Draft

Better support for SomeEnum.item == some_literal #19594

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
ab3ed33
Fix enum comparison with literal values
sterliakov Aug 4, 2025
6f4dbb8
Merge remote-tracking branch 'upstream/master' into bugfix/gh-19576-e…
sterliakov Aug 7, 2025
350aa53
Sync reachability and comparison overlap checks
sterliakov Aug 7, 2025
ebfc647
Fix selfcheck
sterliakov Aug 7, 2025
0001936
Oops
sterliakov Aug 7, 2025
c87c707
Prevent narrowing by equality to overlapping literals (discarding enu…
sterliakov Aug 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion mypy/meet.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -547,9 +547,12 @@ def _type_object_overlap(left: Type, right: Type) -> bool:
right = right.fallback

if isinstance(left, LiteralType) and isinstance(right, LiteralType):
if left.value == right.value:
if left.value == right.value or (left.fallback.type.is_enum ^ right.fallback.type.is_enum):
# If values are the same, we still need to check if fallbacks are overlapping,
# this is done below.
# Enums are more interesting:
# * if both sides are enums, they should have same values
# * if exactly one of them is a enum, fallback compatibibility is enough
left = left.fallback
right = right.fallback
else:
Expand Down
47 changes: 47 additions & 0 deletions test-data/unit/check-enum.test
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2681,3 +2681,50 @@ reveal_type(Wrapper.Nested.FOO) # N: Revealed type is "Literal[__main__.Wrapper
reveal_type(Wrapper.Nested.FOO.value) # N: Revealed type is "builtins.ellipsis"
reveal_type(Wrapper.Nested.FOO._value_) # N: Revealed type is "builtins.ellipsis"
[builtins fixtures/enum.pyi]

[case testEnumItemsEqualityToLiterals]
# flags: --python-version=3.11 --strict-equality
from enum import Enum, StrEnum, IntEnum

class A(str, Enum):
a = "b"
b = "a"

A.a == "a"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me why A.a == "a" should be allowed

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, that's basically what I want to gather feedback on: at runtime it's true, so there is some merit in allowing such comparisons (see also #17162 for exactly such example).

I'll need to update all added tests to check reachability - if the comparison is not considered non-overlapping, corresponding if bodies must be reachable.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did I misunderstand something?

>>> import enum
>>> class X(enum.Enum):
...   a = "b"
... 
>>> X.a == "a"
False

Copy link
Collaborator Author

@sterliakov sterliakov Aug 5, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plain enum.Enum doesn't compare equal, of course.

In the test case, however, I'm checking StrEnum and str, Enum subclasses, and they do compare equal to strings matching the values:

import enum

class A(str, enum.Enum):
    A = 'a'

A.A == 'a'  # True

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(so in #17162 both cases must be reachable, and IMO shouldn't show comparison-overlap errors)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might be talking about different things. I'm referring to an X.a which is a "b", not a "a". I somehow missed that it doesn't return True for non-string-enums though. For reference:

>>> import enum
>>> class X(str, enum.Enum):
...   a = "b"
... 
>>> X.a == "a"  # this is currently allowed, but returns False
False
>>> X.a == "b"  # this is currently disallowed, but returns True
True

While this PR handles the second case, I think the first case matters too. (Though I haven't cared enough to look at mypy internals and see why it happens ATM)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ough, sorry, I must return to this tomorrow with more focus. Yep, that's the question I asked in the PR description: should we reject such comparisons with an incompatible by value literal? I don't have any strong preference here, except that this implementation complexity may not be worth the benefits: how often do people compare two literals for equality? I don't see any obvious use case for that, so just saying "ok, this looks good enough, such comparison is fine at type level" might be a better strategy. Implementing value-based checks would be slightly less trivial.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, being more smart is good, especially since I doubt it's that many extra lines?

I agree many people may not directly compare literals by value, but I imagine it's useful for like type narrowing. (since we treat enums as a union of their literal elements, I think?)

A.a == "b"

A.a == A.a
A.a == A.b # E: Non-overlapping equality check (left operand type: "Literal[A.a]", right operand type: "Literal[A.b]")

class B(StrEnum):
a = "b"
b = "a"

B.a == "a"
B.a == "b"

B.a == B.a
B.a == B.b # E: Non-overlapping equality check (left operand type: "Literal[B.a]", right operand type: "Literal[B.b]")

B.a == A.a # E: Non-overlapping equality check (left operand type: "Literal[B.a]", right operand type: "Literal[A.a]")

class C(IntEnum):
a = 0

C.a == "a" # E: Non-overlapping equality check (left operand type: "Literal[C.a]", right operand type: "Literal['a']")
C.a == "b" # E: Non-overlapping equality check (left operand type: "Literal[C.a]", right operand type: "Literal['b']")

C.a == C.a
C.a == C.b

class D(int, Enum):
a = 0

D.a == "a" # E: Non-overlapping equality check (left operand type: "Literal[D.a]", right operand type: "Literal['a']")
D.a == "b" # E: Non-overlapping equality check (left operand type: "Literal[D.a]", right operand type: "Literal['b']")

D.a == D.a
D.a == D.b

D.a == C.a # E: Non-overlapping equality check (left operand type: "Literal[D.a]", right operand type: "Literal[C.a]")
[builtins fixtures/dict.pyi]
Loading