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