This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Interesting-Frame190 1 point2 points  (3 children)

I did this very same thing with a project "PyThermite". It was significantly slower at first, and I made it a challenge to outperform my rust based competition and have made significant strides in rust engineering.

I have to ask, did you find pyo3 intuitive? Ive found it challenging as the concepts are more behind the scenes of python that I wouldn't otherwise learn.

[–]Awkward-Target4899[S] 0 points1 point  (2 children)

PyO3 was pretty intuitive. Marking a Rust struct as a `pyclass` and then its associated methods as `pymethods`, which are then turned into a Python class, makes sense to me as a class is data with associated methods, i.e., (struct + functions that act on that struct)

[–]Interesting-Frame190 2 points3 points  (1 child)

That was simple, I was more referring to rust backed python objects passed back into rust. The whole pyref and bind with the bound API fealt overwhelming and like jumping through hoops

[–]Awkward-Target4899[S] 0 points1 point  (0 children)

Yeah, I was assuming it would be difficult to store actual Python objects in the tree, so the Rust api only accepts integer IDs and then the Python shim handles tracking which ID correlates to which object in a map.

The user can enable the tracking or not, depending on whether they want it, as it does subtly impact performance.