Yes, that's what the email said.
I was -- well -- shocked. Too shocked to be polite. Content Warning: much snark follows.
BLUF: Tail Recursion is not Tail Recursion Optimization.
Eventually, it became clear they were worried about tail recursion optimization. Maybe I'm too focused on words, but I think words matter. The initial claim was so clearly wrong, I had to challenge it. It took three *more* emails to get to the optimization point.
Hence my overload of snark. Three emails to discover they didn't see the word "optimization."
Here's an example. (I wish questions included example code instead of weird assertions that are clearly false.)
def f(x: int) -> int: if x == 0: return 1 return x*f(x-1)
This function demonstrates tail recursion. The "tail" of the function involves a recursive reference to the function. An optimizing compiler can optimize the recursion to make it not recursive.
If Python doesn't do tail recursion, this function would not work.
Since it works, Python does tail recursion.
Python limits recursion so that you crash cleanly before you're out of memory.
This is important. Older languages would run out of memory for stack frames. Instead of reporting a recursion problem, they'd just crash. Out-of-memory. Sorry. No drop to `pdb`. Nothing. This is bad.
In the old Mac OS (≤9) the stack and heap memory grew from opposite ends of the available RAM. If they collided, it was a stack overflow, and the running app was crashed.
Here's how the stack limitation plays out in practice:
This shows how a large number of operations (around 1,000) exceeds an internal limit. The exception is not out-of-memory, it's too much recursion.
A slightly smaller number (997 in this example) worked. 999 didn't work because it exceeded the threshold.
Manual Tail Recursion Optimization
New word: Optimization. New concept.
If the tail recursion were optimized into a loop, we'd see code that behaves as if we wrote this:
>>> from math import prod >>> def f1(x: int) -> int: ... return prod(range(1, x+1))
This unwinds the tail recursion into a loop. A generator,
range(1, x+1), creates a sequence of values, which are reduced into a product. This doesn't involve recursion or stack frames. Indeed, because it's a generator, it involves very little memory.
And it works for numbers well over 1,000. Evidence (if any were needed) that tail recursion optimization is *not* being done in Python.
We'll repeat this for those who feel the need to send me crazy-sounding emails.
Automatic Tail Recursion Optimization
There is no automatic transformation from tail recursion to loop in Python.
I'll repeat that for the folks who send me emails claiming tail recursion isn't supported. (Everyone else probably has a pretty good grip on this.)
There is no automatic transformation from tail recursion to loop.
Tail recursion works. It has a limit.
Manually optimized tail recursion (to create a loop) also works. It doesn't have the same limit.
Stated yet another way: unlike some languages, Python does not optimize for you. You must do the rewrite yourself.
While I would have thought these ideas (tail recursion and tail recursion optimization) were different. I was wrong. Hopefully, this blog post will help folks read *all* the words.
I'm also pretty sure it's covered in here: https://www.packtpub.com/product/functional-python-programming-second-edition/9781788627061.