Python has a pretty distinctive programming style (what's considered "pythonic"), and code that makes idiomatic use of tail calls tends to be structured quite differently. While it may have been a good addition early in Python's history, retrofitting it now would make the language more complicated and messy, and avoiding having a dozen ways to do the same thing (as in Perl) has been a goal from the start. Python's design seems to argue that any incremental improvements gained by using one coding style over another will be lost due to dealing with several different coding styles. (Particularly when somebody is actually trying to write Scheme, Haskell, etc. in Python.)
Questions about whether it'd be better if Python supported tail-call elimination, type inference, macros, etc. need to consider not just the theoretical power advantage, but the extent they would tend to fragment the existing community, make existing code harder to use/maintain, etc.
FWIW, Lua (http://lua.org) is stylistically quite similar to Python, and has an equally strong focus on keeping things simple, but approaches it differently. Its designers kept the core language extremely small, yet easily extensible in Lua or C. It's very interesting to compare and contrast its design with Python's. (It's also a great language in its own right, and it has TCO.)
Questions about whether it'd be better if Python supported tail-call elimination, type inference, macros, etc. need to consider not just the theoretical power advantage, but the extent they would tend to fragment the existing community, make existing code harder to use/maintain, etc.
FWIW, Lua (http://lua.org) is stylistically quite similar to Python, and has an equally strong focus on keeping things simple, but approaches it differently. Its designers kept the core language extremely small, yet easily extensible in Lua or C. It's very interesting to compare and contrast its design with Python's. (It's also a great language in its own right, and it has TCO.)