[xapata]

No, Python does not have tail recursion optimization, because Guido decided that he wanted to preserve stack frames for better tracebacks. The language team may revisit that decision someday.

I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.

[Jtsummers]

> because one can write tail recursion in any language that supports subroutines.

If only! For anyone else who got saddled with some FORTRAN 77 code, you may or may not have recursion available even with subroutines. It wasn't required by the language standard, but some implementations supported it. Not the one I "got" to use (and quickly moved on from) a while back, though.

[giantdude]

Thanks, that is what I thought, but didn't trust my memory.

Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)

[xapata]

In those cases, you may wish to use a dynamic programming technique. A bit of caching might be a greater optimization than tail call elimination. The `@functools.lru_cache` tool is very easy to experiment with.

[xapata]

> will be long and redundant

They made a highly redundant traceback display much more pleasant a couple years ago, writing "the same thing 1,998 more times ..." or something like that.

[aidenn0]

Common lisp doesn't require tail call elimination either, fwiw

[bjoli]

But every implementation except clisp, ECL and clisp do it reliably.

[aidenn0]

sbcl doesn't always do it, depending on optimization settings, and clisp does do it when compiling; by "reliably" perhaps you meant "by default"?

[tmtvl]

I think you may have meant to substitute ABCL for one of those clisps?