Loop Factory parameter for asyncio mark

[Vizonex]

After mentally thinking about this back and forth. I decided to step to the plate and try and fix this problem once and for all.
The aiohttp developers have told me they had a bit of intrest utilizing this library and so would I with my plans to migrate from unittest to pytest for winloop and a new project coming that aims to upgrade & migrate pycares to cython, which I've added my own deadline that I would move winloop to pytest by 2026. And yes aiothreading which aims to be an alternative to aiomultiprocess for users with slower hardware or providing safer solutions for heavier loads.

While talking with the aiohttp devs on the matrix about the problem. I decided to see if I could have a crack at providing a way to run eventloops without needing to use deprecated setups. Unfortunately I'm extremely picky about deprecated setups This might be a good thing however because the sooner someone does something to solve the problem the better.

[Vizonex]

Can't seem to figure out where I should inject this new function I made. When I would go to run tests they would fail.

[seifertm]

Testing with different event loops is definitely something we want to support in pytest-asyncio. Currently, there's an event_loop_policy fixture for this purpose.

Can you explain why the existing approach is insufficient for your use cases?

[Vizonex]

Testing with different event loops is definitely something we want to support in pytest-asyncio. Currently, there's an event_loop_policy fixture for this purpose.

Can you explain why the existing approach is insufficient for your use cases?

@seifertm I would love to, as of right now eventloop policies are deprecated and planned for removal in 3.16 my goal is to provide a workaround that doesn't involve silencing warnings and allows for the EventLoopPolicy to remain temporarly but redirect users to using a non-deprecated approach sooner than later.

• SEE: https://docs.python.org/3.14/library/asyncio-policy.html#asyncio.AbstractEventLoopPolicy

I'm trying to catch up with these changes by allowing for a different fixture method to be used I would like to save this library from simply having to keep a warning silent which I would argue is a bad approach to solving a problem. Sooner it's changed the better.

[seifertm]

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'd like to avoid configuring the loop type through a fixture, though, for two reasons:

1. A fixture invites users to add extra code that is unrelated to the configuration of the loop type. This makes it significantly harder for pytest-asyncio to ship non-breaking changes and is one of the main reasons the event_loop fixture got removed. I believe you mentioned in your other issue that you're familiar with the history, so I won't get into it.
2. The current event_loop_policy fixture takes the same approach as the new_event_loop fixture in this PR. The autouse configuration causes non-async tests to be parametrized, leading to sync tests being executed twice (see Parametrizing event_loop_policy parametrizes all tests #796). To my knowledge, there's currently no way to apply autouse selectively.

I'm currently leaning towards a configuration setting in pyproject.toml dor a global parametrization of loop types. I don't really like it, so I'm open for alternative suggestions :) It definitely needs some more thought.

Besides parametrizing globally, we also want users to be able to override the loop type for specific tests (see #1032 #1101). Users should be able to pass a loop_factory keyword argument to the asyncio marker. For example:

@pytest.mark.asyncio(loop_factory=uvloop.new_event_loop)
def test_run_with_uvloop():
    ...

If you're interested in working on the pytest.mark.asyncio(loop_factory=...) support, I'll definitely support it!

[Vizonex]

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'd like to avoid configuring the loop type through a fixture, though, for two reasons:

1. A fixture invites users to add extra code that is unrelated to the configuration of the loop type. This makes it significantly harder for pytest-asyncio to ship non-breaking changes and is one of the main reasons the event_loop fixture got removed. I believe you mentioned in your other issue that you're familiar with the history, so I won't get into it.
2. The current event_loop_policy fixture takes the same approach as the new_event_loop fixture in this PR. The autouse configuration causes non-async tests to be parametrized, leading to sync tests being executed twice (see Parametrizing event_loop_policy parametrizes all tests #796). To my knowledge, there's currently no way to apply autouse selectively.

I'm currently leaning towards a configuration setting in pyproject.toml dor a global parametrization of loop types. I don't really like it, so I'm open for alternative suggestions :) It definitely needs some more thought.

Besides parametrizing globally, we also want users to be able to override the loop type for specific tests (see #1032 #1101). Users should be able to pass a loop_factory keyword argument to the asyncio marker. For example:

@pytest.mark.asyncio(loop_factory=uvloop.new_event_loop)
def test_run_with_uvloop():
    ...

If you're interested in working on the pytest.mark.asyncio(loop_factory=...) support, I'll definitely support it!

That would be a great solution actually. Thanks for helping me come up with a compromise, I'll see what I can do to make that happen.

[Vizonex]

Let me revert my changes and then I'll make new ones.

[Vizonex]

Guess the only thing I will have to figure out is where loop-factory should get executed I wanted to make it so that both Sequences of factories and singular factories could be accepted.

[Vizonex]

Now I think about it I am having trouble finding where to inject loop factories. I'll upload what I have so far and take a temporary break. But I'm trying to make it so that loop_factory can pass multiple factories and run them all.

[Vizonex]

This puzzle turned out to be bigger than I thought let me push what I have now so far...