[hmaarrfk]

> And Coconut code runs the same on any Python version, making the Python 2/3 split a thing of the past.

My understand was that the big issue was the fact that [third party] libraries assume that strings were made of 8bits characters.

How does coconut solve that issue?

Seems a little misleading....

if you import enough things from `six` or `__future__` then you code will run the same on both python 2/3.

some things like fancy tuple expansion aren't available if you work with that subset, but yeah, most things are OK.

[JoBrad]

I haven't used Coconut beyond some dabbling last time it made HN's frontpage, so someone with more experience may be able to provide a better answer. However, the syntax is based on Python 3, and they use their own builtins for both Python 2 and 3 to maintain compatibility. Some functionality can't be back-ported to Python 2 (tuple unpacking with *, f strings, etc.), and there is more info about that at the link below.

https://coconut.readthedocs.io/en/master/DOCS.html#compatibl...

[hmaarrfk]

Thanks for the link.

I wonder how they are doing tail call optimization in python

[eindiran]

Here is where TCO is implemented in the Coconut compiler code:

https://github.com/evhub/coconut/blob/07e311fb8f69861d30e58f...

[zbentley]

That's clever and horrifying. Clever because writing a regex-based preprocessor for a complex, dynamic language that adds TCO and actually works in most cases is impressive. Horrifying because . . . it's a regex based preprocessor that rearranges arbitrary function code in a complex, dynamic language.