About rust and python

[Edward K. Ream]

In the "What's Next post I said:

"As far as wasm [WebAssembly] goes, rust has a (temporary?) advantage over python, because wasm doesn't yet support garbage collection."

Well, what about writing the python interp in rust? No need for a gc ;-) As so often happens, someone not only had that idea, but did something about it. It's called RustPython. I might study the code, just to see what real rust code looks like. Or not.

Imo, RustPython is not likely to go anywhere, unless a company like Google or Apple supports it. For Python's core devs, RustPython probably looks like a fork. Having just emerged from the trauma of the Python 3 fork, my guess is that they have no appetite for another.

Summary

RustPython is a cute idea that isn't likely to gain traction.

As I said about wasm, I see no way for someone like me to do something significant re either Python or Rust.  Onward with Leo!

Edward

[Thomas Passin]

On Monday, March 16, 2020 at 7:17:17 AM UTC-4, Edward K. Ream wrote:

In the "What's Next post I said:

"As far as wasm [WebAssembly] goes, rust has a (temporary?) advantage over python, because wasm doesn't yet support garbage collection."

Well, what about writing the python interp in rust? No need for a gc ;-) As so often happens, someone not only had that idea, but did something about it. It's called RustPython. I might study the code, just to see what real rust code looks like. Or not.

Imo, RustPython is not likely to go anywhere, unless a company like Google or Apple supports it. For Python's core devs, RustPython probably looks like a fork. Having just emerged from the trauma of the Python 3 fork, my guess is that they have no appetite for another.

Like PyPy and Stackless, though the devs are usually trying to keep compatibility with them as they add new features.

I wonder if there is a C++ to Rust converter.  That would be the only thing that could event make it thinkable.

BTW, Jython is a wonder.  It's only up to 2.7 so far, though I think they are slowly working on a version 3.  You can import any java library and use it in Python code, and you can write a Python module and call it from inside a Java program.  The only hitch in using it from the command line, really, is that it takes a long time to start up.  I used it to make a little index and search app with Lucene.

[Edward K. Ream]

On Mon, Mar 16, 2020 at 9:02 AM Thomas Passin <tbp1...@gmail.com> wrote:

>> Imo, RustPython is not likely to go anywhere, unless a company like Google or Apple supports it. For Python's core devs, RustPython probably looks like a fork. Having just emerged from the trauma of the Python 3 fork, my guess is that they have no appetite for another.

> Like PyPy and Stackless, though the devs are usually trying to keep compatibility with them as they add new features.

Right. I was thinking of both.

> I wonder if there is a C++ to Rust converter. 

Use the Google, Luke. It probably has much the same status as RustPython :-)

> That would be the only thing that could even make it thinkable.

Support from a major player would also make it thinkable.

Edward

[Edward K. Ream]

On Monday, March 16, 2020 at 6:17:17 AM UTC-5, Edward K. Ream wrote:

> [I might study] RustPython...just to see what real rust code looks like.

I have just created #1538: Create an importer for rust.

Edward

[vitalije]

You should take a look at the  PyOxidizer

I haven't used it yet, but it seems promising. The other one you should look at (and I have been using it) is PyO3, for writing python extensions in rust. There is also neon for writing nodejs extensions in rust. I haven't tried it but it looks like it might be possible to write an extension in rust and then add some glue code using PyO3 to create python extension and some glue code using neon to create nodejs extension. That way a certain module can be used in both  nodejs (JavaScript) and in Python.

There is also my experimental mini_leo project on github. It is far from being finished. It requires nightly version of cargo and rustc. The build_wheel.py script builds a python extension written in rust which can load .leo files and at-file nodes. With the following script on my new computer:

import timeit
from mini_leo import *
def f():
    t0 = load_leo('/opt/programi/leo/trunk/leo/core/LeoPyRef.leo')
    return t0
t1 = timeit.timeit(f, number=10)/10 * 1000
def f2(tr):
    res = []
    for lev, v in iternodes(tr):
        res.append('--'*(lev - 1))
        res.append(v.h)
        res.append('\n')
    return ''.join(res)
t3 = f()
def f3():
    return f2(t3)
print(f2(t3))
print('tree contains: %d'%tree_len(t3))
print("Loading speed average: %.2fms"%t1)
t1 = timeit.timeit(f3, number=100)/100*1000
print("Iterating speed average: %.2fms"%t1)

it loads LeoPyRef.leo along with all at-file nodes in less than 80ms.

The extension module has also an iterator of nodes which iterates tree of 9250 nodes in 7ms. Drawing tree with such an iterator shouldn't take too long.

Loading of other kinds of files is missing. Hopefully, I will find the time to finish loading all kinds of files.

Vitalije

[vitalije]

it loads LeoPyRef.leo along with all at-file nodes in less than 80ms.

The extension module has also an iterator of nodes which iterates tree of 9250 nodes in 7ms. Drawing tree with such an iterator shouldn't take too long.

Oh, and it doesn't use multi processor cores at all. Loading external files is a perfect job for parallelization. It might be even 2-8 times faster depending on how many cores your processor have. But even on a single thread it is quite fast.

The build_wheel.py script builds mini_leo and places resulting wheel in dist folder. To install use `pip install dist/mini_leo-0.1.0-py3-none-linux_x86_64.whl`.

I remember testing it on the windows too, but I haven't tried it recently.

Vitalije

[Edward K. Ream]

On Mon, Mar 16, 2020 at 10:06 AM vitalije <vita...@gmail.com> wrote:

> You should take a look at [PyOxidizer, PyO3 , neon , and mini_leo].

 

Thanks for these links. I've bookmarked them all. I am relying on you to keep me informed about rust-related developments.

Edward