commit
601d9573c8
|
@ -15,8 +15,8 @@
|
|||
- [Emulating numeric types](class/numeric.md)
|
||||
- [Emulating callable objects](class/call.md)
|
||||
- [Type conversions](conversions.md)
|
||||
- [Mapping of Rust types to Python types](conversions/tables.md)]
|
||||
- [Conversion traits](conversions/traits.md)]
|
||||
- [Mapping of Rust types to Python types](conversions/tables.md)
|
||||
- [Conversion traits](conversions/traits.md)
|
||||
- [Python exceptions](exception.md)
|
||||
- [Calling Python from Rust](python_from_rust.md)
|
||||
- [Using `async` and `await`](async-await.md)
|
||||
|
|
|
@ -30,7 +30,7 @@ Resulting future of an `async fn` decorated by `#[pyfunction]` must be `Send + '
|
|||
|
||||
As a consequence, `async fn` parameters and return types must also be `Send + 'static`, so it is not possible to have a signature like `async fn does_not_compile(arg: &PyAny, py: Python<'_>) -> &PyAny`.
|
||||
|
||||
However, there is an exception for method receiver, so async methods can accept `&self`/`&mut self`
|
||||
However, there is an exception for method receiver, so async methods can accept `&self`/`&mut self`.
|
||||
|
||||
## Implicit GIL holding
|
||||
|
||||
|
|
Loading…
Reference in New Issue