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