-
-
Notifications
You must be signed in to change notification settings - Fork 32k
[3.13] gh-128308: Revert "pass **kwargs
to asyncio task_factory (GH-128768) (#130084)"
#133808
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
Conversation
…ry (pythonGH-128768) (python#130084)" This reverts commit 7b0543e.
**kwargs
to asyncio task_factory (GH-128768) (#130084)"**kwargs
to asyncio task_factory (GH-128768) (#130084)"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only the backport is being reverted right? Please explain in the commit message why.
Does this spell doom for the 3.14 change???? @graingert |
I don't think so, a new kwarg If we decide passing |
**kwargs
to asyncio task_factory (GH-128768) (#130084)"**kwargs
to asyncio task_factory (GH-128768) (#130084)"
So it just shouldn’t have been backported. Sorry. somehow I can’t find the issue suggesting the revert. |
See #133745. That argument applies to 3.14 too. |
|
But we broke explicit |
Notice that several people have implemented workarounds since then so we need to ensure we preserve both behaviors to not break the people that have adapted. For example: beeware/toga#3395 |
Looks like we have more work to do -- 3.13.4 must support the workarounds that people have already made for 3.13.3. |
FWIW as one of the people who made a workaround, we just followed the documentation and passed through |
Thanks @alicederyn, that's very helpful. |
@graingert Are you going to update this PR to not break the workaround described by @alicederyn ? |
Does a plain revert break the workaround? |
I think so. Pre-revert (but only in 3.13.3), you could have a "private" keyword parameter passed to create_task() that's passed on to your factory (assuming you have control over the factory and your factory accepts this private keyword). So I think the various create_task() methods should (in addition to name= and context=) grow a new It's possible that that fix also models the improved version for 3.14b2 (which should pop name and |
Ah right, that's a better option! I'm not sure about this:
Do you mean |
Sorry, "and cancel" should have been "and context". Will fix in the original. |
Do you want to always pop name in 3.13.4? |
So, passing name= through kwargs to the factory must be a feature that factories must support to be compatible with 3.13.3 (but not later versions of 3.13), and to be compatible with 3.14b1+. 3.13.4+ must revert to the lame setname call to send the factory the name (a very old hack to be compatible with earlier versions of uvloop IIRC), but for 3.14b2 and everything after we require factories to support passing name= via **kwargs, and won't do the setname call any more. Right? |
I think so, since pre-3.13.3 factories may not support any keywords (other than and empty dict) and IIUC there's no way to tell if a factory supports that or requires setname, and I don't want to introduce a new API so we could ask a task factory about this. |
Ok I opened up a draft here: #133948 the news fragment is going to be fun, I've left it blank for now |
This reverts commit 7b0543e.
📚 Documentation preview 📚: https://cpython-previews--133808.org.readthedocs.build/