Why is relying on CPython's refcounting to close files unsafe on other implementations?

## The guarantee that is not one CPython frees an object the instant its reference count reaches zero, and that behaviour is so dependable that a whole idiom grew around it: `data = open(path).read()`, no `close()` in sight, the handle released when the temporary file object dies at the end of the expression. It works. It is also **an implementation artefact, not a rule of Python.** The language specification is deliberately silent about when finalization happens, precisely so that implementations are free to use a different memory manager. They do. Implementations built on tracing garbage collectors — PyPy, GraalPy, Jython — do not maintain per-object reference counts. Unreachable objects are discovered during a collection, which runs when the runtime decides it is worthwhile: after some allocation volume, under memory pressure, or not at all before the process exits. A file object that became garbage may sit unfinalized for a long time, and the operating system handle it owns stays open the whole while. ## What that looks like in production Consider a nightly search-index rebuilder that walks segment files, reading each one with a bare `open(path).readline()` inside a helper. On CPython it has behaved perfectly for a year. Moved to an implementation with a tracing collector for throughput, it opens files far faster than collections reclaim them, crosses the process descriptor limit somewhere in the middle of the run, and dies with `OSError` — "too many open files" — at a different segment on every attempt. The failure is a boundary effect, so it looks nondeterministic and reproduces only at scale; the code that "worked fine locally" for an 11-person team is the same code that fails in the rebuild. The same class of bug bites sockets (connections left in `CLOSE_WAIT`), database cursors and connections held out of a pool, subprocess pipes that keep a child from seeing EOF, memory-mapped regions, and any lock released only in a finalizer. ## Even CPython's guarantee is conditional It is worth being precise, because the honest senior answer is not "CPython is safe, others are not". On CPython the object is freed when the last reference goes — and several ordinary situations mean the last reference has *not* gone: * **A live traceback.** A caught exception keeps its traceback, which keeps every frame in the chain, which keeps those frames' locals — including your open handle — alive for as long as the exception object is referenced. * **A reference cycle.** If the object is in a cycle, no decref ever reaches zero and finalization waits for the cycle collector. * **A cache or registry.** A module-level dict that recorded the handle keeps it forever, and no scope exit changes that. * **Interpreter shutdown.** Finalizers are not guaranteed to run at all during teardown. So even on CPython, "the file closes when the function returns" is a probabilistic statement about your reference graph, not a contract. ## The correct construction Make the lifetime explicit and the question disappears on every implementation: ```python with open(path, encoding="utf-8") as f: head = f.readline() from contextlib import ExitStack with ExitStack() as stack: handles = [stack.enter_context(open(p, encoding="utf-8")) for p in paths] merge(handles) ``` `with` compiles to a `try`/`finally` around the block, so the resource is released on the normal path, on an exception and on an early return, in every implementation, with no dependence on the memory manager. `contextlib.closing` wraps a legacy object that has `close()` but no context-manager protocol; `contextlib.ExitStack` handles a count of resources known only at runtime. For classes of your own, expose `__enter__`/`__exit__` rather than doing cleanup in `__del__` — a finalizer is a safety net whose timing you do not control and whose exceptions are swallowed. ## Catching it before it ships The tooling for this is unusually good, and using it is the part that separates a senior answer from a textbook one: * Run the service and the test suite under **`-X dev`** (or `PYTHONDEVMODE=1`), which enables `ResourceWarning` — an unclosed file reports the line that opened it. * Turn the warning into a failure in CI with `-W error::ResourceWarning`, or per-test with `warnings.simplefilter("error", ResourceWarning)`. * Enable `tracemalloc` alongside dev mode so the warning carries the allocation traceback of the object that was never closed. * Track the descriptor count of long-running processes; a monotonically rising count is the leading indicator, long before the limit is hit. The rule that survives every implementation, every interpreter version and every build configuration is simple: **anything holding an operating-system resource gets an explicit, lexically visible lifetime.** Reference counting is an optimisation that makes sloppiness survivable on one interpreter, not a design you can build on.