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

Steven D'Aprano 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
welcomed gratefully.

 
>> (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?


-- 
Steven.




More information about the Python-list mailing list