Why does `sys.getrefcount(x)` report one more reference than your code holds?

## Where the extra one comes from `sys.getrefcount(obj)` is not magic syntax; it is a function call. Evaluating the call binds the object to the function's parameter, which is itself a reference, and that reference exists while the function reads the counter. So the value returned always includes the argument you just handed over. The documentation states this plainly: the count is generally one higher than you might expect. The consequence is a small, reliably-failing trap. A fresh object bound to exactly one module-level name reads **2**: ```python import sys x = object() print(sys.getrefcount(x)) # 2 -> the name x, plus the argument y = x print(sys.getrefcount(x)) # 3 del y print(sys.getrefcount(x)) # 2 ``` An engineer writing a cleanup test who asserts `sys.getrefcount(obj) == 1` has produced an off-by-one boundary that fails on every run, and the instinct to "fix" it by loosening the assertion to `<= 2` usually loses the very property the test was meant to protect. The right shape is a delta: capture the count before, do the work, capture it after, and assert the difference. ## The references you did not write The off-by-one is the easy half. The harder half is that the number counts *everything*, including references the interpreter creates on your behalf: * the fast-locals of every live call frame that received the object as an argument or bound it locally; * the argument tuple and the evaluation stack of a frame that is mid-call; * closure cells, when a nested function captured the name; * a function's `__defaults__` tuple, if the object was used as a default argument value; * module globals, class dicts, and instance `__dict__` entries; * the frames pinned by a live exception traceback — a caught exception can hold an entire call chain, and everything its locals reference, alive; * memoizing wrappers such as `functools.lru_cache`, which retain both arguments and results; * in an interactive session, the `_` name holding the last displayed result. None of those are bugs. They are why a count read in isolation rarely answers the question people actually have, which is *"who is keeping this alive?"* — a question the number cannot answer at all, because it is a scalar with no provenance. ## Reading it correctly Three habits make the function useful rather than misleading: 1. **Measure deltas, not absolutes.** `before = sys.getrefcount(obj)`, run the operation, `after = sys.getrefcount(obj)`; the difference is meaningful even though neither endpoint is. 2. **Measure from a stable frame.** Take both readings at the same call depth with the same locals in scope, otherwise frame references move the baseline under you. 3. **Do not read it from another thread's perspective.** The value is a snapshot; another thread can change it between the read and the assertion. ## Two modern caveats Since **CPython 3.12** (PEP 683) some objects are *immortal*: interpreter singletons such as `None`, `True`, `False` and the empty tuple carry a pinned sentinel count in the billions, and increfs and decrefs on them are skipped. Reading a count for those tells you nothing about references at all. And in the **free-threaded build** — experimental in 3.13, officially supported in 3.14 under PEP 779 — reference counting is maintained with deferred and biased schemes rather than one naively shared counter, so a single read is even further from being an exact ledger of live references. Code that asserts on absolute counts is not portable across build configurations. ## A worked reading It helps to be able to predict the number out loud. Take a module-level `payload = object()` and walk it: the global binding is one, the argument handed to the call is two, so the reading is 2. Append it to a list and the list slot makes three. Pass it into a function that keeps it in a local and read the count inside that function: the module global, the list slot, the callee's local and the argument all count, so four. Return from that function and the local goes with the frame. Nothing here is mysterious once you accept the rule that *every* place holding the object contributes exactly one, including the places the interpreter created. ## When to reach for something else If the goal is *"is this object still retained after teardown?"*, a weak reference that reports whether the object is gone is a far better instrument than a count. If the goal is *"what is holding it?"*, count-reading is the wrong tool entirely — you need a referrer walk or an allocation-tracking snapshot such as `tracemalloc` comparing before and after. `sys.getrefcount` earns its keep in exactly one place: a quick, local check of whether one specific operation added or removed a reference, with the off-by-one understood and never asserted upon.