Skip to content

Commit d8ede4f

Browse files
committed
Closes #13203: add a FAQ section about seemingly duplicate id()s.
1 parent 4b53259 commit d8ede4f

File tree

1 file changed

+26
-0
lines changed

1 file changed

+26
-0
lines changed

Doc/faq/programming.rst

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1599,6 +1599,32 @@ You can program the class's constructor to keep track of all instances by
15991599
keeping a list of weak references to each instance.
16001600

16011601

1602+
Why does the result of ``id()`` appear to be not unique?
1603+
--------------------------------------------------------
1604+
1605+
The :func:`id` builtin returns an integer that is guaranteed to be unique during
1606+
the lifetime of the object. Since in CPython, this is the object's memory
1607+
address, it happens frequently that after an object is deleted from memory, the
1608+
next freshly created object is allocated at the same position in memory. This
1609+
is illustrated by this example:
1610+
1611+
>>> id(1000)
1612+
13901272
1613+
>>> id(2000)
1614+
13901272
1615+
1616+
The two ids belong to different integer objects that are created before, and
1617+
deleted immediately after execution of the ``id()`` call. To be sure that
1618+
objects whose id you want to examine are still alive, create another reference
1619+
to the object:
1620+
1621+
>>> a = 1000; b = 2000
1622+
>>> id(a)
1623+
13901272
1624+
>>> id(b)
1625+
13891296
1626+
1627+
16021628
Modules
16031629
=======
16041630

0 commit comments

Comments
 (0)