Live Call Stack

## What the limit actually is Every Python-level call pushes a frame — the object that holds the running function's locals, its instruction pointer and a link to its caller. CPython tracks how deep that chain currently is for the running thread, and before it enters another Python call it compares that depth against a single ceiling stored in the interpreter: the *recursion limit*. Cross it and CPython raises `RecursionError` with the message "maximum recursion depth exceeded". The default value on CPython is **1000**. Two functions expose it, and both live in `sys`: ```python import sys print(sys.getrecursionlimit()) # 1000 on a stock CPython sys.setrecursionlimit(3000) # interpreter-wide, effective immediately ``` `sys.setrecursionlimit` is not scoped to a call, a module or a thread. It mutates one number that the whole interpreter consults, so a library that raises it raises it for everyone in the process, and there is no context manager that puts it back. Code that changes it should save the old value and restore it. ## What it is not It is **not a memory limit**. It counts frames, and frames vary enormously in size — a function with two locals and a function holding a large tuple of intermediates cost the same one unit. So the limit does not tell you how much memory a recursion will use, and hitting it is not the same failure as `MemoryError`. It is **not a per-thread setting**. Each thread carries its own depth counter, so one thread recursing deeply does not push another over the edge, but they all measure themselves against the same limit value. It is **not a language rule**. It is a CPython implementation guard; other implementations are free to enforce depth differently, and no Python implementation is required to eliminate tail calls, so "write it tail-recursively" does not make the depth go away in CPython. ## Why the guard exists Historically, each Python-level call also consumed a frame on the real C stack that the operating system gave the thread. That stack is a fixed allocation — commonly around 8 MiB for a process's main thread — and running off the end of it is a hard crash, not an exception. The recursion limit is a cheap counter that is designed to trip *before* the real stack is exhausted, converting a segfault into a catchable Python exception. Since **3.11** pure Python-to-Python calls are inlined in the evaluation loop and no longer cost a C stack frame each, and **3.12** split the accounting outright: the number you set governs Python frames, while recursion that re-enters the interpreter through C code is bounded by a separate internal guard. In other words, the limit you can see and set is a budget for *Python* frames. ## Where it fires in real code A literal recursive function on deep data is the obvious case: a linked structure with several thousand links walked one call per link will exceed 1000 long before the data looks large. The subtler cases have no visible recursion at all: * a `__getattr__` that reads `self.something` which is itself missing, so every lookup re-enters `__getattr__`; * a `__repr__` that formats a structure containing itself; * a property getter that reads the property it implements; * two functions that call each other with no terminating condition, so the cycle is spread across files. The traceback is a good tell. The `traceback` machinery collapses repeats, so you see a short cycle of frames followed by a line such as `[Previous line repeated 996 more times]`. A tight repeat of one or two distinct frames means runaway recursion; a long chain of *different* frames means genuinely deep data. ```python import sys def depth(n=1): return depth(n + 1) try: depth() except RecursionError: print("stopped at limit", sys.getrecursionlimit()) ``` ## Catching it `RecursionError` is a subclass of `RuntimeError`, which is why an over-broad `except RuntimeError` quietly absorbs it. Catching it deliberately is legitimate for a probe — measuring how deep you got, or turning a hostile input into a 400-style rejection — but it is a poor control-flow mechanism, because the handler runs while the stack is still almost full and needs frames of its own to do anything useful. ## The first decision after seeing one Ask whether the recursion is *unbounded* or merely *deep*. Unbounded means a cycle or a missing base case, and no limit value fixes it — raising the ceiling only makes the failure slower and more expensive. Deep means the input legitimately has that many levels, and then the choice is between raising the ceiling knowingly and restructuring the traversal so depth does not live on the call stack at all.