MyIntEnum.ONE should be passable to functions expecting Literal[1] arguments

[ambv]

Bug Report

This is related but distinct from #19576, #16327, and #17162. It's also not specific to IntEnums, but I use them in the example for clarity. StrEnums as well as enums based on (int, Enum), or (str, Enum), etc.

To Reproduce

import enum
from typing import Literal

type One = Literal[1]
type Two = Literal[2]
type Three = Literal[3]

def option(arg: One | Two | Three) -> None:
 ...

class MyEnum(enum.IntEnum):
 ONE = 1
 TWO = 2
 THREE = 3

option(MyEnum.TWO) # error: Argument 1 to "option" has incompatible type "Literal[MyEnum.TWO]"; expected "Literal[1, 2, 3]" [arg-type]

Expected Behavior

No error reported.

Actual Behavior

The error in the comment in the example is a false positive. This code works fine at runtime.

Your Environment

• Mypy version used: master as of 0d791b2
• Python version used: 3.13

[erictraut]

I think mypy is working correctly here.

An int Literal value must be an instance of int, not a subclass of int. I recently fixed a bug in pyright to enforce this. See this forum thread for more details.

In your code sample, you can make this comply with the type system by changing the final line to:

option(MyEnum.TWO.value)

[ambv]

@erictraut While I see the point in general, I disagree in particular. I'd argue that IntEnum/StrEnum are special cases, as they are handled in the PR. They aren't arbitrary "int subclasses" but ways to represent int values using namespaced human-readable names. That's exactly how IntEnums were introduced to, say, the socket standard library. I'll respond on the Discourse discussion.