[3.13] gh-133745: Fix asyncio task factory name/context kwarg breaks

[graingert]

• Issue: Breaking API Change in Python 3.13.3: Task Factory Signature Change #133745

[gvanrossum]

I think this is the right thing, just one refactoring suggestion.

We should ask Alice to try this (maybe after it's in the nightly builds).

[gvanrossum]

To be clear, this is supposed to happen instead of the rollback, right?

[graingert]

To be clear, this is supposed to happen instead of the rollback, right?

that's my understanding, yet

[gvanrossum]

Despite what the comment says, you're just removing the try/except here. Was that intentional?

[graingert]

Despite what the comment says, you're just removing the try/except here. Was that intentional?

Ah it looks like that in the diff, but I also added an else and removed the early return. Execution follows after the if/else and returns the task deleting it 'after' the return

[gvanrossum]

Got it. What's difficult or controversial about the news fragment? Just that we're waffling about the feature? I think it's reasonable to say something like this:

In 3.13.3 we accidentally changed the signature of create_task() and how it calls a custom task factory in a backwards incompatible way. Since some 3rd party libraries have already made changes to work around the issue that might break if we simply reverted the changes, we're instead changing things to be backwards compatible with 3.13.2 while still supporting those workarounds. In particular, the special-casing of name and context is back (until 3.14) and consequently eager tasks may still find that their name hasn't been set before they execute their first line of code.

WDYT? If you agree, let's merge this.

[graingert]

do we want to say create_task() family of methods or just list out them all: loop.create_task, TaskGroup.create_task and asyncio.create_task

[gvanrossum]

I see no strong reason to spell them all out -- the 3.13.3 changes affect all methods named create_task and only those.

[gvanrossum]

I am happy with the code and the news blurb.

I'd like @kumaraditya303 to review this too, to be extra sure that we don't have to backtrack more in 3.13.5.

And don't we need something in the docs about this change? I just noticed that it looks like the previous change didn't even have a versionchanged (3.13.3) directive. We should add that retroactively, and another versionchanged (3.13.4) mentioning what we changed there.