On Fri, Jul 26, 2019 at 12:57:42AM -0400, Random832 wrote:
> On Fri, Jul 26, 2019, at 00:22, Ivan Pozdeev via Python-Dev wrote:
> > Since a hash table is an unordered container and keys(), items() and
> > values() are iterators over it, *I would expect the results of any of
> > the comparisons to be undefined.*
>
> keys, items, and values are not iterators. They are view objects, and
> keys and items implement the entire set API (in the same sense that
> range implements the entire sequence API). Values is the odd one out
> in that it can contain multiple instances of each object, so it can't
> really be considered as a set.
But it can be considered a multiset.
In plain English, a set can contain duplicates. If I have a set of some
collectable item (say, trading cards), or a dinner set, they can contain
duplicates.
We shouldn't make too much of the fact that Python sets collapse
multiples of a value down to one. If we wanted a multiset, we could get
one. collections.Counter is already a multiset of sorts.
Nor should we make too much of the fact that Python sets require
elements to be hashable. As Java TreeSet demonstrates, we could get an
efficient set of unhashable items if we required orderability; and we
can get sets of unhashable, unorderable items if we're willing to
compromise on efficiency.
> Items also sometimes contains unhashable types, and some methods
> simply fail in that case. I suggest that this precedent provides a way
> forward - implement the entire intuitive "contains the same amount of
> each value" algorithm [more or less Counter(obj1) == Counter(obj2)],
> and have this fail naturally, throwing e.g. an exception "TypeError:
> unhashable type: 'list'" if any of the values are unhashable in the
> same way that trying to perform certain set operations on an items
> view does.
Equality tests really ought not to fail. If they do fail, it should be
considered a bug in the __eq__ method, not an intentional result.
To allow == tests to fail is just a way of sneaking in a three-value
logic into the language, only using an extremely inconvenient API:
try:
if a == b:
print(True)
else:
print(False)
except Exception:
print(Maybe) # or undecidable, unknown, mu, etc.
Multi-value logics usually model the complexities of the real world much
better than boolean logic, but the assumption of boolean logic and the
law of the excluded middle is too prevalent to mess with in the
builtins.
http://mathworld.wolfram.com/LawoftheExcludedMiddle.html
https://en.wikipedia.org/wiki/Three-valued_logic
--
Steven
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/DGVHRP7DSQY43WEDEQBPEMGKYM57WUPU/
