Hi kiwi0fruit, welcome to discourse. I ask that you include a bit more context in your post — why should folks visit that link and what kind of discussion would you like to have here?
I’d suggest having a look at the python to julia interop packages:
These allow python and julia to talk to each other and send data structures back and forth.
If you want to call libraries written in one language from the other, this is a far easier and more reliable option than transpiling.
I’m the author of Py2Jl.jl. Py2Jl.jl is useful though it haven’t supported full-featured Python, and I think you can already use JuliaPy and Py2Jl to speed up numeric computations instead of Numba.
Py2Jl.jl is aimed at migrating Python codebase into pure Julia. I’m still looking for a way to transpile full-featured Python without heavy performance issues, but my bandwidth seems to be a problem.
The following obstacles are lied at data model and import. Currently I translated objects into pure Julia ones and the support for Python reflection is missing, and import constructs haven’t been translated yet.
I’d like to invite any guys have insterests to join Py2Jl.jl’s development. It’s now quite straightforward(but does work) and you might be capable of understanding its implementation within several instants.
That’s great, I think this is the sweet spot for this kind of project. The heavy lifting of converting syntax is the part which is relatively easy to automate and the user can then fix up performance and stylistic problems by hand.
To get an idea of how hard it is to solve the completely general problem of translating python (or python-like) code to a performant backend it’s interesting to look at the efforts in python land. Numba has about 13000 commits, cython has 15000 commits and pypy has 66000 commits. Yikes!
The original post came from this discussion: Why Julia? Will Python/Numba and Python/Cython lose to Julia? that led to PEP for Python-free interop at C level vs. Python to Julia transpiler.
And the latter is actually the opposite to migrating Python codebase into pure Julia. It’s about writing Julia in Python, transpiling and not migrating to Julia.
It is still very unclear
- how you imagine this would work (as usual, the devil is in the details),
- what the benefit would be (as opposed to, say, writing Julia in Julia).
Despite a lot of similarities in some elements of surface syntax, Python and Julia have very different core semantics, type systems, and performance models. You can map certain subsets of types (ie values with those types), which is useful when you want to call existing library code from the other language.
- The first try may be parsing valid Python code with types written as classes from stub module into pyhton AST (macroses written as function decorators). Then generating Julia code from that AST (together with source maps that can be used for lynting and autocompletion passthrough in IDE). Comments and docstrins can also be utilized but only as last resort.
- The benefit is that code is written Python. It’s already enough of a benefit
This “Juthon” language surely would be more pythonic than Julia.
There is no big practical benefit in the transpiler as Julia is readable and simple enough to move from Python to Julia. Transpiler idea is more about aestetics.
Have you ever thought about JIT related stuffs? I think a transpiler could support a superset of what Numba could do now.
A core dev of Numba said that multiple dispatch could make Julia slower, however when it comes to purely static cases, dispatching will not be dynamic and just compiled into codes without runtime test.
Actually now Numba now does Python → llvm. The proposed transpiler would do Python → Julia → llvm but also itilize Julia packages ecosystem that is elegant.
If numba can support most python data models in nopython mode, we can think python->llvm might be better python->julia->julia back-ends
Since this thread was first posted, there is now a FAQ on transpiling: