Julieta Shem <js...@yaxenu.org> writes: [...]
> I agree. By the way, I once read or watched an interview with Guido van > Rossum and and he was asked why not to tail-call optimize Python and the > answer he gave --- IIRC --- was that tail-call optimization makes it > harder for a beginner to understand a stack trace. I'm now interested > in discovering whether that was his sole reason. Do you (or does > anyone) know of any reference that I could look into? Thank you. It seems everyone refers Guido van Rossum's post at https://neopythonic.blogspot.com/2009/04/final-words-on-tail-calls.html >From the page, confuse-users is /not/ the only reason. After mentioning it first, he begins a second paragraph saying ``[t]he main issue here [...]'' and I wonder if by ``main issue'' he means something like --- the main /problem/ with tail-call optimization (for me) is [...]. --8<---------------cut here---------------start------------->8--- Personally, I think it is a fine feature for some languages, but I don't think it fits Python: The elimination of stack traces for some calls but not others would certainly confuse many users, who have not been raised with tail call religion but might have learned about call semantics by tracing through a few calls in a debugger. The main issue here is that I expect that in many cases tail calls are not of a recursive nature (neither direct nor indirect), so the elimination of stack frames doesn't do anything for the algorithmic complexity of the code, but it does make debugging harder. For example, if your have a function ending in something like this: if x > y: return some_call(z) else: return 42 and you end up in the debugger inside some_call() whereas you expected to have taken the other branch, with TCO as a feature your debugger can't tell you the value of x and y, because the stack frame has been eliminated. --8<---------------cut here---------------end--------------->8--- -- https://mail.python.org/mailman/listinfo/python-list
