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

Steven D'Aprano steve at
Mon Jun 11 05:22:28 CEST 2007

On Mon, 11 Jun 2007 01:28:09 +0100, Alexander Schmolck wrote:

> Steven D'Aprano <steve at> 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.

Don't keep us in suspense. What do you believe is 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.

He's not the only one who gets to make these decisions. But even if he
uses his veto to prevent tail-recursion optimization from being put into
the main branch, there are other options.

>>>> (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).

That's not the sort of arbitrary failure I was discussing, but for that
matter Python is one of those languages. Perhaps Python is not the
language for you?

Correct me if I'm wrong, but surely it is C++ that can have arbitrary
behaviour for "a + b", not C?

>> 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.

Sorry, how does that work? You're suggesting that there is an algorithm
which the compiler could follow to optimize away tail-recursion, but human
beings can't follow the same algorithm?

Now I'm confused.


More information about the Python-list mailing list