Why and how does the Python interpreter remember literal objects

Question

I am surprised by the following result, using Python 2.7.4:

>>> id(5)
5068376

>>> id(5)
5068376

When the expression 5 is evaluated, a new object is created with the identity of 5068376. Now, I would expect that repeating the same statement would create another new object, whose identity would be unique, since simply evaluating an expression doesn't yield any references to the object and the object should be garbage collected.

It's not that the interpreter is reusing the same memory address either:

>>> id(6)
5068364

>>> id(5)
5068376

So what gives? Does the interpreter do behind-the-scenes binding of literals?

related : http://stackoverflow.com/questions/11476190/why-0-6-is-6-false — Ashwini Chaudhary, Apr 24 '13 at 17:44
@AshwiniChaudhary: You may want to summarize and post as an answer since that answers the question. — Guvante, Apr 24 '13 at 17:44
See also: http://stackoverflow.com/questions/306313/python-is-operator-behaves-unexpectedly-with-integers — Mark Hildreth, Apr 24 '13 at 17:46
@Guvante: why would he do that? Voting to close as duplicate is the correct course of action. No need to rephrase existing answers from another question here. — Wooble, Apr 24 '13 at 17:51
@Wooble: Because while the answer is the same, I could not tell if the question was the same. I don't recognize `id` versus `is` so didn't want to claim duplicate. — Guvante, Apr 24 '13 at 20:54

score 5 · Accepted Answer · answered Apr 24 '13 at 17:44

5

There's a range of small numbers that are kept as singletons within Python; any reference will always return the same object and they will never be garbage collected.

>>> for x,y in enumerate(range(1000)):
    if x is not y:
        print x,y
        break

257 257

answered Apr 24 '13 at 17:44

Mark Ransom

299,747
42
398
622

To clarify, the reason for this is because otherwise there'd be annoyingly large performance hits for things like `1+2` – daniel gratzer Apr 24 '13 at 17:45
1

Got it, thanks for the quick response. There really ought to be a mention of this in the Python data model documentation. – Sharp3 Apr 24 '13 at 17:47
4

@Sharp3, it's an implementation detail, subject to change at any time. You really shouldn't care whether you get the same object or not. – Mark Ransom Apr 24 '13 at 17:48
Congrats on hitting the big 100K! :-) – Martijn Pieters Apr 24 '13 at 23:24
@MartijnPieters, thanks! And congratulations on beating me to it! – Mark Ransom Apr 25 '13 at 00:31

Martijn Pieters · Answer 2 · 2013-04-24T18:08:24.960

There are 2 things going on here:

Small Python integers (from -5 to 256 inclusive) are interned; a literal integer is translated into the exact same object for the same number. For these integers their id() is going to be constant.
The id() is only unique for the lifetime of the object; it can be reused later on for another object if the first object has been cleared again. You don't store your literals anywhere, so the memory address can be reused again:
```
>>> id('foo bar')
4572936304
>>> id('bar baz')
4572936304
```
Here 'foo bar' and 'bar baz' are two distinct objects, but their lifetimes do not overlap. The first is created, passed to the id() function, then destroyed again. Then the second string is created, passed to id() and destroyed in turn.

Why and how does the Python interpreter remember literal objects

2 Answers2