keying by identity in dict and set
Steve White
stevan.white at gmail.com
Sun Oct 20 14:29:00 EDT 2019
On Sun, Oct 20, 2019 at 7:57 PM Peter Otten <__peter__ at 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!
More information about the Python-list
mailing list