use inline_python::python;
let who = "world";
let n = 5;
python! {
for i in range('n):
print(i, "Hello", 'who)
print("Goodbye")
}
The nice thing about this, if you get the power of Python to handle your data loading, scrubbing, validation, etc and then spend the bulk of your high performance work in Rust.
Layout is king, so structuring your code to have compact, native layout will not only make it much easier to call compiled code, it will vastly reduce your memory requirements.
I never understood the use case for embedding python in rust. In my experience the actual high performance code is a small portion of the overall code base, and writing all the glue code file processing, plotting is typically much faster in python due to the excellent excellent ecosystem. I further forgo the ability to use the python repl if I do it this way around.
Don't get me wrong I like rust, but I would always write the high performance code to be a module that can be imported in python, write everything in rust and the use python for some specific functions only.
I used to think that too, and both techniques have merit. The extending vs embedding debate has gone since Python was created, but much of that has been shaped by the difficulty in actually embedding Python, so I found myself convincing myself that embedding is the wrong choice.
Contrast that with Lua where embedding and extending are about the same difficulty, there one is more likely to pick the technique that best fits the situation.
One thing that is really nice about calling into Python when you need it but otherwise using your calling language and runtime is you get all the semantics of your calling language to structure the codebase and use Python as a library where needed. This is esp nice when you have security or concurrency properties that you need to hold, or if you were bootstrapping a project with Python and all of its wonderful libraries but eventually will replace or reduce the script code.
One semantic nit, you probably do understand it, you just don't like it. If I have a big ETL that has lots of parts that need to run in Rust, but the cleanup code would be much easier to write in Python, I don't need a to turn my ETL into a library.
https://docs.rs/inline-python/latest/inline_python/
The nice thing about this, if you get the power of Python to handle your data loading, scrubbing, validation, etc and then spend the bulk of your high performance work in Rust.Layout is king, so structuring your code to have compact, native layout will not only make it much easier to call compiled code, it will vastly reduce your memory requirements.
chunk can now be used as a fixed size array. And chunk can be passed by reference in native code (Zig, Rust, Fortran, etc).