On Sun, Oct 20, 2019 at 7:57 PM Peter Otten <__pete...@web.de> wrote: > > Steve White wrote: > > > > The point is, I don't think __eq__() is ever called in a situation as > > described in my post, yet the Python documentation states that if > > instances are to be used as keys, it must not be used to determine if > > non-identical instances are equivalent. > > What else should be used if not __eq__()? Where in the docs did you you see > such a statement? > Nothing. Nowhere.
As I said, it appears that if __hash__ returns values from the id() function, no collision ever occurs, so there is tie to break in a lookup, so in particular there is no need for the heuristic of calling __eq__. And again, the problem here is that the documentation is a little weak on just how these things really interact. We're having to guess, experiment, and even look at C code of the Python implementations. > The only limitation for a working dict or set is that for its keys or > elements > > (1) a == b implies hash(a) == hash(b) > (2) a == a > > Does your custom class violate one of the above? > Yes. It's all in the original post, including code. Give it a shot! Thanks! -- https://mail.python.org/mailman/listinfo/python-list
