When would you use threading.stack_size to run a deeply recursive routine?

## The lever it actually pulls Two separate things bound recursion in CPython: the frame counter you set with `sys.setrecursionlimit`, and the real stack the operating system gave the thread. `threading.stack_size` is the only lever in the standard library that moves the second one, and it moves it only for threads created *after* the call: ```python import threading threading.stack_size() # current setting; 0 means platform default threading.stack_size(64 * 1024 * 1024) ``` Called with no argument it reports the setting. Called with a size it records it for subsequently created threads; existing threads, and the main thread, are unaffected. The main thread's stack was allocated by the OS before Python started, so from inside the process there is nothing to change — which is exactly why the pattern is to move the deep work onto a worker thread rather than to attempt it on the main one. Platforms constrain the value: there is a minimum (32 KiB), some systems require a multiple of the page size, and a platform that does not support setting it raises an error rather than silently ignoring the request. Handle that rather than assuming it took. ## The full idiom Both constraints have to be lifted, because raising either one alone leaves the other binding: ```python import sys import threading def deep(n=1): if n >= 30_000: return n return deep(n + 1) def run(): sys.setrecursionlimit(40_000) print(deep()) threading.stack_size(64 * 1024 * 1024) worker = threading.Thread(target=run) worker.start() worker.join() ``` Note that `sys.setrecursionlimit` is interpreter-wide, so raising it inside the worker raises it for every thread — the stack size is the only part of this that is genuinely scoped to the new thread. ## When it is the right call It earns its place in a narrow band: * the depth is **real**, not a cycle — a cycle exhausts any stack, and a big one merely makes the failure slower and the crash larger; * the depth is **bounded and known**, so you can size the stack against a measured maximum rather than guessing; * the recursive code is **not yours to restructure** — a third-party recursive-descent parser, a legacy traversal with subtle post-recursion work — or the job is one-shot and not worth reshaping; * the workload is **batch-shaped**, so an extra worker thread and a large stack reservation are acceptable. If you own the traversal and it will keep growing with the data, restructuring so depth lives in a heap structure rather than the call stack is the durable answer, and the thread trick is the stopgap that buys time for it. ## What it costs and what it does not fix The setting is process-global for future threads, so a pool created later inherits the large stack for every worker. On most systems the stack is reserved as virtual address space and only becomes resident as it is touched, so the cost of an unused reservation is modest — but a pool of many threads each reserving tens of megabytes is a real address-space and accounting concern, and it is easy to set once at import and forget. Set it, create the thread you need, and set it back to 0 if other threads follow. It also does not change the accounting split: since **3.12** recursion that passes through C code answers to an internal guard rather than to your `sys.setrecursionlimit` value, so a larger stack helps that recursion survive physically while the guard may still stop it. ## The alternatives to weigh against it * **Restructure the traversal** so pending work is held in a heap data structure — the only fix that scales with the data indefinitely. * **Bound the depth explicitly** and reject input beyond a documented maximum, which is often the correct product answer for machine-generated or untrusted input. * **Run the work in a subprocess** whose stack limit is raised by the launching environment, which isolates both the memory and the crash risk from the parent service. The thread trick is a legitimate, well-understood tool, but it is a capacity adjustment, not a correctness fix — reach for it once you have established that the depth is genuine.