what is the keyword "is" for?

[daniel]

I'm so confused by the keyword "is" and "==" equal sign, it seems they
could be exchanged in some contexts, but not in others, what's the
difference between them in terms of comparation?

thanks...

daniel

[Kirk McDonald]

daniel wrote:

I'm so confused by the keyword "is" and "==" equal sign, it seems they
could be exchanged in some contexts, but not in others, what's the
difference between them in terms of comparation?

thanks...

daniel

'is' compares object identity. == compares values.

>>a = [1, 2, 3]
b = [1, 2, 3]
a is b

False

>>a == b

True

In this example, a and b refer to two separate lists that happen to hold
the same values. Thus, 'is' returns False, and == returns True. On the
other hand:

>>c = d = [4, 5, 6]
c is d

True

>>c == d

True

Here, c and d refer to the same list. Therefore, 'is' returns true (they
both refer to the same object), as does == (an object is always equal to
itself, unless you overload the equality check in a weird way).

The distinction can easily be seen if we try to mutate these lists:

>>a.append(4)
a is b

False

>>a == b

False

>>c.append(7)
c is d

True

>>c == d

True

When we mutate a, b is not affected. They are two different lists, and
changing 'a' makes it so they are no longer equal.

When we mutate c, d IS affected; they refer to the same list.

You can easily confuse yourself if you ever talk about applying 'is' to
(for example) integers. Python may re-use certain small integers when
you might not expect it to; this is done in the interests of efficiency.
If you only compare the /values/ of numbers (with ==), then you will
never notice this.

>>a = 1
b = 1
c = 1000000
d = 1000000
a is b

True

>>c is d

False

-Kirk McDonald

[daniel]

many thanks to Sybren and Kirk for your helpful explanation.

when I tried to check the stuff out, found sth interesting that if you
define variables in a style like this:
a = b = ['a', 'b']
changing one list affects the other, and they still refer to same
object. in fact, seems all compound types (dictionary for instance)
behave in this way.

however, when list is replaced with other built-in types like integers
:
a = b = 3
changing one of them cause the two objects differ...
best regards.

daniel

[Martin v. Löwis]

daniel wrote:

when I tried to check the stuff out, found sth interesting that if you
define variables in a style like this:
a = b = ['a', 'b']
changing one list affects the other, and they still refer to same
object. in fact, seems all compound types (dictionary for instance)
behave in this way.

however, when list is replaced with other built-in types like integers
:
a = b = 3
changing one of them cause the two objects differ...

Ah, but make a difference between "change a variable", and "change an
object".

pya = b = [1,2,3]
pya[0] = 6 # don't change the variable a, just change the object
pya
[6, 2, 3]
pyb
[6, 2, 3]
pya=[7,8,9] # change the variable a;
# it's now a different object than b
pya
[7, 8, 9]
pyb
[6, 2, 3]

For some objects, "change the object" is impossible. If you have

a = b = 3

then there is no way to change the object 3 to become 4 (say);
integer objects are "immutable" . So for these, to make a change,
you really have to change the variable, not the value.

Regards,
Martin

[daniel]

Martin v. Löwis wrote:

daniel wrote:

when I tried to check the stuff out, found sth interesting that if you
define variables in a style like this:
a = b = ['a', 'b']
changing one list affects the other, and they still refer to same
object. in fact, seems all compound types (dictionary for instance)
behave in this way.

however, when list is replaced with other built-in types like integers
:
a = b = 3
changing one of them cause the two objects differ...

Ah, but make a difference between "change a variable", and "change an
object".

pya = b = [1,2,3]
pya[0] = 6 # don't change the variable a, just change the object
pya
[6, 2, 3]
pyb
[6, 2, 3]
pya=[7,8,9] # change the variable a;
# it's now a different object than b

mm, python runtime might allocate a new chunk of memory for this... but
might not for the previous operation..

pya
[7, 8, 9]
pyb
[6, 2, 3]

For some objects, "change the object" is impossible. If you have

a = b = 3

then there is no way to change the object 3 to become 4 (say);
integer objects are "immutable" . So for these, to make a change,
you really have to change the variable, not the value.

sounds reasonable, I tried tuple which is also immutable, it behaves
the same as integers.

Regards,
Martin

tks Martin...

[Steve Holden]

daniel wrote:

Martin v. Löwis wrote:

[...]

>>For some objects, "change the object" is impossible. If you have

a = b = 3

then there is no way to change the object 3 to become 4 (say);
integer objects are "immutable" . So for these, to make a change,
you really have to change the variable, not the value.

sounds reasonable, I tried tuple which is also immutable, it behaves
the same as integers.

Well spotted. Tuples are indeed immutable, as are strings, unicode
strings, integers and floats.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Terry Reedy]

"Sybren Stuvel" <sy*******@YOUR thirdtower.com. imaginationwrot e in message
news:sl******** **************@ schuimige.stuve l.eu...

'is' compares the object's addresses.

It actually compares the objects' integer identifiers. That happens to be
the linear memory address for CPython, but not necesarily so for other
interpreters.

tjr

[Dan Bishop]

Sybren Stuvel wrote [on the difference between is and ==]:

Obviously "a is b" implies "a == b",

Not necessarily.

>>a = b = 1e1000 / 1e1000
a is b

True

>>a == b

False

[Dan Bishop]

Steve Holden wrote:

daniel wrote:

Martin v. Löwis wrote:

[...]

>For some objects, "change the object" is impossible. If you have

a = b = 3

then there is no way to change the object 3 to become 4 (say);
integer objects are "immutable" . So for these, to make a change,
you really have to change the variable, not the value.

sounds reasonable, I tried tuple which is also immutable, it behaves
the same as integers.

Well spotted. Tuples are indeed immutable, as are strings, unicode
strings, integers and floats.

But tuples can contain mutable objects.

>>a = (0, [1])
a[1].append(2)
a

(0, [1, 2])

[Hendrik van Rooyen]

"Dan Bishop" <da*****@yahoo. comwrote:
| Sybren Stuvel wrote [on the difference between is and ==]:
| Obviously "a is b" implies "a == b",
|
| Not necessarily.
|
| >>a = b = 1e1000 / 1e1000
| >>a is b
| True
| >>a == b
| False

Huh? - wtf is this - I find this deeply disturbing - Sybren's explanation kind
of was congruent with my own understanding, and this is just weird - Hendrik