A tail calling interpreter for Python (already landed in CPython)
blog.reverberate.org
A tail calling interpreter for Python (already landed in CPython)
1–10 of 93 posts
Re: A tail calling interpreter for Python (already landed in CPython)
#2This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.
Re: A tail calling interpreter for Python (already landed in CPython)
#3This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.
That's probably one of the more frustrating things about Python. Each release it gets all sorts of questionable new syntax (including the very strange pattern matching "feature" that kind of sucks compared to something like Erlang or Scala), but we never get real useful quality of life improvements for basic functional programming like TCO or multi line lambdas
Re: A tail calling interpreter for Python (already landed in CPython)
#4This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.
Guido is no longer BDFL though, it's the steering committee that decides.
Re: A tail calling interpreter for Python (already landed in CPython)
#5This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.
That's probably one of the more frustrating things about Python. Each release it gets all sorts of questionable new syntax (including the very strange pattern matching "feature" that kind of sucks compared to something like Erlang or Scala), but we never get real useful quality of life improvements for basic functional programming like TCO or multi line lambdas
The utility value of multi-line lambdas is real, but the readability of these is terrible. And Python prizes readability. So you know where this initiative will end up.
Re: A tail calling interpreter for Python (already landed in CPython)
#6This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.
That's probably one of the more frustrating things about Python. Each release it gets all sorts of questionable new syntax (including the very strange pattern matching "feature" that kind of sucks compared to something like Erlang or Scala), but we never get real useful quality of life improvements for basic functional programming like TCO or multi line lambdas
Python has always been unashamedly imperative, with some functional features entering by slipping through the cracks. The pattern matching thing seemed ok to me when I tried it, but I haven't used it except briefly, since I'm still mostly on Python 3.9. Interestingly, Python has been losing users to Rust. I don't entirely understand that, other than everyone saying how Rust's tooling is so much better.
Re: A tail calling interpreter for Python (already landed in CPython)
#7Earlier quoted context omitted.
That's probably one of the more frustrating things about Python. Each release it gets all sorts of questionable new syntax (including the very strange pattern matching "feature" that kind of sucks compared to something like Erlang or Scala), but we never get real useful quality of life improvements for basic functional programming like TCO or multi line lambdas
The utility value of multi-line lambdas is real, but the readability of these is terrible. And Python prizes readability. So you know where this initiative will end up.
Nothing more readable than a triply-nested list comprehension on an object that exists only to vend its __getattr__ for some unholy DSL
Re: A tail calling interpreter for Python (already landed in CPython)
#8This does NOT mean Python will get Tail Call Optimization, as Guido cannot be shown The Light, and has decided.
Guido is no longer BDFL though, it's the steering committee that decides.
Ah, you’re correct. My comment was mainly meant as a tongue in cheek remark to point out that this definition of tailcall is wholly separate from Python function objects and merely an implementation detail.
Re: A tail calling interpreter for Python (already landed in CPython)
#9See also this little bit of discussion about a week back: https://news.ycombinator.com/item?id=42999672
Re: A tail calling interpreter for Python (already landed in CPython)
#10Will 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?