Why does CPython still push a frame when a Python function returns a call in tail position?

### What "tail position" means A call sits in *tail position* when its value becomes the caller's return value and nothing is left to do afterwards. `return helper(n - 1)` is a tail call; `return 1 + helper(n - 1)` is not, because the addition still has to run once `helper` comes back. In a language that mandates tail-call elimination, the compiler notices there is no work left, reuses the caller's stack slot instead of adding one, and an arbitrarily long chain of tail calls runs in constant stack space. ### What CPython actually does CPython does not do this — at any optimization level, in any release, 3.14 included. The compiler emits exactly the same instruction sequence for a tail call as for any other call. Disassemble `def f(n): return f(n - 1)` and you see the function loaded, the argument computed, a call instruction, and then a *separate* return instruction. That separate return is the whole reason the caller must stay: the interpreter pushes a frame for the callee while the caller's frame sits underneath it holding the instruction pointer that says "resume at the return". Every recursive step adds another one, so the memory a recursion needs grows linearly with its depth, and the interpreter's nesting counter climbs on every call. ### Why the refusal is deliberate, not an oversight Frames in Python are not an invisible implementation detail; they are reachable objects that the language's own tooling depends on. A traceback carries one entry per active frame, which is what tells you the path the program took to the failure. `sys._getframe()` and `inspect.stack()` walk the live chain. Debuggers, profilers and coverage tools install a hook with `sys.settrace()` and are called on every call, line and return. Silently dropping the caller's frame on a tail call would delete call history that all of those report — a program would fail somewhere and the traceback would simply not mention the function that got you there. Python's designers have repeatedly judged that a faithful stack trace, every time, is worth more than unbounded recursion in a language where rewriting the recursion as a loop is easy. There is a mechanical argument too: the name in `return f(x)` is looked up dynamically at call time and can be rebound between calls, so a self-call is not statically guaranteed to be a self-call at all. ### What did change, and what people mistake for tail calls Two 3.x changes get misreported as tail-call optimization. In **3.11**, a Python function calling another Python function stopped recursing into the C evaluator. The interpreter pushes a lightweight frame record onto its own data stack and keeps running in the same C loop, and it materializes a full frame object lazily, only when something actually looks at it. Calls got substantially cheaper and stopped consuming C stack per Python call. Depth still grows: this is a cheaper frame, not a reused one. In **3.14**, CPython ships an optional build in which each bytecode handler is a C function that tail-calls the next handler instead of dispatching through a computed-goto table; a modern compiler turns those into jumps and the interpreter gets a few percent faster. That is the eval loop's own C-level calling convention. `return f(x)` in your Python code behaves exactly as it always did. The JIT is a separate experiment: off unless you set `PYTHON_JIT=1`, checkable with `sys._jit.is_available()`, with results ranging from somewhat slower to somewhat faster, and it adds no tail-call elimination either. ### What you do instead For direct self-recursion in tail position, write the loop by hand. Wrap the body in `while True:`, and where the recursive call was, rebind the parameter names to the new arguments and `continue`; where the base case was, `return`. That is the transformation elimination would have performed, done explicitly and visibly. For a recursion that branches — a walk over a nested structure — you need somewhere to keep the pending work, so carry an explicit stack: a list you seed with the root, pop from, and extend with children. Trampoline decorators exist as a curiosity: the wrapper loops, and the "recursive" call returns a small object describing the next call rather than making it. They handle only direct self-recursion, cost more per step than a plain loop, and destroy exactly the traceback and introspection that made CPython decline elimination in the first place. ### The interview answer Say the fact, then the mechanism, then the reason. Python has no tail-call optimization; `return f(x)` compiles to an ordinary call and the caller's frame stays alive to receive the value; frames are first-class objects that tracebacks, `inspect` and tracing hooks read, so eliding them would silently falsify the stack; and the practical remedy for deep input is a loop you write yourself.