You are right, we should have made that clearer. If you look at all the 25 compilers that we list at the bottom of: https://lpython.org/, some of them are supersets, some of them are subsets. Sometimes the distinction is blurry, since even with LPython you can call arbitrary CPython today, it just doesn't get compiled right now, but perhaps later we can actually compile it like Cython does, just not speed it up much. In that case we become a subset that is fast, the rest is slower, but I think every superset of Python behaves like that too. In a way, I think all of the 25 compilers supports all of Python one way or the other (LPython as well), and I think each of them only gets a subset to be fast.
If you have some ideas how to best communicate this, let me know.
The best approach that I know right now is to say that we support a strict subset of Python, and if it compiles, it will be fast. The rest of Python you have to call explicitly and it will be slow and you get a CPython dependency in the binary that we generate, but you can do it. That way there is a clear distinction what gets compiled via our compiler into high performance machine code and what gets dispatched via CPython (it will eventually get "compiled", but it will just call CPython).
I guess I'd put it like "LPython compiles a type-annotated Python subset (dialect? variant?) to optimized machine code. Interop with CPython is easy: arbitrary Python code can go in the same source file using a decorator." -- just as an example to try to be helpful -- of course you know your system and I don't. It sounds really cool and I'm wishing you luck.
Comments
You are right, we should have made that clearer. If you look at all the 25 compilers that we list at the bottom of: https://lpython.org/, some of them are supersets, some of them are subsets. Sometimes the distinction is blurry, since even with LPython you can call arbitrary CPython today, it just doesn't get compiled right now, but perhaps later we can actually compile it like Cython does, just not speed it up much. In that case we become a subset that is fast, the rest is slower, but I think every superset of Python behaves like that too. In a way, I think all of the 25 compilers supports all of Python one way or the other (LPython as well), and I think each of them only gets a subset to be fast.
If you have some ideas how to best communicate this, let me know.
The best approach that I know right now is to say that we support a strict subset of Python, and if it compiles, it will be fast. The rest of Python you have to call explicitly and it will be slow and you get a CPython dependency in the binary that we generate, but you can do it. That way there is a clear distinction what gets compiled via our compiler into high performance machine code and what gets dispatched via CPython (it will eventually get "compiled", but it will just call CPython).
I guess I'd put it like "LPython compiles a type-annotated Python subset (dialect? variant?) to optimized machine code. Interop with CPython is easy: arbitrary Python code can go in the same source file using a decorator." -- just as an example to try to be helpful -- of course you know your system and I don't. It sounds really cool and I'm wishing you luck.
Thank you! I opened up an issue to do this: https://github.com/lcompilers/lpython/issues/2220.