Use default trait implementations for runtime interfaces (e.g., `future_into_py`) instead of free functions

[Varixer]

In the current architecture, to support specific Rust runtimes, each runtime interface requires explicitly defining a free function in its respective module that calls the identically named function in the generic module, passing the corresponding runtime generic parameter R.

// src/async_std.rs
pub fn future_into_py<F, T>(py: Python, fut: F) -> PyResult<Bound<PyAny>>
where
    F: Future<Output = PyResult<T>> + Send + 'static,
    T: for<'py> IntoPyObject<'py> + Send + 'static,
{
    generic::future_into_py::<AsyncStdRuntime, _, T>(py, fut)
}

// src/generic.rs
pub fn future_into_py<R, F, T>(py: Python, fut: F) -> PyResult<Bound<PyAny>>
where
    R: Runtime + ContextExt,
    F: Future<Output = PyResult<T>> + Send + 'static,
    T: for<'py> IntoPyObject<'py> + Send + 'static,
{
    future_into_py_with_locals::<R, F, T>(py, get_current_locals::<R>(py)?, fut)
}

This design results in significant code duplication across runtime modules, differing only in the runtime generic parameter R passed. Additionally, supporting new runtimes requires copying this code. To eliminate this duplication, I propose using default trait implementations to encapsulate the free functions within the generic module.

pub trait HybridRuntimeMethods<R> {
    ...
    fn future_into_py<F, T>(py: Python, fut: F) -> PyResult<Bound<PyAny>>
    where
        R: Runtime + ContextExt,
        F: Future<Output = PyResult<T>> + Send + 'static,
        T: for<'py> IntoPyObject<'py> + Send + 'static,
    {
        Self::future_into_py_with_locals::<F, T>(py, Self::get_current_locals(py)?, fut)
    }
    ...
}

pub struct HybridRuntime<R>(PhantomData<R>);

impl<R> HybridRuntimeMethods<R> for HybridRuntime<R> {}

By using the blanket implementation impl<R> HybridRuntimeMethods<R> for HybridRuntime<R> {} to provide the default implementation, runtime modules no longer need to define these functions explicitly. They can be used directly as shown below:

use pyo3::{prelude::*, wrap_pyfunction};

use pyo3_async_runtimes::generic::HybridRuntimeMethods;
type HybridRuntime = pyo3_async_runtimes::generic::HybridRuntime<async_std_runtime::AsyncStdRuntime>;

#[pyfunction]
fn rust_sleep(py: Python) -> PyResult<Bound<PyAny>> {
    HybridRuntime::future_into_py(py, async {
        println!("sleeping for 1s");
        async_std::task::sleep(std::time::Duration::from_secs(1)).await;
        println!("done");
        Ok(())
    })
}

#[pymodule]
fn async_std_rs_sleep(py: Python, m: &Bound<'_, PyModule>) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(rust_sleep, m)?)?;
    Ok(())
}

[kylebarron]

If this project were being newly created today, I think your design could potentially make more sense (I don't think async traits were as stable when this project was created).

However, this project is more or less in maintenance mode at the moment because there's no primary maintainer putting in the time or effort into new features, and it's more or less feature complete. Furthermore, hopefully in the future pyo3 will get native async support that means pyo3-async-runtimes and its workarounds can be deprecated.

Just changing the functional approach to a trait approach seems like it would just cause churn of breaking changes. Are you actually desiring new runtimes beyond the existing two?

[davidhewitt]

For what it's worth, I'm hoping to carve out time in the short-mid term to continue PyO3's native async support. I think this crate may continue to be relevant after that support is improved as a way to interface with the various async runtimes. async-std is no longer relevant, and we could work to remove that here, however I think smol is now an alternative we may want to consider.

[kylebarron]

I don't know enough about the varying rust async runtimes. Should we remove async-std?

I'm excited for pyo3-native async support, especially if it has the potential of improved performance/less overhead, though I haven't spent any time reading the background in the linked issue.

[davidhewitt]

https://crates.io/crates/async-std - all I know is that it very directly describes itself as deprecated for smol. I would think we could similarly add smol support here (maybe via the trait described in the OP? I haven't thought hard about the design), and mark the async-std features as deprecated for a couple of versions.

The PyO3 native async support will be as low cost as we can make it, what that overhead will be at the end is unclear. Should hopefully be faster than what's in this crate, but I want to make it unaware of Rust executors.

[0x676e67]

The experimental support for native asynchronous in PyO3 has shown that the scheduling performance in my benchmark tests is indeed better than that of pyo3-async-runtimes. The CPU time slice occupancy has decreased significantly compared to the previous period.

[ararog]

Since I'm working on add Python (WSGI, ASGI and RSGI) support into vetis, and project has support for both tokio and smol, this is kinda of critical for me. I can help on add smol support to this crate.

I've read few times what granian did to make async callables possible there, but I think pyo3 is the place where this can be done in an even better and performant way.

[davidhewitt]

A PR for smol support would be very welcome!

[ararog]

A PR for smol support would be very welcome!

I tested smol and pyo3 together in my project with some success, as soon as I start working on add ASGI/RSGI support, I will add smol support on pyo3-async-runtimes.