Fix return type annotation for asyncio.Task.get_coro()

[ZeroIntensity]

This closes #12440.

[ZeroIntensity]

This is bug in AnyIO (as in, it does not support eager_task_factory), as found when debugging this issue report.

[JelleZijlstra]

Should this be made conditional on the version? The CPython docs imply that before 3.12 it could not return None.

[ZeroIntensity]

Should this be made conditional on the version? The CPython docs imply that before 3.12 it could not return None.

Oh, that's right, I'll update it.

[ZeroIntensity]

Issue in AnyIO opened: agronholm/anyio#764

[graingert]

I'm not sure why eager task factory can't return the coro it's passed, this seems like a cpython bug

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

anyio (https://github.com/agronholm/anyio)
+ src/anyio/_backends/_asyncio.py:335: error: Argument 1 to "getcoroutinestate" has incompatible type "Coroutine[Any, Any, Any] | None"; expected "Coroutine[Any, Any, Any]"  [arg-type]
+ src/anyio/_backends/_asyncio.py:1845: error: Argument 4 to "__init__" of "TaskInfo" has incompatible type "Coroutine[Any, Any, Any] | None"; expected "Generator[Any, Any, Any] | Awaitable[Any]"  [arg-type]

[ZeroIntensity]

I think it's intentional, and apparently it helps performance: see here.

[kumaraditya303]

It is done deliberately, it help performance as it clears cycle refs.

[graingert]

It seems obvious that asyncio.eager_task_factory(loop, coro).get_coro() can return the coro without being a breaking change.

I suspect that performance increase was added without realising it's a breaking change, that would need a deprecation warning and 3 releases

[JelleZijlstra]

I merged this as it reflects the documented behavior of CPython. If you want to change CPython's behavior, open an issue on the CPython repo.