Remove explicit loop from asyncio tests #5353
Conversation
|
The failures do seem to be related, but I do not understand them as I tested with 3.9 and 3.10 and this seemed to have worked. |
|
Hmm, no, actually, locally it didn't fail, but a scratch build in koji did. So it seems flaky to do this exactly. I guess the queue must be created when the right loop is running, and not pre-created. |
QuLogic
force-pushed
the
drop-event-loop
branch
from
1535ed6 to
f78696e
Compare
QuLogic
changed the title
|
The explicit loop in asyncio code was removed by #5709, so I've changed this to just remove the loop from the tests. |
In 3.10, the _internal_ `_loop` attribute of several asyncio classes has been removed.
|
The failing test appears unrelated. |
|
|
||
|
|
||
| @pytest.mark.skipif( | ||
| sys.version_info >= (3, 10), reason="No internal loop in Python 3.10" |
There was a problem hiding this comment.
the "_loop" attribute is there in 3.10 - it's just late bound: https://github.com/python/cpython/blob/8acbb93c0763fa53b5959fe05d86ba275c9e8a5b/Lib/asyncio/mixins.py#L28
the tests could be modified to use the asyncio resource first so the loop is always bound before the assert, eg:
await c.gather([c.submit(...)])
assert c._gather_semaphore._loop
|
Replaced by #5952. |
3 participants
In Python 3.5.3 and 3.6, the
get_event_loopreturned the expected result always, so in Python 3.8, this parameter was deprecated and in 3.10 it was removed.pre-commit run --all-files