sameness/identity

[chajadan]

I've been watching this thread, and I'm a little confused as to the momentum.

As I see it, there are only two qualities of 'sameness': equality and identity.

1 + 2 = 3

1 plus 2 equals 3
1 plus 2 is not 3

Equals just means holds the same value. But nothing can be something else. Just equal to it.

If you say 3 is 3, in the sense that there is only one 3 in existance, then you are right.

If you add a level of abstraction, and say x = 3 and y = 3, now is that 3 and the other 3 the same?

Well, in the one sense, there is only one three ever in the universe. While in another you now have two attributes, x's 3 and y's 3. The attributes themselves are equal, but they are not the same attribute, for one attribute is x's and the other is y's. The attributes are both represented by the universal idea of "3", but no matter what, x's attribute is not y's. If you're asking is 3 3? Then that's funny, because that's like asking am I me?

So I'm left with only 2 forms of sameness, though I do understand the 3 types of identity.

So what exactly was the "==/is" description of things lacking for you?

--chajadan

---------- Original Message ----------------------------------
From: "John Roth" <johnroth at ameritech.net>
Date:  Sun, 30 Sep 2001 19:26:25 -0700

>
>"Greg Weeks" <weeks at vitus.scs.agilent.com> wrote in message
>news:1001876090.367103 at cswreg.cos.agilent.com...
>> I said in an earlier note that I didn't want to get into the whole issue
>of
>> "sameness" and how Python "got it wrong".  Well, I changed my mind.  I'll
>> first admit that "got it wrong" is a poor choice of words.  Allow me to
>> explain what I meant.
>>
>> Consider:
>>
>>     x = 6.02
>>     y = 6.02
>>
>> Are x and y identical?  They are identical as *numbers* (which I'll call
>> conceptual identity) but not as Python *implentations* of numbers (since
>> id(x) != id(y)).  Good programming style requires us to think of numbers
>> primarily as numbers and not as their implementations.  So we are more
>> interested in conceptual identity than in implementation identity.
>>
>> Now consider a simple Bank_account class:
>>
>>     class Bank_account:
>> def __init__(me, initial_balance):
>>     me.balance = initial_balance
>> def deposit(me, amount):
>>     me.balance += amount
>> def withdraw(me, amount):
>>     me.balance -= amount
>> def get_balance(me):
>>     return  me.balance
>>
>>     my_bank_account = Bank_account(100)
>>     your_bank_account = Bank_account(100)
>>
>> Are the two bank accounts the same bank account?  No.
><rest of discussion snipped>
>
>I think you're confusing yourself here. If I was doing a bank account
>program, I'd expect that there was at most one instance of the
>bank account class active for a given bank, department and
>account. More than that and you risk all sorts of update anomalies.
>
>In this case, 'is' is what you need. You can make == work like
>is, and I probably would just to insure that I didn't accidentally
>introduce errors (and also because I need to provide ordering
>operators for report sorting, etc.)
>
>I suspect that one of the design criteria for a well-formed design
>is that there be some kind of identification method to tell whether
>instances refer to the same conceptual object. The '=='
>operator on a class should implement that method. 'is' only works
>if the 'at most one instance per conceptual object' rule is followed.
>
>John Roth
>
>>
>> Greg
>
>
>-- 
>http://mail.python.org/mailman/listinfo/python-list
>