Surprise using the 'is' operator

[codefire]

I thought the 'is' operator was used to identify identical objects,
whereas the '==' operator checked equality. Well, I got a surprise
here:

IDLE 1.1.3
I was NOT expecting the last statement to return True!

What am I missing?

Thanks
Tony

 

[Diez B. Roggisch]

I thought the 'is' operator was used to identify identical objects,
whereas the '==' operator checked equality. Well, I got a surprise
here:

IDLE 1.1.3

I was NOT expecting the last statement to return True!

What am I missing?

One of the most severely beaten dead horses of python - small integers are
cached by the interpreter. Maybe. Thus the above results.

Google for a bazillion discussions on this.

Diez

 

[Christophe]

codefire a écrit :

I thought the 'is' operator was used to identify identical objects,
whereas the '==' operator checked equality. Well, I got a surprise
here:

IDLE 1.1.3
True

I was NOT expecting the last statement to return True!

The answer is : Why not? Does it even matter for integers? Never use
"is" on integers, always == ( and on strings too for that matter )

 

[codefire]

Haha!

OK thanks guys.

I was just trying to check if objects were the same (object), didn't
know Integers were a special case.

Thanks,
Tony

 

[Fredrik Lundh]

I was just trying to check if objects were the same (object), didn't
know Integers were a special case.

they're not, really; "is" works the same way for all objects.

when you ask for a new immutable object, a Python implementation may
always reuse an existing object, if it wants to.

the CPython implementation does this for small integers, booleans, None,
empty tuples, certain strings, type objects, etc. this also applies to
library code; for example, string methods often return a reference to
"self" if the method didn't actually change anything.

</F>

 

[codefire]

Thanks for that Fredrik, that's clear. That's actually a pretty nice
feature as it's nicely optimised.

Cheers,
Tony

 

[Christophe]

codefire a écrit :

Haha!

OK thanks guys.

I was just trying to check if objects were the same (object), didn't
know Integers were a special case.

They are not a special case so much. It's just that "is" is extremly
unreliable unless you're the one who created the objects. In the case of
integers, it's the CPython implementation which constructs them as it
sees fit and so, you cannot expect any kind of reliable "is" behavior.

When you are manipulating let's say lists, it gets much more reliable.
You do know that the list you create by doing a = [] is not and will
never be the same than the one you'll create later by doing b = []

 

[Ben Finney]

I was just trying to check if objects were the same (object), didn't
know Integers were a special case.

They're not. The Python runtime environment can do whatever it likes
underneath the hood; the language gives no promises about any
relationship between 'is' and '=='.

What you may be missing is that 'c = 10' is not "putting the value 10
into the box named c". It is rather "putting the label c onto the
object 10".

Whether there are one, two or twelve instances of an object '10' is
entirely up to the Python runtime implementation. You can use 'is' to
check whether two objects are identical; you can use '==' to check
whether they are equal in value; you cannot generalise anything about
the relationship between those two.

 

[Antoon Pardon]

they're not, really; "is" works the same way for all objects.

when you ask for a new immutable object, a Python implementation may
always reuse an existing object, if it wants to.

the CPython implementation does this for small integers, booleans, None,
empty tuples, certain strings, type objects, etc. this also applies to
library code; for example, string methods often return a reference to
"self" if the method didn't actually change anything.

I find this a bit oddly worded. Now the "may always reuse" phrase
suggests this is not an obligation and I can certainly understand
that in the case of integers. But when you enumerate examples you
include None and Booleans, creating the suggestion these don't
have to be implemented as singletons either and that there can be
more than one None, True and False object. Now I probably just
misunderstand, but I'm wondering, is there somewhere in the language
reference that specifies these have to be singletons?

 

[John Roth]

I find this a bit oddly worded. Now the "may always reuse" phrase
suggests this is not an obligation and I can certainly understand
that in the case of integers. But when you enumerate examples you
include None and Booleans, creating the suggestion these don't
have to be implemented as singletons either and that there can be
more than one None, True and False object. Now I probably just
misunderstand, but I'm wondering, is there somewhere in the language
reference that specifies these have to be singletons?

Yes. The topic "The standard Type Hierarchy" in the
Language reference specifies this exactly.

John Roth

 

[Antoon Pardon]

Yes. The topic "The standard Type Hierarchy" in the
Language reference specifies this exactly.

Thank you very much.