Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 17 commits into from
May 18, 2025

Conversation

graingert
Copy link
Contributor

@graingert graingert commented May 12, 2025

@graingert graingert changed the title gh-128308: Fix asyncio task factory name/context kwarg breaks gh-133745: Fix asyncio task factory name/context kwarg breaks May 12, 2025
@graingert graingert force-pushed the fix-name-passed-to-task-factory branch from f298146 to 5c3c953 Compare May 12, 2025 19:13
@graingert graingert changed the title gh-133745: Fix asyncio task factory name/context kwarg breaks [3.13] gh-133745: Fix asyncio task factory name/context kwarg breaks May 12, 2025
Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@graingert
Copy link
Contributor Author

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

that's my understanding, yet

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@graingert
Copy link
Contributor Author

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
Copy link
Member

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 graingert marked this pull request as ready for review May 14, 2025 08:16
Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@kumaraditya303 kumaraditya303 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, @graingert do you want to add the version changed entry?

@@ -238,18 +238,31 @@ Creating Tasks

-----------------------------------------------

.. function:: create_task(coro, *, name=None, context=None)
.. function:: create_task(coro, *, name=None, context=None, eager_start=None, **kwargs)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh hang on these didn't change until 3.14

Co-authored-by: Kumar Aditya <kumaraditya@python.org>
Comment on lines 379 to 385
An optional keyword-only *eager_start* argument allows eagerly starting
the execution of the :class:`asyncio.Task` at task creation time.
If set to ``True`` and the event loop is running, the task will start
executing the coroutine immediately, until the first time the coroutine
blocks. If the coroutine returns or raises without blocking, the task
will be finished eagerly and will skip scheduling to the event loop.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe we should document eager_start here at all. I doesn't require special treatment, it can just be put in **kwargs. It looks like we added this in 3.13.4, and such feature changes in a bugfix release are frowned upon. We should only advertise **kwargs as an unfortunate added in3.13.3 and fixed in 3.13.4.

Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks great! I will merge this now.

@gvanrossum gvanrossum merged commit fd6a602 into python:3.13 May 18, 2025
39 checks passed
@gvanrossum
Copy link
Member

Thanks Thomas for moving this forward! Hopefully this is the end of the story for 3.13. For 3.14 I think we ought to add a bit to whatsnew/3.14.rst.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants