> Um. Under my definition of "recursion", you haven't really removed > recursion in the generator version. That is, you're still calling the > depthFirstIterator method upon each iteration--you've just changed from > list-concatenation to yielding instead, which trades off list-management > overhead for closure-maintenance overhead. yup, i am aware that my generator version is also recursive. but what i thought this would do is "generate" a lazy list of return values (in theory at least). but this still doesn't explain why the yielding is so much slower than the list concatenation!
> A truly non-recursive > implementation would probably exist outside of whatever class you've got > this method in, and would keep its own pointer to the current node as it > traversed the tree. i loved the generator solution because it was short, concise and lazy, but if i am going to write the closure/continuation/recursion handling manually i'd rather go with the memory-consuming list concatenation... a non-recursive solution to traversing a recursive data type is bound to get ugly, isn't it? i just wondered if there was a concise, clean way of doing this with generators which i had overlooked, or whether there was some blatant mistake in my code. thx, Johannes -- http://mail.python.org/mailman/listinfo/python-list