Python is not bad ;-)

[Ian Kelly]

On Sat, May 2, 2015 at 9:55 AM, Chris Angelico <rosuav at gmail.com> wrote:
> 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.

Or you just iterate over the ast.walk generator, which uses a deque
rather than recursion.