Python's "only one way to do it" philosophy isn't good?

Neil Cerutti horpner at yahoo.com
Wed Jun 13 14:22:54 EDT 2007


On 2007-06-13, Anders J. Munch <2007 at jmunch.dk> wrote:
> General tail-call optimisation is of course completely
> out-of-bounds for Python, because it ruins tracebacks.  Unlike
> tail recursion, which could use recursion counters.

Is it really ruined? To use a similar example:

def foo(x):
    bar(x+1)

def bar(x):
    if x > 10:
        raise ValueError
    else:
        foo(x+2)

Today, when I call foo(4), I get something like:

C:\WINNT\system32\cmd.exe /c python temp.py
Traceback (most recent call last):
  File "temp.py", line 529, in <module>
    foo(4)
  File "temp.py", line 521, in foo
    bar(x+1)
  File "temp.py", line 527, in bar
    foo(x+2)
  File "temp.py", line 521, in foo
    bar(x+1)
  File "temp.py", line 527, in bar
    foo(x+2)
  File "temp.py", line 521, in foo
    bar(x+1)
  File "temp.py", line 525, in bar
    raise ValueError
ValueError
shell returned 1

With tail-call optimization you'd get something like:

C:\WINNT\system32\cmd.exe /c python temp.py
Traceback (most recent call last):
  File "temp.py", line 529, in <module>
    foo(4)
  File "temp.py", line 525, in bar
    raise ValueError
ValueError
shell returned 1

What makes the latter harder to work with?

-- 
Neil Cerutti



More information about the Python-list mailing list