Steven D'Aprano <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list