|
17 | 17 |
|
18 | 18 | > PyO3 Asyncio is a _brand new_ part of the broader PyO3 ecosystem. Feel free to open any issues for feature requests or bugfixes for this crate.
|
19 | 19 |
|
20 |
| -__If you're a new-comer, the best way to get started is to read through the primer below! For `v0.13` users I highly recommend reading through the [migration section](#migrating-from-013-to-014) to get a general idea of what's changed in `v0.14`.__ |
| 20 | +__If you're a new-comer, the best way to get started is to read through the primer below! For `v0.13` and `v0.14` users I highly recommend reading through the [migration section](#migration-guide) to get a general idea of what's changed in `v0.14` and `v0.15`.__ |
21 | 21 |
|
22 | 22 | ## PyO3 Asyncio Primer
|
23 | 23 |
|
@@ -521,7 +521,8 @@ fn main() -> PyResult<()> {
|
521 | 521 | - Managing event loop references can be tricky with pyo3-asyncio. See [Event Loop References](https://awestlake87.github.io/pyo3-asyncio/master/doc/pyo3_asyncio/#event-loop-references) in the API docs to get a better intuition for how event loop references are managed in this library.
|
522 | 522 | - Testing pyo3-asyncio libraries and applications requires a custom test harness since Python requires control over the main thread. You can find a testing guide in the [API docs for the `testing` module](https://awestlake87.github.io/pyo3-asyncio/master/doc/pyo3_asyncio/testing)
|
523 | 523 |
|
524 |
| -## Migrating from 0.13 to 0.14 |
| 524 | +## Migration Guide |
| 525 | +### Migrating from 0.13 to 0.14 |
525 | 526 |
|
526 | 527 | So what's changed from `v0.13` to `v0.14`?
|
527 | 528 |
|
@@ -615,7 +616,42 @@ __Before you get started, I personally recommend taking a look at [Event Loop Re
|
615 | 616 | - Replace `pyo3_asyncio::get_event_loop` with `pyo3_asyncio::<runtime>::get_current_loop`
|
616 | 617 | 5. After all conversions have been replaced with their `v0.14` counterparts, `pyo3_asyncio::try_init` can safely be removed.
|
617 | 618 |
|
618 |
| -> The `v0.13` API will likely still be supported in version `v0.15`, but no solid guarantees after that point. |
| 619 | +> The `v0.13` API has been removed in version `v0.15` |
| 620 | + |
| 621 | +### Migrating from 0.14 to 0.15 |
| 622 | + |
| 623 | +There have been a few changes to the API in order to support proper cancellation from Python and the `contextvars` module. |
| 624 | + |
| 625 | +- Any instance of `cancellable_future_into_py` and `local_cancellable_future_into_py` conversions can be replaced with their`future_into_py` and `local_future_into_py` counterparts. |
| 626 | + > Cancellation support became the default behaviour in 0.15. |
| 627 | +- Instances of `*_with_loop` conversions should be replaced with the newer `*_with_locals` conversions. |
| 628 | + ```rust no_run |
| 629 | + use pyo3::prelude::*; |
| 630 | + |
| 631 | + Python::with_gil(|py| -> PyResult<()> { |
| 632 | + let event_loop = pyo3_asyncio::get_running_loop(py)?; |
| 633 | + |
| 634 | + // *_with_loop conversions in 0.14 |
| 635 | + let fut = pyo3_asyncio::tokio::future_into_py_with_loop( |
| 636 | + event_loop, |
| 637 | + async move { Ok(Python::with_gil(|py| py.None())) } |
| 638 | + )?; |
| 639 | + // should be replaced with *_with_locals in 0.15 |
| 640 | + // |
| 641 | + // contextvars can be copied with `copy_context` or supplied |
| 642 | + // manually via `with_context` |
| 643 | + let fut = pyo3_asyncio::tokio::future_into_py_with_locals( |
| 644 | + py, |
| 645 | + pyo3_asyncio::TaskLocals::new(event_loop).copy_context(py)?, |
| 646 | + async move { Ok(()) } |
| 647 | + )?; |
| 648 | + |
| 649 | + Ok(()) |
| 650 | + }); |
| 651 | + ``` |
| 652 | +- `scope` and `scope_local` variants now accept `TaskLocals` instead of `event_loop`. You can usually just replace the `event_loop` with `pyo3_asyncio::TaskLocals::new(event_loop).copy_context(py)?`. |
| 653 | +- Return types for `future_into_py`, `future_into_py_with_locals` `local_future_into_py`, and `local_future_into_py_with_locals` are now constrained by the bound `IntoPy<PyObject>` instead of requiring the return type to be `PyObject`. This can make the return types for futures more flexible, but inference can also fail when the concrete type is ambiguous (for example when using `into()`). Sometimes the `into()` can just be removed, |
| 654 | +- `run`, and `run_until_complete` can now return any `Send + 'static` value. |
619 | 655 |
|
620 | 656 | ## Known Problems
|
621 | 657 |
|
|
0 commit comments