Unexpected error comparing set and frozenset for equality with --strict-equality

[neiljp]

I just upgraded a local mypy installation to 0.720 (python 3.6.5) and was exploring --strict-equality.

My interpretation is that sets and frozensets can be compared just fine; as such the following error was rather unexpected:

$mypy --strict-equality /tmp/blah.py
blah.py:3: error: Non-overlapping equality check (left operand type: "FrozenSet[int]", right operand type: "Set[int]")

for

# blah.py
x = frozenset([1,2,3])
y = set([1,2,3])
if x == y:
    print("equal")

As expected, python3 blah.py gives equal.

[msullivan]

That is cute and frustrating. The error trips because the types aren't considered overlapping since neither is a superclass of the other, but nevertheless __eq__ returns true because they are specifically built to handle that.

A related failure mode is {1: 2}.keys() == {1}, which fails due to non-overlapping equality of Set and KeysView.

If this is relatively uncommon, we can maybe handle it with some special casing (of AbstractSet, perhaps) in dangerous_comparison. If this turns out to happen more than I would guess, we might need to do something smart. (Looking at __eq__ types, for example)

[ilevkivskyi]

@msullivan I think we can special-case both cases.