A tail calling interpreter for Python (already landed in CPython)

How does this differ from direct threading interpreters?

It seems like it solves the same problem (saving the function call overhead) and has the same downsides (requires non-standard compiler extensions)

EDIT: it seems the answer is that compilers do not play well with direct-threaded interpreters and they are able to perform more/better optimizations when looking at normal-sized functions rather than massive blocks

http://lua-users.org/lists/lua-l/2011-02/msg00742.html

Recent discussion: https://news.ycombinator.com/item?id=42999672

Do check out the articles in the top most comment.. about how tail call optimization gets you faster interpreters.

It completely eliminates the overhead of function calls in the generated machine code while you still your code modularly using functions.

`return goto f()` syntax in C seems interesting

I had a similiar idea that Python could have `return from f()` to support tail calls without the issues raised about implicit tail calls

To read about the basics of tail calls optimization:

https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

See also this little bit of discussion about a week back: https://news.ycombinator.com/item?id=42999672

This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.

Will Python ever get fast? Or even _reasonably_ fast?

The answer is no, it will not. Instead they'll just keep adding more and more syntax. And more and more ways to do the same old things. And they'll say that if you want "fast" then write a native module that we can import and use.

So then what's the point? Is Python really just a glue language like all the rest?