Result of ``a is b''

[Ronald Oussoren]

Re: Result of ``a is b''


On 18-mrt-04, at 14:14, Axel Boldt wrote:
[color=blue]
> afriere@yahoo.c o.uk (Asun Friere) wrote[color=green]
>> axelboldt@yahoo .com (Axel Boldt) wrote[/color]
>[color=green][color=darkred]
>>> 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?[/color]
>>
>> 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?[/color]
>
> 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.[/color]

Yes you can:

Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright" , "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> class MyStr(str): pass[/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> x = MyStr("hello")
>>> type(x)[/color][/color][/color]
<class '__main__.MyStr '>[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

[Terry Reedy]

Re: Result of ``a is b''

For what it's worth: the idea of changing the meaning of 'is' been
discussed on the PyDev (development) list for a couple of days. GvR posted
this a few hours ago ('the code' refers to an example misusing 'is'):

"I'm ready to pronounce. The code is buggy. There are good reasons to
keep 'is' the way it always was. The definition of 'is' ain't gonna
change. So be it"

Terry J. Reedy

[Axel Boldt]

Re: Result of ``a is b''

"DomF" <fidtz@clara#sp am#.co.uk> wrote in message news:<107962963 8.19728.0@lotis .uk.clara.net>. ..[color=blue][color=green]
> > 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.
> >[/color]
> Mostly because I am interested in the counter argument:
>
> class mynewstr(str):
> ... pass
> ...[color=green][color=darkred]
> >>> s = mynewstr()
> >>> dir(s)[/color][/color]
> <<list of str stuff>>[/color]

I stand corrected, I don't think there is a counter argument. So then
the objection of Asun Friere remains: could a redefinition of "is" for
strings affect the behavior of classes derived from str? I don't know.

Axel

[Asun Friere]

Re: Result of ``a is b''

axelboldt@yahoo .com (Axel Boldt) wrote in message news:<40200384. 0403180514.341f e3b0@posting.go ogle.com>...[color=blue]
> Probably because basic built-in strings form a type
> that's not a class and you can't inherit from it.[/color]

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()
[color=blue][color=green]
> > 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.[/color]
>
> If you make Name a class that contains a string as a data attribute ...[/color]

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


[color=blue]
>[color=green]
> > 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[/color]
>[/color]

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.
[color=blue][color=green]
> > I mean you wouldn't really be in a
> > situation to advocate a redefinition of the identity/equivalence
> > relationship unless you had, would you?[/color]
>
> Why not?[/color]

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