pyo3-asyncio & references

[diliop]

Been scratching my head on whether the bellow is feasible or not for a while now. Read a couple of similar questions both here and in pyo3-asyncio but have not found a definitive answer. Here is what I'm trying to do:

I have an async function defined elsewhere that accepts &str and returns String. I need to wrap said function and expose it to Python by doing the following:

// external_lib
async fn async_echo_string_ref(arg: &str) -> String {
    arg.to_string()
}

// lib
#[pyfunction]
pub fn async_echo_string_ref(py: Python, input: PyObject) -> PyResult<Bound<PyAny>> {
    let _input = input.extract(py)?;
    pyo3_asyncio::tokio::future_into_py(py, async move {
        let _res = external_lib::async_echo_string_ref(_input).await;
        Python::with_gil(|gil| Ok(_res.into_py(gil)))
    })
}

which generates this error:

error[E0521]: borrowed data escapes outside of function
  --> fbcode/scripts/diliopoulos/pyo3/rs/src/asynchronous.rs:56:5
   |
54 |   pub fn async_echo_string_ref(py: Python, input: PyObject) -> PyResult<Bound<PyAny>> {
   |                                --
   |                                |
   |                                `py` is a reference that is only valid in the function body
   |                                has type `pyo3::Python<'1>`
55 |       let _input = input.extract(py)?;
56 | /     pyo3_asyncio::tokio::future_into_py(py, async move {
57 | |         let _res = __external_lib::async_echo_string_ref(_input).await;
58 | |         Python::with_gil(|gil| Ok(_res.into_py(gil)))
59 | |     })
   | |      ^
   | |      |
   | |______`py` escapes the function body here
   |        argument requires that `'1` must outlive `'static`

I understand that future_into_py expects the future passed in to be 'static so I could instead pass _input as String. But I'm trying to understand if there is a way to avoid doing that or a more general way to do this assuming that I also need to handle Vec<&str>, Vec<Vec<&str>> etc. as inputs.

[davidhewitt]

Sorry for the slow reply. The general problem here is that extraction of data from Python types will need the py token to pull the data out safely, but in cases like strings the immutability on the Python side means we don't actually need to have the py token once we've done the extraction.

If you're using pyo3-asyncio, that presumably means you're still on PyO3 0.20 and the .extract() function for &str will tie the &str to the lifetime of py unnecessarily. After migrating off the gil-refs API in 0.21, that connection is broken but instead you will be borrowing from input which leads to similar complications.

Fortunately in PyO3 0.21 we also added PyBackedStr which fit exactly what you need here - it's &str compatible but borrows data from Python. Unfortunately, that means pyo3-asyncio needs to upgrade.

I think it's probably time that the PyO3 organisation helped maintain pyo3-asyncio, but it looks like the maintainer is absent at the moment so we might need to consider forking (temporarily?) so bring support. awestlake87/pyo3-asyncio#126

[diliop]

Thanks for the explanation! I will give PyBackedStr a try and see how much change is needed to support that in pyo3-asyncio on top of the changes for supporting PyO3 0.21.

I think it's probably time that the PyO3 organisation helped maintain pyo3-asyncio, but it looks like the maintainer is absent at the moment so we might need to consider forking (temporarily?) so bring support. awestlake87/pyo3-asyncio#126

I second that! pyo3-asyncio has been around for a couple of years now which leads me to believe that similar to myself, there are plenty of PyO3 users out there that use it as their default crate for async support. A temporary fork would be quite warranted given first and foremost, the need for supporting PyO3 0.21 which is quite long overdue. There are 2 PRs up already for doing that so I think the need is there.

[davidhewitt]

Looping back here - I've now published https://crates.io/crates/pyo3-asyncio-0-21 which should unblock you on updating to PyO3 0.21.

[diliop]

Thanks @davidhewitt, somehow I missed this :(