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

[Carsten Haese]

On Wed, 2007-06-13 at 18:22 +0000, Neil Cerutti wrote:
> 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?

The fact that you don't see how many call levels down your algorithm got
before throwing an exception. This may be an important clue in debugging
a recursive algorithm.

-- 
Carsten Haese
http://informixdb.sourceforge.net