On Sat, May 2, 2015 at 9:55 AM, Chris Angelico <ros...@gmail.com> wrote: > On Sun, May 3, 2015 at 1:45 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: >> On Sat, May 2, 2015 at 5:42 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: >>> Christian Gollwitzer <aurio...@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. -- https://mail.python.org/mailman/listinfo/python-list
