Pyo3: Define async functions

[thedrow]

Currently there's no way to define async functions for classes and functions.
It'd be crucial for Celery's usecase to be able to define those.

I suggest the using an annotation:

#[pyasync]
fn foo() -> PyAsyncResult<int> {
  // do some stuff
  1;
}

[konstin]

Without someone properly defining the semantics of how rust's async and pythons async interact, this out of scope for pyo3. Same for #410

[thedrow]

So you're saying we cannot use asyncio inside rust without unsafe code?

[konstin]

No, but it's incredibly complex to make the interaction between rust futures and python futures sound. It's definitely nothing that can be done with just an annotation and a new return type.

[thedrow]

I suggest that we do not interop between those two for the time being.
We should however allow to use Python's Co-routines.

[konstin]

Could you elaborate why you want to define async functions if you can't really interact with python's async? E.g. a pyawait! macro would require the function to become a generator which afaik is only properly possible by using the async fn and wrapping rust's futures mechanism.

[thedrow]

What you are describing is the optimal solution.

The initial implementation of pyawait!(coro_obj) could translate to:

PyDict d = PyDict::new();
d.set_item('coro_obj', coro_obj);
py::eval("await coro_obj", Some(d));

Or something similar.
Would this segfault?

[thedrow]

Alternatively, we should simply call the equivalent CPython API.

[pganssle]

IMO, pyo3's role should be to provide safe Rust access to Python's C API, so doing something complicated like providing await and coroutine support directly in PyO3 seems unnecessary, particularly this early in the game.

It would make sense to me to add safe wrappers around whatever's supported in the C API (Async Object Structures is all I could find with a cursory look), and leave it to other libraries to introduce things like pyawait! and other "nice" interfaces for async/await.

If async/await support were less complex, or if the interfaces were more mature (both on the Python and Rust sides), I'd be more in favor of a fancy wrapper, but I think at this point in time a conservative approach that enables helper crates to experiment with the interface makes the most sense to me.

[konstin]

Closing as out of scope