Python Implemention in Julia

Hi all :slight_smile:

I know about CPython and IronPython and probably a couple more. These are all implementation of python. Is there also such a project in Julia. Using Julia for a python implemention?

Cheers

1 Like

There’s only one Julia implementation, and I’m not aware of any plans for others.

2 Likes

Sorry, I didn’t mean another Julia implementation. But using Julia to implement python like dotnet is used for IronPython

What are your plans of using here?

For example a good integration with VS Code (what I understand IronPython to be for .net at first glance) would be the plugin Home · Julia in VS Code).

Otherwise maybe it is better to have good interfaces instead of a re-implementatio? For example Python will not be reimplemented in Julia, since there are several packages that allow to call Python Code (same for C code being called from Julia),

For using Julia Code in Python I am sure there is something, but I am not that much using Python myself.

This is a FAQ: Why don’t you compile Matlab/Python/R/… code to Julia?

4 Likes

I think this isn’t quite the same thing, although I agree it’s linked – I think the IronPython example is a bit more subtle, but I suspect the analogy the person is getting at is:

  • C :: CPython
  • Java :: Jython
  • Julia :: ???

So not transpilation, but literally writing a Python interpreter in Julia.

8 Likes

That only seems worthwhile for languages like Java and C#/.NET that run in a VM, in which case it’s more painful to call anything that doesn’t run in the same VM.

Julia compiles to the native architecture, not a VM, so it can directly call the native libpython from CPython (e.g. via PyCall.jl or PythonCall.jl), with no additional overhead. So there’s no real advantage to be gained from a Python interpreter written in Julia.

11 Likes

I agree the value is likely not there. I’m just trying to clarify what I believe is OP’s intended question.

5 Likes

Yeah like an interpreter of python written in pure Julia.

1 Like

Let me try to summarize the thread and address the two themes brought up:

  1. There is no interpreter for Python being written in Julia that is widely known about.
  2. As @stevengj notes, the reason there is no interpreter for Python being written in Julia is that the value for it is unclear – writing an interpreter in Julia instead of C will not make Python faster and Julia is a “native” language that doesn’t provide privileged interactions with a VM the way that Jython does.
4 Likes

I agree with @stevengj’s take, but I’d point out one notable exception to the general rule that VM considerations drive the development of alternative Python implementations: PyPy, which is written in Python (sort of).

The motivation for PyPy is to offer a different set of tradeoffs. So you can imagine an implementation of Python in Julia if there were promising design choices that would be easier to explore with that approach. I can’t think of what they would be, but I also can’t rule it out.

Regardless, such a project would be a ton of work and would therefore need to offer a big payoff to be worth it.

1 Like

it’s already been done, it’s called:
https://numba.pydata.org/


I’m only half-joking, because if you use Julia to write a python interpreter, it’s probably gonna compile to the same LLVM IR as Numba (optimally)

Didn’t though about the VM. Yes that makes sense

Having another implementation of Python can be useful, e.g.

RustPython can be embedded into Rust programs to use Python as a scripting language for your application, or it can be compiled to WebAssembly in order to run Python in the browser.

I don’t think the payoff for Julia would be that great for having yet another way to call Python code since Julia itself can be used as a scripting language if needed.

What do you think would be the magnitude of this project (lines of code or man years)?

RustPython has about 90kloc of Rust.

CPython seems to be more like somewhere between 500kloc and 1Mloc. Sounds like something is missing in RustPython.

CPython has 320kloc C (excluding comments), and Rust has better abstraction power than C so it seems plausible. Much of both implementations are written in Python, e.g. the (large) standard library, and can probably be shared.

Interesting. I didn’t find any reliable source for this. How did you find this out? Thanks!

For counting lines I use tokei. For the stdlib, it’s in the Lib directory of RustPython. Though it does look like a bunch of the stdlib is actually missing as you guessed. Compare to the cpython version https://github.com/python/cpython/tree/main/Lib

Edit: actually the missing stuff is documented What’s left (but as I said some of these are written in Python and can reuse code from CPython).

1 Like