Why does `sys.getrefcount(None)` return a huge constant on CPython 3.14?

## The observation ```python import sys print(sys.getrefcount(None)) # 3221225472 on a 64-bit CPython 3.14 build n = None print(sys.getrefcount(None)) # unchanged ``` The number is not an overflow and not a bug. It is a **sentinel**, and the fact that it never moves when you bind another name to `None` is the point. ## Immortal objects, PEP 683, CPython 3.12 A handful of objects are guaranteed to exist for the lifetime of the interpreter: `None`, `True`, `False`, `Ellipsis`, `NotImplemented`, the empty tuple, and a set of other statically allocated singletons. Before 3.12 they were reference-counted like everything else, even though the count could never usefully reach zero. **PEP 683, shipped in 3.12, marks such objects immortal:** their count field is initialised to a special large value, and the interpreter's increment and decrement operations check for that value and do nothing. The object can therefore never be deallocated, and its counter never changes — which is exactly what `sys.getrefcount` faithfully reports back. ## Why anyone bothered The change looks cosmetic and is not. Reference counting *writes* to the object header on every acquire and release, and `None` is touched constantly by every piece of running code. That created two real costs: **Copy-on-write breakage.** A process that forks shares its memory pages with the child until one of them writes. Because every child immediately began incrementing and decrementing the shared singletons, the pages holding those objects were dirtied and copied in every child. Deployments that forked worker processes to share a warm heap paid for it in resident memory. Immortalising the singletons keeps those pages read-only and genuinely shared. **Contention between threads.** Multiple threads hammering the same counter on the same cache line serialise on that line. That is tolerable when a global lock already serialises bytecode execution, and intolerable once you remove it. Immortal objects were a prerequisite both for the per-interpreter GIL that landed in 3.12 and for the free-threaded build — experimental in 3.13, and **officially supported in 3.14 under PEP 779**, where a single-threaded penalty of roughly 5–10% is documented. ## What it means for your code Three concrete consequences: 1. **Never read anything into a singleton's count.** `sys.getrefcount(None)` does not tell you how many names point at `None`; it tells you the object is immortal. Any leak check, test assertion or diagnostic based on such a reading is measuring a constant. 2. **Absolute-count assertions are not portable.** They already had to account for the call's own argument reference; now they must also account for immortality, and in a free-threaded build for counting schemes — deferred and biased reference counting — that are deliberately not a naive shared integer. Assert on observable lifetime instead. 3. **Extension code cannot assume decref frees.** Native code that releases a reference to a singleton is a no-op by design; the memory is never returned. ## What is not immortal Ordinary objects — your instances, lists, dicts, strings you build at runtime — are counted normally and freed the moment their count reaches zero, exactly as before. Immortality applies to a fixed, small set of interpreter-owned objects whose memory cost is bounded and paid once at startup. It is not a leak, and it is not a general opt-in mechanism exposed to Python code. ## How to talk about it in an interview Nobody's offer turns on this. It is the kind of thing an interviewer asks out of curiosity, usually after a broader reference-counting question, to see whether you have kept up with the runtime. A complete answer is three sentences: the value is a pinned sentinel, immortality arrived in 3.12 via PEP 683, and the reason was to stop shared singletons from dirtying copy-on-write pages and contending on cache lines — which was a precondition for a per-interpreter GIL and for free-threading.