Does CPython perform tail-call elimination on a tail-recursive Python function?

## The claim, precisely A *tail call* is a call whose result is returned immediately, with nothing left for the caller to do afterwards — `return helper(n - 1, acc + n)` is one; `return 1 + helper(n - 1)` is not, because the addition still has to happen after the callee returns. *Tail-call elimination* is the implementation technique of reusing the caller's frame for such a call instead of pushing a new one, which makes tail recursion run in constant stack space. **CPython does not do this.** Not for direct recursion, not for mutual recursion, not under any flag or optimisation level. The compiler emits an ordinary call instruction, the interpreter pushes a new Python frame, and the thread's recursion counter goes up by one exactly as it would for any other call. Consequently a tail-recursive function raises `RecursionError` at the same depth as a non-tail-recursive one, and rewriting a function into accumulator-passing style — the transformation that makes a function stack-safe in a language that does eliminate tail calls — changes nothing about its depth behaviour in Python. CPython's maintainers have declined the optimisation deliberately rather than by oversight; the usual reason given is that it would discard frames that tracebacks, debuggers and profilers depend on. Whatever you think of the tradeoff, the practical takeaway for an interview is unambiguous: in Python, depth-safety comes from not recursing, not from where you put the call. ## What to do instead For a genuinely tail-recursive shape the mechanical rewrite is a loop that rebinds the parameters: ```python def countdown(n): if n == 0: return "done" return countdown(n - 1) def countdown_loop(n): while n: n -= 1 return "done" ``` The loop runs in one frame at any depth, and it is also faster: even after 3.11 made calls substantially cheaper, a Python call still costs far more than a loop iteration, because it builds and tears down a frame, binds arguments and re-enters the evaluation machinery. A *trampoline* is the other classic workaround: the recursive function returns a small callable or a data record describing the next call instead of making it, and a driver loop repeatedly invokes what it gets back until a real value appears. It genuinely bounds the stack, but it changes the function's contract, flattens tracebacks into one uninformative frame, confuses profilers, and is slower than the loop it is emulating. It is a curiosity worth knowing about, not a default. ## Two changes that are not tail-call elimination **The 3.11 call inlining.** Before 3.11, a Python function calling another Python function re-entered the interpreter's evaluation function recursively, so every Python-level call also consumed a C stack frame. 3.11 changed that: a Python-to-Python call now continues in the same interpreter loop. Calls got cheaper, tracebacks got better, and — importantly — the C stack stopped growing in lockstep with Python recursion, which is why raising the recursion limit is far safer on modern versions than it was on 3.10. What did **not** change is the frame count: each call still creates a Python frame and still increments the depth counter, so the default limit still stops you at the same place. **The 3.14 tail-call interpreter.** CPython 3.14 added an optional build configuration in which the evaluation loop's per-opcode handlers hand control to one another using C tail calls rather than looping through a central dispatch. On a compiler that supports it, this yields a modest interpreter speedup. The name causes real confusion in interviews: it describes how *bytecode handlers* dispatch inside the interpreter's C code. It has nothing to do with Python-level tail calls, does not reuse Python frames, and does not change how deep a recursive Python function can go. Neither does the experimental JIT, which is off by default and is a code-generation change, not a calling-convention change. ## How this surfaces in real code The failure mode is a recursion that is correct on every input you have seen and fatal on the input you have not. A function that walks a chain one element per call is fine on test data a few dozen elements long and dies on a production chain of tens of thousands, and no amount of tail-position tidiness averts it. When a recursion's depth is proportional to input size rather than to something logarithmic like a balanced tree's height, treat the recursion itself as the risk and convert the linear part to iteration.