Dennis Lee Bieber wrote:
On Tue, 11 Aug 2009 17:54:36 -0700, James Stroud <jstr...@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


--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to