Better support for SomeEnum.item == some_literal

[sterliakov]

Fixes #19576.
Fixes #16327.
Should fix #17162 too, but doesn't yet, keeping in draft for now.

This needs more feedback: is the logic I propose reasonable? Do we want to be stricter and reject such comparisons altogether? Or maybe only reject them if values are incompatible?

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[A5rocks]

I was a bit confused about this in the original issue too

[A5rocks]

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

[sterliakov]

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.

[A5rocks]

Did I misunderstand something?

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

[sterliakov]

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

[sterliakov]

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

[A5rocks]

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)

[sterliakov]

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.