Non-overlapping identity check when member variable mutated by function call

[Hawk777]

I get the following error in a situation where I think I shouldn’t:

test.py:25: error: Non-overlapping identity check (left operand type: "Literal[MyEnum.FOO]", right operand type: "Literal[MyEnum.BAR]")

Given the following code:

import enum


@enum.unique
class MyEnum(enum.Enum):
    FOO = enum.auto()
    BAR = enum.auto()


class MyClass:
    __slots__ = (
        "_my_value",
    )

    _my_value: MyEnum

    def __init__(self) -> None:
        super().__init__()
        self._my_value = MyEnum.FOO

    def do_thing(self) -> None:
        if self._my_value is MyEnum.FOO:
            self._set_my_value_to_bar()
            # self._my_value = MyEnum.BAR
            if self._my_value is MyEnum.BAR:
                print("And yet, the value was BAR!")

    def _set_my_value_to_bar(self) -> None:
        self._my_value = MyEnum.BAR


if __name__ == "__main__":
    x = MyClass()
    x.do_thing()

If I uncomment the commented line, the error goes away. It seems that Mypy does not understand that a method call might mutate member variables of the class, obsoleting any prior checks of their values.

This is when running version 0.780 with --strict.

[JukkaL]

Yeah, this behavior is confusing. #9021 fixed a similar issue with booleans. A possible fix would be to omit non-overlapping equality checks based on enum values, since they are likely to result in false positives.

[Hawk777]

What does this have to do with enums, specifically? It seems to me that values of any type could run into this; the real problem is that making a method call ought to invalidate prior knowledge of the value.

[JelleZijlstra]

@Hawk777 it's a tradeoff, but my sense is that doing so would invalidate the precise type too often, which would then lead to annoying false positives.

[JukkaL]

Yeah, this is all based on heuristics. There's no way we can reliably decide whether a function or method (or operator) could modify some inferred type as a side effect, so we make the simplification of assuming that it doesn't happen. This works well in practice, except for certain idioms which tend to generate false positives.

[intgr]

One work-around is using no-op assignments whenever there are side-effects, to make mypy forget its learned constraints:

assert foo.status == 'spam'
foo.refresh_from_db()
foo = foo  # <-- Work-around for https://github.com/python/mypy/issues/9005
assert foo.status == 'eggs'
#          ^^^^^^ mypy no longer complains

There's no way we can reliably decide whether a function or method (or operator) could modify some inferred type as a side effect, so we make the simplification of assuming that it doesn't happen.

Maybe creating an annotation with PEP 593 Annotated[] to explicitly mark arguments that are known to be mutated?

E.g.

class Widget:
    def refresh_from_db(self: Annotated[Widget, mypy_extensions.Mutates]) -> None:
        self.status = ...

Then every time x.refresh_from_db() is called, mypy forgets any constraints it had learned for x.