[Python-Dev] Proper tail recursion (original) (raw)

Chris King colanderman at gmail.com
Fri Jul 16 02:10:59 CEST 2004

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)

More information about the Python-Dev mailing list