chitralverma commented on PR #6622: URL: https://github.com/apache/opendal/pull/6622#issuecomment-3402847465
> What are the limitations? @Xuanwo your comment is in ref to point 1 in my message earlier. the snippet your shared is a simpler version of `future_into_py_async` that i attached above, please take a look. the difference between option 1 (self implemented `future_into_py_async`) and existing approach (pyo3_async_runtimes's `future_into_py`) is as following: --- ### Short answer They’re similar in purpose but serve different roles. ### Long answer #### High-Level Comparison | Aspect | future_into_py_async | pyo3_async_runtimes::future_into_py | | :--- | :--- | :--- | | **Return type** | `PyResult<T>` (awaits Rust side, returns result) | `PyResult<Bound<PyAny>>` (a Python `asyncio.Future`) | | **Runs inside Rust** | Yes — your async method awaits it fully before returning to Python | No — it returns control to Python immediately, and Python awaits the future | | **Python integration** | Minimal — looks like a normal `async fn` to PyO3 | Deep — integrates with Python's event loop (TaskLocals) | | **Cancellation** | needs [more work](https://pyo3.rs/v0.26.0/async-await#cancellation) to do this | Full support (cancellation, contextvars, error propagation) | | **Error handling** | handled `JoinError` manually | Handles panics, cancellation, and wraps into Python exceptions | | **Use case**| Async inside PyO3 `async` functions (you await in Rust) | Async from sync `PyO3` methods (return Python awaitables to user) | --- #### Conceptual Difference: Two Approaches to Async Bridging There's a fundamental difference in the design and use case between the standard `future_into_py` and the proposed `future_into_py_async` helper. ##### `pyo3_async_runtimes::future_into_py` This function acts as a **bridge from Rust to Python's event loop**. * **Analogy**: "Here, Python, take this promise (`asyncio.Future`). I'll tell you when the work is done." * **How it works**: It immediately returns a Python `asyncio.Future` object to the caller. The Python event loop then takes control and `await`s this future. Meanwhile, Rust spawns the work in the background. * **Integration**: It provides deep, "heavyweight but correct" integration, handling cancellation, contextvars, and proper error propagation between the two runtimes. * **Use Case**: The canonical way to expose a Rust `async` operation to Python from a **synchronous** Rust function. --- ##### The proposed `future_into_py_async` This function is a **self-contained async operation within Rust**. * **Analogy**: "Wait here. I'm going to finish this Rust task, and I'll give you the final result when I'm back." * **How it works**: It is an `async fn` itself that `await`s the given Rust future *completely within Rust*. It only returns the final, concrete `PyResult<T>` to Python after the Rust-side `await` is complete. * **Integration**: Minimal. From PyO3's perspective, it's just another `async` function. It doesn't manage Python futures or interact with the event loop. * **Use Case**: A helper for running a `Send`-able Rust future *inside* an existing `async` PyO3 method. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
