Equivalent comparison operation in membership test operations for set container type is not 100% accurate. about cpython

[pochmann3]

print(a == 'True')
print(hash(a) == hash('True'))

prints:

True
False

Your class is broken.

From the __hash__ doc:

The only required property is that objects which compare equal have the same hash value

[sobolevn]

I've checked your example once again and found that you have both __eq__ and __hash__, but they break the __eq__ logic. By Python's rules:

• If objects are equal
• their hashes should be equal too

and this is not the case for your Foo class!

class Foo:
     def __init__(self, value: bool):
         self.value = value
     def __eq__(self, other):
         return self.value == bool(other)

f = Foo(1)

print(any(f is e or f == e for e in {1, 2}))  # True
print(any(f is e or f == e for e in {'a', 'b'}))  # True
print(any(f is e or f == e for e in {''}))  # False

For a regular class without __hash__ it works just fine.

[terryjreedy]

It is documented that a == b should imply that hash(a) == hash(b). Python works hard to make this so for builtins.

hash(1) == hash(1.0) == hash(Decimal(1)) == hash(Fraction(1,1)) == 1
True

When so, hash(a) != hash(b) implies a != b. The doc intentionally says 'equivalent', not 'exactly equal'. The speed shortcut is an CPython implementation detail. not a language requirement. Closing.

Please ask questions about CPython detail on, for instance, https://discuss.python.org/c/users/7, where many more people are likely to see answers.

[sobolevn]

@ThePhar indeed! Would you like to send a PR? I think it would be something like:

For several container types such as list, tuple, or collections.deque

[sobolevn]

wait a second :)