# Python Integer Caching: Why 256 is 256 but 257 is Not

**Why does `256 is 256` evaluate to `True`, but `257 is 257` return `False`? Python pre-allocates small integer objects (traditionally -5 to 256) inside a global array to save memory. Because this optimization is version-dependent, using the `is` operator for numeric comparisons introduces subtle, breaking bugs.**

Run `a = 256; b = 256; a is b` in your Python REPL, and it returns `True`. Run `x = 257; y = 257; x is y` on separate lines, and it returns `False`. This behavior isn't a glitch—it is a direct consequence of how CPython optimizes memory allocation for low-value integers.

Understanding the mechanics of this behavior requires looking beneath Python's high-level syntax and into CPython's memory management.

## How does CPython optimize small integers under the hood?

CPython pre-allocates a static array of integer objects for values between `-5` and `256` (inclusive) during interpreter initialization. When you assign one of these values, CPython returns a pointer to the pre-existing object rather than allocating new memory on the heap.

In CPython, integers are not lightweight, 8-byte primitive types like they are in C or C++. Instead, they are defined as `PyLongObject` structures. Every `PyLongObject` contains metadata inherited from the base `PyObject` structure, including:

*   `ob_refcnt`: An 8-byte reference counter used for garbage collection.
*   `ob_type`: An 8-byte pointer to the type object (`&PyLong_Type`).
*   `ob_size`: An 8-byte signed integer indicating the size of the digit array.

On a 64-bit system, this structural overhead means even the integer `0` consumes 24 to 28 bytes of memory. Constantly allocating and deallocating these structures for basic loop counters or arithmetic operations would cause massive heap fragmentation and CPU overhead.

To mitigate this, CPython's source code (specifically in `Objects/longobject.c`) defines an array named `small_ints`. During startup, CPython initializes this array with `PyLongObject` instances for every number from `-5` up to `256`. 

## Why does the "is" operator fail on larger numbers?

The `is` operator evaluates object identity by comparing memory addresses directly, whereas `==` evaluates value equality by invoking the object's comparison method. For integers outside the cached range, CPython allocates distinct heap memory addresses, causing `is` to return `False` even if the values are identical.

When you assign a number outside the `small_ints` range (such as `257`) across separate lines in the interactive REPL, the CPython runtime cannot reuse a cached instance. It calls `PyLong_FromLong()`, which invokes `_PyObject_New` to allocate a completely new `PyLongObject` on the heap.

As a result, the variables point to two entirely different addresses in virtual memory. The `is` operator checks if the raw pointer values are equal. Because these pointers point to distinct heap allocations, the identity check fails, even though the underlying numeric values match.

## How does Python 3.15 change integer caching behavior?

Starting in Python 3.15, CPython is raising the small integer caching threshold from `256` up to `1024`. This means that expressions like `1000 is 1000` will evaluate to `True` in Python 3.15, whereas they evaluated to `False` in all prior versions.

This upcoming adjustment highlights why relying on the `is` operator for value comparison is a dangerous anti-pattern. The boundaries of the `small_ints` array are internal implementation details, not part of the Python language specification. 

If you write code that accidentally relies on this cache, your application might pass its tests locally on a newer Python interpreter but fail silently when deployed to a production environment running an older version of CPython.

| Python Version | `256 is 256` | `257 is 257` | `1024 is 1024` | Safe Comparison Operator |
| :--- | :--- | :--- | :--- | :--- |
| **Python 3.12 and older** | `True` | `False` | `False` | `==` |
| **Python 3.15+** | `True` | `True` | `True` | `==` |

## FAQ

### Why does CPython's cache start exactly at -5?
CPython starts the cache at `-5` because low-value negative numbers are frequently used as index offsets (such as accessing lists from the end with `-1`) and error-state sentinel values in C-API integrations.

### Does CPython optimize string objects using a similar mechanism?
Yes, CPython uses a process called "string interning" for short, ASCII-only strings that look like Python identifiers. This is handled via the `sys.intern()` function and internal dictionary keys, allowing the interpreter to perform fast pointer comparisons instead of expensive character-by-character string comparisons.

### Why do two large identical numbers sometimes return True for "is" inside a script?
When Python compiles a single script file or module, the compiler processes entire code blocks at once. During this compilation phase, CPython performs constant folding and merges identical literals within the same code object's constant pool (`co_consts`), causing them to share the same memory allocation.