Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate event_loop fixture overrides #311

Closed
seifertm opened this issue Mar 17, 2022 · 3 comments
Closed

Deprecate event_loop fixture overrides #311

seifertm opened this issue Mar 17, 2022 · 3 comments

Comments

@seifertm
Copy link
Contributor

seifertm commented Mar 17, 2022

There have been multiple feature requests for setting loop exception handlers (#205) and canceling tasks after the event loop has closed (#222, #309). I believe pytest-asyncio is not just about being able to write async tests, but about helping people to write good async code with pytest. That's why I think those requests are warranted.

All feature requests propose to add additional code to the event_loop fixture. However, a fair amount of pytest-asyncio users override the fixture, in order to control its scope. These overrides prevent us from extending the event_loop fixture for existing users. We could ask them to extend their override functions manually, but the fixture definition could become very length (see the code required for task and generator cleanup code in CPython)

I propose to deprecate overrides of the event_loop fixture. This allows the pytest-asyncio developers to modify and extend the event_loop fixture behaviour with special setup code (e.g. loop exception handlers) and teardown code (e.g. task cleanup, raising warnings, etc.).

The additional functionality of the event_loop fixture could be handled in a modular way. Pytest configuration options, for example, can serve as feature flags for new functionality, which would also improve our stability guarantees for new releases.

The fixture scope would be controlled with the asyncio_loop_scope = "session" setting. Other features would add similar settings, e.g. asyncio_exceptions = "raise" to address #205.

Maybe this could be our way towards pytest-asyncio v1.0? I'd be happy to hear your feedback on this idea!

@asvetlov
Copy link
Contributor

Regarding task cancellation etc.
Could proposed improvements be done in pytest_fixture_setup / pytest_fixture_post_finalizer?

Also, Python 3.11 will likely have asyncio.Runner context manager that simplifies the loop cleanup. Maybe we can build our system on top of a runner instead of the event loop?
Sure, the feature backporting could be nontrivial (python/cpython#31837 is absent in 3.10) but still possible.

@seifertm
Copy link
Contributor Author

Regarding task cancellation etc.
Could proposed improvements be done in pytest_fixture_setup / pytest_fixture_post_finalizer?

This would only work, if the user does not provide their own def event_loop. Otherwise, the loop will likely be closed when the fixture finalizer starts.

Also, Python 3.11 will likely have asyncio.Runner context manager that simplifies the loop cleanup. Maybe we can build our system on top of a runner instead of the event loop?

This is really interesting! Let's park my proposal until we get to experiment with asyncio.Runner then :)

Linking the relevant issues for reference:
https://bugs.python.org/issue47062
python/cpython#31799

@seifertm
Copy link
Contributor Author

@asvetlov If I understand correctly, asyncio.Runner and aioloop-proxy are competing solutions. Is that right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants