Unsupported operand types depending on number of enum.Flag values

[astrojuanlu]

Bug Report

Depending on the number of enum.Flag possible values, I get a MyPy "Unsupported operand types" error.

To Reproduce

$ cat mypy_flags_simple.py 
from enum import Flag, auto


class MyStatus(Flag):
    A = auto()
    B = auto()
    C = auto()  # If commented out, no error!


def check_status(s: MyStatus) -> str:
    if s is MyStatus.A:
        return "A"
    elif s & MyStatus.B:
        return "B"
    else:
        return "Other"


if __name__ == "__main__":
    check_status(MyStatus.B)

Expected Behavior

Not give an error.

Actual Behavior

$ mypy mypy_flags_simple.py --pretty --show-error-codes
mypy_flags_simple.py:13: error: Unsupported operand types for & ("Literal[MyStatus.C]" and "Literal[MyStatus.B]")  [operator]
        elif s & MyStatus.B:
                 ^
mypy_flags_simple.py:13: note: Left operand is of type "Union[Literal[MyStatus.B], Literal[MyStatus.C]]"
Found 1 error in 1 file (checked 1 source file)

Your Environment

• Mypy version used: 0.790
• Mypy command-line flags: --pretty --show-error-codes
• Mypy configuration options from mypy.ini (and other config files): (None)
• Python version used: 3.8.5
• Operating system and version: Linux Mint 20

[JelleZijlstra]

This is probably because of the piece of the stubs (https://github.com/python/typeshed/blob/master/stdlib/3/enum.pyi#L63) that has def __and__(self: _T, other: _T) -> _T: .... We use the _T to make it so you can only and a Flag with another instance of the same Flag enum, and you get another instance of the same enum back. But if the self type is a Literal, mypy constrains _T to be the literal type, and then it no longer allows a different literal for the other argument.

I'm not sure what the best solution is. Perhaps mypy could be made to infer _T as MyStatus instead of Literal[MyStatus.B] here, but I'm not sure how easy that is or if it would have unforeseen side effects. We could also loosen the types in typeshed to something like def __and__(self, other: Flag) -> Flag:, but that would lose some type safety.

[erictraut]

This problem appears to have been fixed. I can no longer repro the error with the latest version of mypy.

[jan-spurny]

I have probably the same problem with current (1.10.0) mypy version - it's python3.10 which triggeres the problem - it's fine with python 3.11.

My minimal code:

from enum import Flag, auto

class F(Flag):
    NOTHING = 0
    A = auto()
    B = auto()
    C = auto()
    D = auto()
    ALL = A | B | C | D


def foo(flags: F) -> None:
    if flags is F.NOTHING:
        print('nothing')
        return

    if flags & F.A:
        print('A set')

mypy output:

$ mypy --python-version 3.10 check_flags.py 
check_flags.py:19: error: Unsupported operand types for & ("Literal[F.B]" and "Literal[F.A]")  [operator]
check_flags.py:19: error: Unsupported operand types for & ("Literal[F.C]" and "Literal[F.A]")  [operator]
check_flags.py:19: error: Unsupported operand types for & ("Literal[F.D]" and "Literal[F.A]")  [operator]
check_flags.py:19: error: Unsupported operand types for & ("Literal[F.ALL]" and "Literal[F.A]")  [operator]
check_flags.py:19: note: Left operand is of type "Literal[F.A, F.B, F.C, F.D, F.ALL]"
Found 4 errors in 1 file (checked 1 source file)

For me it was actually triggered by checking the NOTHING value - without if flag is F.NOTHING.. code, it worked fine.
It's also fine when I have only 2 enum values (i.e. NOTHING + A).

I understand this is closed, but I was wondering if there is anything I can do (I have to use python3.10) besides # type ignore ?

[henryiii]

Another example:

import enum

class Validate(enum.Flag):
    TOP_LEVEL = enum.auto()
    BUILD_SYSTEM = enum.auto()
    PROJECT = enum.auto()
    WARN = enum.auto()
    ALL = TOP_LEVEL | BUILD_SYSTEM | PROJECT
    NONE = 0

validate: Validate = Validate.ALL

assert validate.TOP_LEVEL & validate

You can even reduce it to:

import enum

class Validate(enum.Flag):
    TOP_LEVEL = enum.auto()

validate: Validate = Validate.TOP_LEVEL

assert validate.TOP_LEVEL & validate

I'll open a new issue since this one is closed.

[henryiii]

Ahh, I'm getting the item from the instance - which is supported at runtime, but not idea. Getting it from the class works.