Michael Seifert
Michael Seifert
Testing with different event loops is definitely something we want to support in pytest-asyncio. Currently, there's an [event_loop_policy fixture](https://pytest-asyncio.readthedocs.io/en/latest/how-to-guides/multiple_loops.html) for this purpose. Can you explain why the existing approach is...
I agree that the existing approach with the `event_loop_policy` needs to be replaced (see also #1032). I'd love to deprecate it, but we first need another solution, as you said....
I had another look at the edge cases and how to address them. To be honest, I don't think it's reasonable to implement the proposed API. The `loop_factory` argument to...
I also ran into this problem and wanted to share the use case leading me to this issue. Let's assume we have a Python module that contains pytest test cases....
It's hard to say without a reproducible example. It's possible that something inside TortoiseORM or aerich closes the loop prematurely. You can try gradually commenting out lines in your `sanic_app`...
Thanks for reporting this and for the great reproducer! To be honest, I never even heard of `GLibEventLoopPolicy` until now. NB: Pytest-asyncio wants to move away from the asyncio policy...
Pytest-asyncio gives the option to run more than one test in a single event loop via the `loop_scope` argument to [pytest.mark.asyncio](https://pytest-asyncio.readthedocs.io/en/stable/reference/markers/index.html#pytest-mark-asyncio). In your reproducer, there's just a single test that...
Thanks for pointing out this issue. I don't think pytest-asyncio has enough awareness of its performance, especially in large code bases. This could be a duplicate of #720. There has...
The pre-release `pytest-asyncio==1.0.0a1` creates significantly fewer fixtures, which should improve the collection performance. @davidparsson Please let us know whether this improves or solves the situation.
@davidparsson pytest-asyncio v1.0.0 is out and should address this issue.