[Python-Dev] Proper tail recursion

[Chris King]

On Thu, 15 Jul 2004 18:01:25 -0400, Tim Peters <tim.peters at gmail.com> wrote:
> [Jeremy Hylton]
> > ...
> > Getting a useful traceback after tail call optimization seems like an
> > awfully important quality of implementation issue.
> 
> Indeed, in delegation-heavy designs, when an error occurs the
> delegation path you took to reach the failing code often *is* "the
> error".

Well, since optimizing only when -O is specified was rejected, and
from __future__ import tail_call seems like a similarly bad idea, why
not something like 'sys.optimize_tail_calls()' to enable the alternate
mechanism? This can be done in such a way that programs not using it
won't even notice a change in execution speed (e.g. using a different
eval loop when it's enabled).

I'd then place this mechanism in the same category as such other
implementation-altering functions as gc.disable(), psyco.full(), and
sys.setrecursionlimt(1e9). Since it's explicitly enabled by the
programmer, he'd know the consequences of enabling it. The only
downside is a little extra glue code would be needed to replace it
with an appropriate sys.setrecursionlimit() call on Pythons that don't
support it:

import sys
try:
    sys.optimize_tail_calls()
except AttributeError:
    sys.setrecursionlimit(10000)