[1.14 regression] truthy check for enums

[delfick]

Bug Report

It appears the truthy check for enums is incorrect in 1.14 when warn_unreachable is set to True.

For example

import enum


class MyEnum(enum.StrEnum):
    EMPTY = ""
    NOT_EMPTY = "asdf"


def is_truthy(e: MyEnum) -> None:
    if e:
        print(f"{e} was truthy: {len(e)}")
    else:
        print(f"{e} was falsey: {len(e)}")


is_truthy(MyEnum.EMPTY)
is_truthy(MyEnum.NOT_EMPTY)

With a mypy.ini

[mypy]
warn_unreachable = True

If we run the script we get:

 was falsey: 0
asdf was truthy: 4

Which shows the behaviour of these enums is such that they can be used in an if condition

but running mypy a.py results in:

a.py:13: error: Statement is unreachable  [unreachable]
Found 1 error in 1 file (checked 1 source file)

Your Environment

• Mypy version used: 1.14
• Python version used: tested with and saw same problem on python3.12 and python3.13

[hauntsaninja]

Thanks, bisects to #17337

[hauntsaninja]

cc @Daverball in case you have time to take a look

[hauntsaninja]

PR here #18379

[delfick]

Thanks :)

[Daverball]

This is specific to StrEnum and a typeshed bug. Even though str provides a custom __bool__ method at runtime the typeshed stubs don't represent that, so the only __bool__ method the trutyness check finds is the one on EnumType which is always True.

Case in point, the bug disappears if you use IntEnum, where int also provides its own __bool__.

So it's not really a true regression, the old broken behavior happened to be accidentally correct for StrEnum, because it used the enum value for determining truthyness, which is only correct for StrEnum and IntEnum.

We could probably slightly improve the behavior for StrEnum and IntEnum by special-casing them, so we statically determine that an IntEnum member with value 0 is always falsey and every other value is always truthy and the same for StrEnum with the empty string vs. any other string. But I'm not fully convinced it's worth the extra complication, since we would need to detect any custom enum subclass that inherits from either str or int without overriding __bool__ somewhere along the way.

[Daverball]

Hmm, actually str's trutyhness relies on __len__ rather than __bool__, so there is actually no __bool__. So looks like this is actually a bug, so the fallback to the metaclass only should happen when there's no type providing either __bool__ or __len__ in the mro.

[hauntsaninja]

Yup on __len__. I'm not sure metaclasses should be involved here. See the PR I opened with the link to Brett's description of CPython truthiness logic... I think it basically boils down to enum being final