pyo3 | Rust bindings for the Python interpreter

First Part: (Explanation)

Since a is the owner of the value and you are passing reference using the owner which will remain in scope even after execution but in the case when you directly pass &urlpath.to_string() there isn't any owner and as soon the execution ends the value would be dropped and there will be a dangling reference which is the cause for the message.

Second Part: (Python to rust conversion)
I am not a crypto expert but I tried to convert the same script you provided without the condition part and matched the output in python and rust.

So I ended up figuring it out:

@jakub's solution ended up solving the problem for me. I uninstalled the version of rust that was installed through pacman. To replace it, I installed rustup and then using rustup, installed the latest nightly version of rust (1.60). Once I did that, installing the cryptography package worked just fine.

If you are using rustup, just make sure that you add ~/.cargo/bin to your PATH before installation. Also, the command I used to install rust through rustup was rustup toolchain install nightly.

The problem is that serde_json::Value doesn't implement the pyo3::conversion::ToPyObject trait. You can't implement that yourself either, since you can't implement a foreign trait on a foreign object.

What you can do is wrap your serde_json::Value and implement the trait on that. Something like this should work (untested):

I don't think what you say is possible without some rejigging of the interface:

Your XWrapper owns the x and your Y owns its x as well. That means creating an XWrapper will always involve a clone (or a new).

Could we change XWrapper so that it merely contains a reference to an x? Not really, because that would require giving XWrapper a lifetime annotation, and PyO3 afaik doesn't allow pyclasses with lifetime annotation. Makes sense, because passing an object to python puts it on the python heap, at which point rust loses control over the object.

So what can we do?

Some thoughts: Do you really need to expose the composition structure of y to the python module? Just because that's the way it's organized within Rust doesn't mean it needs to be that way in Python. Your YWrapper could provide methods to the python interface that behind the scenes forward the request to the x instance:

I found a way to do this using Maturin. So, in case anyone else is trying to find out how to do this, here's one way.

The project needs to have the following structure:

I managed to solve it by adding this to cargo.toml file

The fix that Ry suggests, seems to work well. Using for<'p> lets the compiler defer evaluation of the lifetime until it's needed when processing the code that calls .extract(). And the lifetime, 'p, doesn't need to be specified in the function's generic parameter list. Also, the Clone bound wasn't required.

If you have power over the function signature, you can just change it to fn f(slf: Py) -> A

I prefer this method, wherever possible, because then the conversion just happens under the hood.

If you need to keep the signature general because you might be returning structs of different types, you need to invoke the correct conversion method.

A struct marked with #[pyclass] will have IntoPy implemented, but the conversion method isn't called to_object but rather into_py, and it wants a gil token. So here's what you do: