Please restore the loop param to staggered.staggered_race

Bug report

Bug description:

The following remove the loop param from staggered.staggered_race :

#124390
#124574
#124573

~~its wasn't scheduled for removal until 3.16~~ this never merged

CPython versions tested on:

3.12, 3.13, CPython main branch

Operating systems tested on:

No response

Linked PRs

Hello!
Thanks for the report.

asyncio.staggered_race should not be used directly. It is a private API that is not documented anywhere in the documentation. If you want to use staggered_race, please install the 3rd party package async-stagger: https://github.com/twisteroidambassador/async_stagger.

Its a bit unexpected to have deprecation warnings in it given its not intended for public use. Its also not possible to use https://github.com/twisteroidambassador/async_stagger since it only supports python 3.11+ https://github.com/twisteroidambassador/async_stagger/blob/e09eeefd5d5c123d79abb8ac7f1b5583e8ff3203/setup.py#L30

@Eclips4

FWIW, there was no deprecation emitted. That got removed right before the PR got merged. @Eclips4 should we reopen this? I guess this is too much of a breaking change for a patch release.

@bdraco

@bdraco, we're going to add back the loop parameter for 3.12. (I'm not sure what the deprecation plan is, I think it's supposed to be 3.14?)

Anyways, this will allow use of eager_task_factory on prior aiohttp versions. However, we're officially marking staggered_race as a private API (and will rename it to _staggered_race). Please copy the current implementation into third parties for future use, as we're not guaranteeing any future support past 3.12 (or maybe 3.13, I think that's undecided).

pythonGH-124639: add back loop param to staggered_race (python#124700)

[3.12] GH-124639: add back loop param to staggered_race (GH-124700) (#…

What's the purpose of the loop kwarg here? Is it to avoid an expensive call to get_running_loop? If so adding the assertion will just remove that perf fix

What's the purpose of the loop kwarg here? Is it to avoid an expensive call to get_running_loop? If so adding the assertion will just remove that perf fix

At this point the concern is historical compatibility only as get_running_loop is so much faster in newer cpython.

The new implementation doesn't seem to handle multiple winners in the same iteration of the event loop as we received aio-libs/aiohappyeyeballs#100 today

Traceback (most recent call last):
  File "/opt/homebrew/Caskroom/miniforge/base/envs/work/lib/python3.12/site-packages/aiohappyeyeballs/_staggered.py", line 85, in run_one_coro
    assert winner_index is None  # noqa: S101
           ^^^^^^^^^^^^^^^^^^^^
AssertionError

I was able to write a test to simulate the problem https://github.com/aio-libs/aiohappyeyeballs/blob/e3519bbebf2069eee0aff0dfde50689c742ba97f/tests/test_staggered.py#L33

    loop = asyncio.get_running_loop()
    winners = []
    finish = loop.create_future()

    async def coro(idx):
        await finish
        winners.append(idx)
        return idx

    coros = [partial(coro, idx) for idx in range(4)]

    task = loop.create_task(staggered_race(coros, delay=0.00001))
    await asyncio.sleep(0.1)
    loop.call_soon(finish.set_result, None)
    winner, index, excs = await task

I ended up writing a new implementation for aiohappyeyeballs that should work on 3.8-3.13+ https://github.com/aio-libs/aiohappyeyeballs/blob/main/src/aiohappyeyeballs/_staggered.py

Revert "pythonGH-124639: add back loop param to staggered_race (pytho…

gh-124309: Revert eager task factory fix to prevent breaking downstre…

pythongh-124309: Revert eager task factory fix to prevent breaking do…

[3.12] gh-124309: Revert eager task factory fix to prevent breaking d…

Closing as the change was reverted in all branches

@bdraco

I would like to concur with @bdraco that the new implementation (the one being reverted here) does not handle multiple winners.

This implementation cancels the entire task group by raising an exception when a coroutine wins. This cancellation is not immediate, in the sense that other tasks in the same group may get chances to run before being cancelled, which may result in multiple winners.

I believe (but haven't checked) that my new implementation is compatible with eager task factories: https://github.com/twisteroidambassador/async_stagger/blob/master/async_stagger/stagger.py

I thought we fixed this with a separate implementation already.

I thought we fixed this with a separate implementation already.

Right, I see it now. Thanks!

Navigation Menu

Repository navigation

Please restore the loop param to staggered.staggered_race #124639

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

24 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Please restore the loop param to staggered.staggered_race #124639

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

Eclips4 commented on Sep 26, 2024

bdraco commented on Sep 26, 2024

ZeroIntensity commented on Sep 26, 2024

ZeroIntensity commented on Sep 26, 2024

24 remaining items

graingert commented on Sep 29, 2024

bdraco commented on Sep 29, 2024

bdraco commented on Sep 30, 2024

kumaraditya303 commented on Oct 27, 2024

twisteroidambassador commented on Nov 14, 2024

ZeroIntensity commented on Nov 14, 2024

twisteroidambassador commented on Nov 15, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions