Python is not bad ;-)

[Chris Angelico]

On Sun, May 3, 2015 at 1:45 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Sat, May 2, 2015 at 5:42 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Christian Gollwitzer <auriocus at gmx.de>:
>>
>>> That's why I still think it is a microoptimization, which helps only
>>> in some specific cases.
>>
>> It isn't done for performance. It's done to avoid a stack overflow
>> exception.
>
> If your tree is balanced, then the number of items you would need to
> have to get a stack overflow exception would be approximately 2 **
> 1000, which you can't possibly hope to fit into memory.
>
> If your tree is unbalanced and you're getting a stack overflow
> exception, then maybe you should think about balancing it.

That's assuming it's a search tree, where you *can* just "think about
balancing it". What if it's a parse tree? Let's say you're walking the
AST of a Python module, looking for all functions that contain 'yield'
or 'yield from' (ie generator functions). To do that, you need to walk
the entire depth of the tree, no matter how far that goes. I'm not
sure how complex a piece of code would have to be to hit 1000, but it
wouldn't be hard to have each level of tree cost you two or three
stack entries, so that could come down to just a few hundred.

However, while that _is_ more likely to produce an unbalanced tree,
it's also that much less capable of being converted into tail
recursion.

ChrisA