Dict when defining not returning multi value key error
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Fri Aug 1 09:31:40 EDT 2014
On Fri, 01 Aug 2014 14:17:41 +1000, Ben Finney wrote:
> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>
>> On Thu, 31 Jul 2014 20:12:12 -0700, Dan Stromberg wrote:
>>
>> > I removed some quotes, and noticed that 1 and 1.0 hash the same.
>> > That's a bit unexpected, but I suppose it's not completely
>> > unreasonable.
>
> I would expect it, for the reasons Steven explains. Why is it
> unexpected?
>
>> You should expect that two equal objects should hash to the same value
>> in different versions of Python, or even from one run of Python to the
>> next.
>
> I suspect there's a “not” missing there.
Thanks for spotting that. Correct, I meant that you should *not* expect
hashing to return any specific value.
[...]
> If you expect the hash valuesto be the same, you're making a mistake; if
> you expect the hash values to be different, you're making a mistake.
Yes. Although Python promises (at least for classes in the standard
library) that x == y should imply that hash(x) == hash(y), it says
nothing about the other way:
x == y implies that hash(x) == hash(y)
but hash(x) == hash(y) does NOT imply that x == y.
py> hash(2**128) == hash(1)
True
> The correct attitude, with regard to implementation details, is to
> expect uncertainty and not assume anything :-)
Yes, this!
--
Steven
More information about the Python-list
mailing list