Understanding Python Object Pooling, Integer Caching, and Interning Mechanisms

A Strange Feature

During a review of Python basics, I noticed that in the interactive interpreter the expression a = 1 b = 1 a is b # true returns True , indicating that both variables point to the same integer object. The book explained that CPython creates a single int object for small integers and makes both a and b reference it, which differs from many other languages.

<code>a = 1
b = 1
a is b  # true</code>

However, the same test with floats shows different objects:

<code>a = 10.1
b = 10.1
a is b  # false</code>

Further experiments with other data types (shown in the image) reveal that int and str objects are reused, while list and float are not, suggesting that the reuse rule depends on the data type. This leads to the concept of an "object pool".

Object Pool

Integers

Python maintains a "small integer object pool" for all integers in the range [-5, 256] . When a small integer is created, Python first checks this pool; if the integer already exists, the new variable points to the existing object, which explains why a and b both reference the same 1 object.

Strings

String objects use an "interning" mechanism. The interpreter keeps a dictionary that maps created string literals (keys) to their object addresses (values). When a new string is created, Python checks this dictionary; if the string already exists, the same object is reused. Only strings shorter than 20 characters are automatically interned, as demonstrated by the following experiment:

Compilation Unit

Discussing constant object storage brings up the notion of a "compilation unit".

Background

In CPython, each function is compiled into a PyFunctionObject that contains bytecode, a constant pool, and other metadata. Top‑level code is also treated as a function, so it has its own compilation unit.

Difference Between Interactive and Script Execution

In the interactive interpreter, each line entered is compiled as a separate unit and executed immediately. If the input does not form a complete unit (e.g., a function definition), the interpreter waits until the unit is complete before compiling.

When a whole .py file is executed, the entire top‑level code forms a single compilation unit.

Constant Pool of a Compilation Unit

Each compilation unit has its own constant pool. Identical constants that appear within the same unit are stored only once, so they refer to the same runtime object.

Across different units, object identity is handled by the small‑integer pool and the string‑interning mechanism, allowing constants from separate units to sometimes point to the same object.

For example, the following script shows that two identical float literals can be the same object because they belong to the same top‑level compilation unit:

<code># Test.py
a = 10.1
b = 10.1
print(a is b)  # true</code>

In contrast, the same two assignments entered line‑by‑line in the interactive interpreter are treated as separate units, so a is b yields False .

When the two assignments are placed on the same line, they belong to the same compilation unit and thus refer to the same object:

<code>>> a = 10.1; b = 10.1;
>>> a is b
True</code>

Summary

In summary, constant objects are shared within a single compilation unit via the constant pool, while across units Python relies on the small‑integer cache and string interning to reuse immutable objects. Mutable objects such as lists or dictionaries are never shared; each creation yields a new object in memory.