Result of ``a is b''

[Axel Boldt]

afriere at yahoo.co.uk (Asun Friere) wrote 
> axelboldt at yahoo.com (Axel Boldt) wrote

> >                                      Why would anybody ever want to
> > know whether two strings or tupels are internally stored at the same
> > location, other than to deduce details of the Python implementation?
> 
> Most obviously to tell whether they are the same object or not.  
> While this is not an issue with simple strings, have you considered
> what effect your suggestions would have on classes inheriting from
> str?

Indeed I have not. Probably because basic built-in strings form a type
that's not a class and you can't inherit from it.

> 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,
then "is" on Name objects will work as always, since Names aren't
immutable. To test whether you have duplicates, you can use "is" on
Names.

Now, rather than test "is" on Name objects, one could be tempted to
test "is" on the string attributes instead. Note that sometimes
strings created by completely different parts of a program compare as
"is-identical". Sometimes they don't, even though they are "==-equal".
It's implementation dependent. Name is broken. My proposal would
eliminate this very programming mistake.

> By the way you /have/ written 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, haven't you?  

No.

> 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?

Axel