GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Breaking API Change in Python 3.13.3: Task Factory Signature Change · Issue #133745 · python/cpython

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

New issue
Copy link
New issue
Copy link
Closed
1 / 11 of 1 issue completed
Closed
Breaking API Change in Python 3.13.3: Task Factory Signature Change#133745
1 / 11 of 1 issue completed
Copy link
Assignees
Yhg1skumaraditya303
Labels
3.13only security fixesonly security fixes3.14bugs and security fixesbugs and security fixes3.15bugs and security fixesbugs and security fixesrelease-blockerstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directorytopic-asynciotype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@pablogsal
pablogsal
opened on May 9, 2025
Issue body actions

In PR #128768 (gh-128308), the asyncio task factory signature was changed from (loop, coro, context=None) to (loop, coro, **kwargs). This seemingly minor change breaks backward compatibility for existing task factory implementations.

The documentation was updated to reflect this new contract:

  • Old: (loop, coro, context=None), where the callable must return a asyncio.Future-compatible object.
  • New: (loop, coro, **kwargs), where the callable must pass on all *kwargs, and return a asyncio.Task-compatible object.

This change causes runtime errors for any code with task factories implemented according to the previous contract, as these factories now unexpectedly receive keyword arguments like name that they aren't designed to handle.

Reproducer

import asyncio

# Task factory implemented according to the previous API contract
def old_style_task_factory(loop, coro, context=None):
    print(f"Creating task with loop={loop}, coro={coro}, context={context}")
    return asyncio.Task(coro, loop=loop)

async def main():
    # Set up a custom task factory following the old documented API
    loop = asyncio.get_event_loop()
    loop.set_task_factory(old_style_task_factory)
    
    # This will fail with TypeError due to unexpected 'name' argument
    print("Attempting to create task with name...")
    await loop.create_task(asyncio.sleep(0.1), name="test_task")
    print("Task completed successfully")  # We won't reach this line

if __name__ == "__main__":
    try:
        asyncio.run(main())
    except TypeError as e:
        print(f"ERROR: {e}")
        # Output: ERROR: old_style_task_factory() got an unexpected keyword argument 'name'

This prints:

Attempting to create task with name...
Creating task with loop=<_UnixSelectorEventLoop running=False closed=False debug=False>, coro=<coroutine object BaseEventLoop.shutdown_asyncgens at 0x72b413aa5450>, context=None
Creating task with loop=<_UnixSelectorEventLoop running=False closed=False debug=False>, coro=<coroutine object BaseEventLoop.shutdown_default_executor at 0x72b413cc5910>, context=None
ERROR: old_style_task_factory() got an unexpected keyword argument 'name'
<sys>:0: RuntimeWarning: coroutine 'sleep' was never awaited
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

This is a breaking change introduced in a patch release, which violates our versioning policy. The change was intended to support the name keyword argument for eager tasks, but the implementation method has unintentionally broken existing code that followed the previously documented API contract.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Linked PRs

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

Activity

  1. pablogsal
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    on May 9, 2025
  2. pablogsal
    assigned
    kumaraditya303
    and
    Yhg1s
    on May 9, 2025
  3. picnixz
    added
    topic-asyncio
    stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
    3.13only security fixesonly security fixes
    on May 9, 2025
  4. github-project-automation
    added this to asyncioon May 9, 2025
  5. github-project-automation
    moved this to Todo in asyncioon May 9, 2025
  6. picnixz
    added
    3.14bugs and security fixesbugs and security fixes
    3.15bugs and security fixesbugs and security fixes
    release-blocker
    on May 9, 2025
  7. ezio-melotti
    added this to Release and Deferred blockers 🚫on May 9, 2025
  8. github-project-automation
    moved this to Todo in Release and Deferred blockers 🚫on May 9, 2025
  9. picnixz commented on May 9, 2025

    @picnixz
    picnixz
    on May 9, 2025
    Member
    More actions

    (I'm marking it as release-blocker just so that we can find the issue more easily)

  10. vstinner commented on May 9, 2025

    @vstinner
    vstinner
    on May 9, 2025
    Member
    More actions

    I suppose that the following issue in the toga project is related to this:

    • Use the documented prototype for task factories. beeware/toga#3395
    • beeware/toga@bdd2e7b
    • https://bugzilla.redhat.com/show_bug.cgi?id=2363033

    There is already a commit to work around the issue.

  11. Yhg1s commented on May 9, 2025

    @Yhg1s
    Yhg1s
    on May 9, 2025
    Member
    More actions

    @asvetlov @kumaraditya303 @graingert for 3.13, do you want to propose anything other than a rollback of the relevant PR (and anything that depends on it)? We'll probably want to do a new release to fix the breakage.

    For 3.14 it may also be worth considering not breaking the documented API (/cc @hugovk), but we have a bit more time to get that sorted.

  12. serhiy-storchaka commented on May 9, 2025

    @serhiy-storchaka
    serhiy-storchaka
    on May 9, 2025
    Member
    More actions

    No hurry. 3.13.3 was released a month ago, and only now we found out about that breakage. A few more days is not critical.

  13. serhiy-storchaka commented on May 9, 2025

    @serhiy-storchaka
    serhiy-storchaka
    on May 9, 2025
    Member
    More actions

    Other breakage of that documented contract happened in 3.11 (bpo-46994/#91150).

    I encountered a similar problem in #74696. It was needed to pass additional argument to the user registered function. I solved it by testing the optional supports_root_dir attribute of the function.

    We could do the same here. The users which need to pass the name to the constructor (eager tasks) should set a special attribute of the factory. By default, the old method will be used. We should document that this is temporary, and the factory should support arbitrary keyword arguments.

  14. kumaraditya303 commented on May 10, 2025

    @kumaraditya303
    kumaraditya303
    on May 10, 2025
    Contributor
    More actions

    I created #133808 to revert the breaking change for 3.13.

  15. graingert
    added a sub-issue on May 11, 2025
    • positional name and context are broken eg create_task(coro(), name, context) #133877
  16. graingert
    added a commit that references this issue on May 12, 2025

    pythongh-133745: Fix asyncio task factory name/context kwarg breaks

    5c3c953
  17. kumaraditya303
    marked create_task(name=...) silently fails to set name with custom task_factory after gh-128308 #132593 as a duplicate of this issue on May 16, 2025
  18. gvanrossum
    added a commit that references this issue on May 18, 2025

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

    fd6a602
  19. kumaraditya303 commented on May 21, 2025

    @kumaraditya303
    kumaraditya303
    on May 21, 2025
    Contributor
    More actions

    Fixed by #133948

    Reacted by Alice
  20. kumaraditya303
    closed this as completedon May 21, 2025
  21. github-project-automation
    moved this from Todo to Done in asyncioon May 21, 2025
  22. github-project-automation
    moved this from Todo to Done in Release and Deferred blockers 🚫on May 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

  • @Yhg1s
    Yhg1s
  • @kumaraditya303
    kumaraditya303

Labels

3.13only security fixesonly security fixes3.14bugs and security fixesbugs and security fixes3.15bugs and security fixesbugs and security fixesrelease-blockerstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directorytopic-asynciotype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Projects

  • Release and Deferred blockers 🚫
    Status
    Done
    Show more project fields
  • asyncio
    Status
    Done
    Show more project fields

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.