Why same id() for two distinct variables with the same float value in Python 3.6.x/ 2.7.x?

Question

Try:

f1 = 2.0
f2 = 2.0
print (id(f1), id(f2), id(f1) == id(f2))
f1 = 2.0
f2 = 2.00
print (id(f1), id(f2), id(f1) == id(f2))
f1 = 2.0
f2 = 2.0 + 0
print (id(f1), id(f2), id(f1) == id(f2))

Result Python 3.6.2 (v3.6.2:5fd33b5, Jul 8 2017, 04:14:34) [MSC v.1900 32 bit (Intel)] on win32:

28901952 28901952 True
28901952 28901952 True
28901952 28903248 False

Result Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit (AMD64)]:

408502020664 408502020664 True
408502020664 408502020664 True
408502020664 408502019104 False

Result ('2.7.13 (default, Jun 26 2017, 10:20:05) \n[GCC 7.1.1 20170622 (Red Hat 7.1.1-3)]', sys.version_info(major=2, minor=7, micro=13, releaselevel='final', serial=0)):

(140026865510064, 140026865510064, True)
(140026865510064, 140026865510064, True)
(140026865510064, 140026865509968, False)

Why are ids from floats identical? What happens behind the scenes (something like preserved integer objects in range -5 to 256?)?

Have you looked at the bytecode? I would guess 2.0 becomes a float constant and then all hardcoded 2.0 refer to that. You could try asking for user input and entering 2.0, then I'd wager they're different ids. — dutt, Jan 26 '18 at 11:22
This is clearly implementation dependant, I get `False` for all 3 with Py 2 and Py 3 on my machine — Chris_Rands, Jan 26 '18 at 11:25
@Coldspeed not exactly a dupe, if they are asking about the implementation details — Chris_Rands, Jan 26 '18 at 11:27
Could you please [edit] your question to indicate which precise Python version on which precise platform you are using? I too get False on Python 3.5.1 (Homebrew) and the system-supplied Python 2.7.11 on MacOS High Sierra. — tripleee, Jan 26 '18 at 11:55
sorry, no reuse memory positions: two float vars, same value and same id at the same time - No Duplicate — V. E., Jan 26 '18 at 12:29
simply put it in codingground : Execute Python Online (Python v2.7.13) shows same results — V. E., Jan 26 '18 at 12:48
see: http://www.tutorialspoint.com/execute_python_online.php?PID=1I2Gi9kv0cq4ePt30nJOvN-D-UgdLmUAf — V. E., Jan 26 '18 at 13:04

score 1 · Accepted Answer · answered Jan 26 '18 at 15:03

This only happens if the code is compiled/translated into bytecode, and not interpreted in a REPL (although some interpreter my also show this behavior). Consider the following function:

def fn():
    f1 = 2.0
    f2 = 2.0
    return f1, f2

When this function gets compiled into bytecode, the literal 2.0 becomes a local constant of the function fn. Python is smart enough to see that the first 2.0 is the same as the second 2.0 so it gets stored only once. At runtime, the function will load the constant from the function's co_consts and store it in f1 and f2 respectively. This is why f1 and f2 have the same id: They are references to the same constant.

>>> f1, f2 = fn()
>>> f1 is fn.__code__.co_consts[1]
True
>>> f2 is fn.__code__.co_consts[1]
True

2.0 + 0 does not have the same id because the original constant 2.0 is immutable and Python does not just skip the (otherwise idempotent) addition. The result of the addition, therefore, has to be a new object, hence a different id.

Why same id() for two distinct variables with the same float value in Python 3.6.x/ 2.7.x?

1 Answers1