Python's "only one way to do it" philosophy isn't good?
steve at REMOVE.THIS.cybersource.com.au
Sun Jun 10 02:23:41 CEST 2007
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?
> What's more important, making code not fail arbitrarily (and
> thus making approaches to certain problems feasible that otherwise
> wouldn't be) or making it a be a bit easier to debug code that will fail
> arbitrarily? Why not only do tail-call optimization in .pyo files and
> get the best of both worlds?
Are you volunteering? If you are, I'm sure your suggestion will be
>> (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, then the world won't end if tail recursion isn't optimized
away by the compiler. You can always hand-optimize it yourself.
dont_run_out_of_memory_and_fail = 10**(10**100) # please?
More information about the Python-list