On Sat, May 2, 2020 at 10:36 PM Guido van Rossum <[email protected]> wrote:
> It does look like that would violate a basic property of `==` -- if two
> values compare equal, they should be equally usable as dict keys.
>
It's certainly a reasonable property, but I don't think it's critical.
By comparison, if it was the case that `(1, 2, 3) == [1, 2, 3]` and
`hash((1, 2, 3)) != hash([1, 2, 3])` were both True without raising
exceptions, that would be a disaster and lead to awful bugs. The
equality/hash contract is meant to protect against that.
> I can't think of any counterexamples.
>
I think it's reasonable that this change would introduce counterexamples
where none previously existed, as we would be changing the meaning of ==.
Although since writing this Dominik gave the frozenset example.
I also think it'd be possible to have a data model where `{(1, 2, 3):
4}[[1, 2, 3]]` does work. You'd need a way to calculate a hash if you
promised to use it only for `__getitem__`, not `__setitem__`, so you can't
store list keys but you can access with them.
(this is all just fun theoretical discussion, I'm still not supporting the
proposal)
>
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/A3IOGPB56QMGO5ZAHH2WOQX5PYY3N3V7/
Code of Conduct: http://python.org/psf/codeofconduct/
