The code "python" is "python" returns True. But why does (1,2,3) is (1,2,3) return False? Even though both are immutable objects, the is operator is evaluating differently. Why?
Asked
Active
Viewed 104 times
0
jonrsharpe
- 115,751
- 26
- 228
- 437
samba
- 869
- 4
- 12
- 20
-
`is` has nothing to do with immutability. – simonzack Oct 04 '14 at 08:07
-
The first example is what you might call local interning of constants in a code block, [courtesy of the compiler](https://hg.python.org/cpython/file/c0e311e010fc/Python/compile.c#l1075) (line 1124; the dict in this case is for building `co_consts`). This is separate from global string and integer interning, i.e. `'1 2 3'` is not interned, but `'1 2 3' is '1 2 3'`. Similarly `1234567 is 1234567` even though CPython globally interns only up to 256. Also, `1.23456 is 1.23456`. – Eryk Sun Oct 04 '14 at 12:58
-
@eryksun you should write that up as an answer – jonrsharpe Oct 04 '14 at 13:25
-
The tuple case is handled differently. `BUILD_TUPLE` creates a tuple at runtime, which isn't necessarily of constants. That said, the [peephole optimizer](https://hg.python.org/cpython/file/c0e311e010fc/Python/peephole.c#l84) does add tuples of constants into `co_consts`. It just doesn't eliminate dupes. For example, `compile('(1,2,3) is (1,2,3)', '', 'exec').co_consts == (1, 2, 3, None, (1, 2, 3), (1, 2, 3))`. The first pass has two `BUILD_TUPLE` ops. The optimization pass replaces them with `LOAD_CONST` ops that load the tuples from `co_consts`. – Eryk Sun Oct 04 '14 at 13:26
4 Answers
1
The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value.
you can think of identity as the object’s address in memory. so for 2 tuple with same index we have different address ! and in this case based on your interpreter and above stuff in your interpreter equal strings point to one memory address
for better understanding see the below Demo:
>>> a=(0,1)
>>> b=a
>>> a is b
True
>>> c=(0,1)
>>> a is c
False
Mazdak
- 105,000
- 18
- 159
- 188
-
+1 Good answer. You might go on to explain that it works the same for both mutable and immutable objects. – John1024 Oct 04 '14 at 08:17
-
Because it doesn't answer the question. Your demonstrations are not equivalent to the OP's code. Tuples and strings are both immutable, so why do they behave differently? – jonrsharpe Oct 04 '14 at 08:19
-
-
Please don't think of Python object identity as the address in memory. That only applies to CPython, for which it suffices because CPython objects are heap allocated and never move in memory. – Eryk Sun Oct 04 '14 at 18:04
-
0
is returns True if both operands refer to the same object. The interpreter can use interning for immutable objects, but it is not guaranteed to.
kraskevich
- 18,368
- 4
- 33
- 45
0
The only reason your first example is True is that string literals are interned when loaded from source code (I think this only applies to strings within a single file even).
In nearly all cases other than string literals, objects created at different times will have different IDs.
o11c
- 15,265
- 4
- 50
- 75
0
In case there's any doubt, X is Y checks whether X and Y refer to the same object. It does not check whether the two objects are equal.
Now to your question:
You should generally not have any expectations about whether A is A returns True or False for the given literal A.
We know quite well how CPython works internally, so we can explain why each particular case behaves the way it does. That said, other than in some truly exceptional circumstances, its best to treat this as an implementation detail. It can well behave differently in a different Python interpreter, or indeed in a different version of CPython.
Of course, this doesn't mean that is is not useful. It is, just not in this case.
