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

[Alexander Schmolck]

Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:

> On Sat, 09 Jun 2007 22:42:17 +0100, Alexander Schmolck wrote:
>
>>> As for why tail calls are not optimized out, it was decided that being able
>>> to have the stack traces (with variable information, etc.) was more useful
>>> than offering tail call optimization
>> 
>> I don't buy this. 
>
> Do you mean you don't believe the decision was made, or you don't agree
> with the decision?

Neither. I don't believe the rationale stated in this thread to be the true
reason.

> Are you volunteering? If you are, I'm sure your suggestion will be welcomed
> gratefully.

I rather doubt it. Guido has stated quite clearly that his not interested in
incorporating this feature.
  
>>> (do what I say).
>> 
>> Where did you say run out of memory and fail? More importantly how do
>> you say "don't run out of memory and fail"?
>
> If we can live with a certain amount of "arbitrary failures" in simple
> arithmetic,

I prefer not too, and thus when possible avoid to use languages where ``a +
b`` is liable to fail arbitrarily (such as C, where the behavior will often be
undefined).

> then the world won't end if tail recursion isn't optimized away by the
> compiler.

I'd personally much rather have arithmetic working properly. Unfortunately
this is not an option at the moment, although quite a few smart people are
working on it and although it is an immensely costly problem.

> You can always hand-optimize it yourself.

Not tail calls, in general, no.

'as