Yes, that's annoying, isn't it? The Python language has an excellent development process IMHO, but, alas, even great processes can produce substandard results n

Yes, that's annoying, isn't it? The Python language has an excellent development process IMHO, but, alas, even great processes can produce substandard results now & then. And I think it's clear that leaving TCO out of Python was the wrong decision. But to address your question: the fact is that OO is rarely taken to this extreme. That's why Cook's article (referenced on this page) had to be written; people just don't think that way. And even when they do, situations like that in the article are not super common. What we have here is a tree-ish structure in which nodes do computation on their subtrees, and the way in which that computation is done needs to be hidden behind an abstraction barrier. That last is what is forcing the recursion requirement. If it weren't true, then some master function could query all nodes in the tree directly, and an iterative method would work fine. However, if we are in such a situation, then the fact is that Python just doesn't work as well as some other languages. There is no "way to handle it". Note, BTW, that TCO is not a complete solution. A function only gets one tail call. If a node needs to query two or more child nodes, then at least one of those calls is not a tail call, and you get stack troubles. The linked page gives an example of just such a situation: the "rebalancing" stuff mentioned in comment #7. See also my comment [#11, id ggchappell]. Guy never responded to it; wish he had.