Properly account for member and nonmember in TypeInfo.enum_members

[sobolevn]

Closes #18557

[tyralla]

This is the first time I heard about member and nomember, but I appreciate the opportunity to learn...

I played a little and found your fix does not cover the following slight change of your example:

from enum import Enum, member
from typing import reveal_type

class Pet(Enum):
    CAT = 1

    @member
    def human(self) -> int:
        return 2

def a(x: Pet) -> None:
    if x is not Pet.human:  # `human` instead of `CAT`, as in the original example
        reveal_type(x)  # N: Revealed type is "__main__.Pet"

Expected would be Literal[__main__.Pet.CAT]

However, this does not seem to be related to TypeInfo.enum_members, so this comment is just a suggestion for an extension of this or an independent PR.

Because of my lack of experience, I am not really sure if some edge cases are missed, but to me, this change looks good and is definitely an improvement.

[sobolevn]

However, this does not seem to be related to TypeInfo.enum_members, so this comment is just a suggestion for an extension of this or an independent PR.

Yeah, there are multiple other problems with Enum. For example: #18563

I think that the example that you've mentioned is happening because right now Enum cannot properly unwrap callable types or something.

[A5rocks]

Should this condition exist for enum.member too because #18563?

[sobolevn]

Hm, good question. Let's keep it for now, I will change it in #18563 if needed.

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

freqtrade (https://github.com/freqtrade/freqtrade): 1.98x slower (128.9s -> 255.0s in a single noisy sample)

[sobolevn]

My further plan: get rid of is_final_enum_value and use enum_members everywhere, PR is incoming!

[sobolevn]

Done: #18675