Repository navigation
Changed strict-equality behavior with dict/Mapping #16340
Description
When using mypy 1.6, this example produces no errors:
# mypy: strict-equality
from typing import Mapping
def f(x: dict[str, int | None], y: dict[str, str | None]) -> bool:
return x == y
def g(x: Mapping[str, int], y: str) -> bool:
return x == yHowever, after #16237, it started generating these errors:
t.py:6: error: Non-overlapping equality check (left operand type: "dict[str, int | None]", right operand type: "dict[str, str | None]") [comparison-overlap]
t.py:9: error: Non-overlapping equality check (left operand type: "Mapping[str, int]", right operand type: "str") [comparison-overlap]
I'm not sure if the new behavior is better or not, but I suspect that the change in behavior may have been an unintended consequence of #16237, so it seems worth investigating what is going on.
cc @ilevkivskyi
Activity
ilevkivskyi commentedon Oct 27, 2023
This is actually intentional. For my
len()PR I needed to disable thelen()check if a tuple subclass has a custom (i.e. user-defined)__len__()(and/or a user-defined__bool__()for cases likeassert some_tuple). But then it turned out the existing helpercustom_special_method()didn't work, because it considered special methods defined intypingas user-defined (it only allowedbuiltinsas not user-defined), andtuplegets its__len__()fromtyping. But also it turns outdictgets its__eq__()fromtypingas well, so we actually never checked unsafe overlap for dictionaries/mappings (because we always considered equality as user-defined there).FWIW I think the new behavior is consistent with how we handle e.g. lists etc where we get
I propose closing this.
JukkaL commentedon Oct 27, 2023
Makes sense! Thanks for looking into this.