Result of ``a is b''

Asun Friere afriere at yahoo.co.uk
Fri Mar 19 01:30:45 EST 2004


Steve <dippyd at yahoo.com.au> wrote in message news:<405A5EC9.6010503 at yahoo.com.au>...
> Asun Friere wrote:
> 
> > In fact __eq__ can be redefined even /so as to be an equivalence
> > relation/ such that x==y => True and x is y => False.  The
> > 'fundamental properties' posisted, are simply not fundamental.
> 
> I think you have mis-read those fundamental properties. 
> They were:
> 
> (1) If x and y refer to the same object, "x is y" 
> yields True.
> 
> (2) If "x is y" yields True, "x==y" also yields True. 
> Equivalently, if "x==y" yields False, "x is y" also 
> yields False.
> 
> Property (2) assumes that __eq__ implements an 
> equivalence relation.
> 
> Notice that your objection that x==y returns True and x 
> is y returns False is *not* one of those properties.

You're right I did misread them.  Mea culpa!

> I don't think the argument that one can redefine __eq__ 
> to be something other than an equivalence relation is a 
> particularly strong argument. I would call that a bug, 
> even if it is a deliberate bug. If "==" doesn't do 
> equality, then it is an exceedingly bad piece of design.

I don't think you can call the intended and and expected behaviour of
a program a 'bug.'  On the other hand, apart from trying to show that
these properties are not truely 'fundamental,' I find it difficult to
conceive of a useful application of this kind of redefinition of the
equivalence function.  So yes, we should expect that identical objects
also to be equivalent.

In any case, now that you brought me back to what Andrew Koenig
actually wrote, I accept his propositions should hold true when __eq__
implements what could justifiably be called an equivalence function,
whether they are rightly called 'fundamental' or not.



More information about the Python-list mailing list