Inconsistent behaviors of `dict.keys()`, `dict.values()` and `dict.items()` with `==`

[hyperkai]

Bug report

Bug description:

dict.keys() and dict.keys() are True because they're the same type and dict.keys() and a list or tuple are False because they're different types but dict.keys() and a set or frozenset are True even though their types are different and it seems like the elements in dict.keys() are ordered but not unordered as shown below:

v = {'A':'B', 'C':'D', 'E':'F', 'G':'H', 'I':'J'}.keys()

print(v)
# dict_keys(['A', 'C', 'E', 'G', 'I'])

print(v == {'A':'B', 'C':'D', 'E':'F', 'G':'H', 'I':'J'}.keys())
# True

print(v == ['A', 'C', 'E', 'G', 'I'])            # list
print(v == ('A', 'C', 'E', 'G', 'I'))            # tuple
# False

print(v == {'A', 'C', 'E', 'G', 'I'})            # set
print(v == frozenset(['A', 'C', 'E', 'G', 'I'])) # frozenset
# True

for x in v:
    print(x)
# A
# C
# E
# G
# I

And, dict.items() and dict.items() are True because they're the same type and dict.items() and a list or tuple are False because they're different types but dict.items() and a set or frozenset are True even though their types are different and it seems like the elements in dict.items() are ordered but not unordered as shown below:

v = {'A':'B', 'C':'D', 'E':'F', 'G':'H', 'I':'J'}.items()

print(v)
# dict_items([('A', 'B'), ('C', 'D'), ('E', 'F'), ('G', 'H'), ('I', 'J')])

print(v == {'A':'B', 'C':'D', 'E':'F', 'G':'H', 'I':'J'}.items())
# True

print(v == [('A', 'B'), ('C', 'D'), ('E', 'F'), ('G', 'H'), ('I', 'J')])            # list
print(v == (('A', 'B'), ('C', 'D'), ('E', 'F'), ('G', 'H'), ('I', 'J')))            # tuple
# False

print(v == {('A', 'B'), ('C', 'D'), ('E', 'F'), ('G', 'H'), ('I', 'J')})            # set
print(v == frozenset([('A', 'B'), ('C', 'D'), ('E', 'F'), ('G', 'H'), ('I', 'J')])) # frozenset
# True

for x in v:
    print(x)
# ('A', 'B')
# ('C', 'D')
# ('E', 'F')
# ('G', 'H')
# ('I', 'J')

Finally, dict.values() and dict.values(), a list, tuple, set or frozenset are all False whether their types are the same or different and whether their elements are ordered or unordered as shown below:

v = {'A':'B', 'C':'D', 'E':'F', 'G':'H', 'I':'J'}.values()

print(v)
# dict_values(['B', 'D', 'F', 'H', 'J'])

print(v == {'A':'B', 'C':'D', 'E':'F', 'G':'H', 'I':'J'}.values()) # dict.values()    
print(v == ['B', 'D', 'F', 'H', 'J'])                              # list
print(v == ('B', 'D', 'F', 'H', 'J'))                              # tuple
print(v == {'B', 'D', 'F', 'H', 'J'})                              # set
print(v == frozenset(['B', 'D', 'F', 'H', 'J']))                   # frozenset
# False

for x in v:
    print(x)
# B
# D
# F
# H
# J

CPython versions tested on:

3.12

Operating systems tested on:

No response

[picnixz]

keys() behave as a set, so comparison is ok but dict.items() == frozenset(...) os really weird. This could be a remnant when the dicts didn't preserve insertion order.

[ronaldoussoren]

The dict.item() == frozenset([...]) case is also documented. The items view is conceptually a set of (key, value) pairs when the values are hashable.

[skirpichev]

I would rather see this as a documentation issue. Yes, it's documented that views are set-like objects. On another hand, it's documented that comparisons treat different types as unequal (usually):

Objects of different types, except different numeric types, never compare equal.

We have exclusion from this for set vs frosenzet:

Both set and frozenset support set to set comparisons. Two sets are equal if and only if every element of each set is contained in the other (each is a subset of the other). A set is less than another set if and only if the first set is a proper subset of the second set (is a subset, but is not equal). A set is greater than another set if and only if the first set is a proper superset of the second set (is a superset, but is not equal).

Instances of set are compared to instances of frozenset based on their members.

But there is no such exclusion for views. Best I can see is something like this:

if all values in an items view are hashable as well, then the items view can interoperate with other sets.

[serhiy-storchaka]

This looks like a duplicate of #56654 and #81300.