hashability

[James Stroud]

Dennis Lee Bieber wrote:
> On Tue, 11 Aug 2009 17:54:36 -0700, James Stroud <jstroud at mbi.ucla.edu>
> declaimed the following in gmane.comp.python.general:
> 
>>    ...
>>    py> {C():4}[C()]
>>    ------------------------------------------------------------
>>    Traceback (most recent call last):
>>      File "<ipython console>", line 1, in <module>
>>    <type 'exceptions.KeyError'>: <__main__.C object at 0xe21610>
>>
>> The basis for the exception is that the two instances do not have the 
>> same hash() although conceptually they might seem equal to the 
>> unitiated. Were I to re-design python, I'd throw an exception in this 
>> case because of the ill-defined behavior one might expect if a C() 
>> serves as a key for a dict.
>>
> 	"A" C()... How would you expect
> 
> c1 = C()
> c2 = C()
> 
> {c1:4}[c2] 
> 
> to behave?


This seems like a subjective question. I think I demonstrated how it 
*does* behave, which is purely objective--and I know I can't do anything 
about that. But the subjective answer to the subjective question is that 
I would like an exception to be raised when the dictionary is 
constructed. I know an exception doesn't get thrown in the current 
incarnation of the python language. That is the objective reality of the 
situation which affronts my subjective notions of how reality should be.

That IS the equivalent of your statement -- two instances are
> two distinctly different entities...

Tell that to two different machines on two different days. Then bet the 
life of yourself and your nearest and dearest family on that fact and 
see whether you really want to take a hash value for granted. If a 
property of the python language fails the "bet the lives of your nearest 
and dearest on a consistent result" test, I call it "ill defined" and, 
subjectively speaking, I prefer exceptions to be thrown--And, by damned, 
I'll throw them myself if I have to.

"If it saves one life, it's worth it all."

James