Result of ``a is b''

[Asun Friere]

axelboldt at yahoo.com (Axel Boldt) wrote in message news:<40200384.0403180514.341fe3b0 at posting.google.com>...
> Probably because basic built-in strings form a type
> that's not a class and you can't inherit from it.

You sure can!  (Providing, of course your python is >= 2.2)  Try this:

class MyString (str) : 
    pass
foo = MyString('the things you can do in python!')
foo.__class__ is MyString
isinstance(foo, str)
MyString.mro()

> > For instance I might have a class 'Name', in a names database, which
> > is a specialised string.  In this case '==' function looks to the
> > contents of the strings being compared, while 'is' tells me whether
> > these two strings are the same object.  Thus "if name0 == name1 and
> > not name0 is name1" will tell me that I am dealing with a duplicate
> > record.  
> 
> If you make Name a class that contains a string as a data attribute ...

Now you know the above all this is irrelevant, yes?  I mean
composition may be a valid strategy, but it doesn't really address the
question, of how your proposed changes would affect inheritence.

The problem with my example (well it's probably a problem with the
Python definition :P), is that while you could be pretty sure that the
condition "if name0 == name1 and not name0 is name1" indicates a
duplicate, its facility to find /all/ duplicates is implementation
dependent (ie it works because only built-in types like 'int' and
'str' are 'cached' to the same objects, and programmer defined classes
such as 'Name' or 'MyString' are not).  Which leads to my next point
...



> 
> > a program in which a large (or at least
> > important) part of the logic was contained in the __eq__ method to the
> > class you created 
> 

It might be instructive to play with the difference between identity
and equivalence in the abstract.  What I mean is this, imagine that
'is' really means 'is' rather the 'is located at.'  Given the current
implementation (and probably any future implementation), one can do
this, bearing in mind the caveat that special considerations apply
with regard to some built-in types.

Doing so might lead to an appreciation the power of this distinction
in an abstract OO context, which in turn might lead towards advocating
a very different kind of change to the meaning of 'is.'  Rather than
inconsistently conflating the concept of identity with equivalence
(which imo your proposal does), one might argue for a guarantee that
an implementation /never/ cache different instances of a programmer
created class to the same memory location.

> > I mean you wouldn't really be in a
> > situation to advocate a redefinition of the identity/equivalence
> > relationship unless you had, would you?
> 
> Why not?

Because you would be advocating a change to an aspect of the language
you don't use, but which other programmers do.