You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
In 3.13.* if custom asyncio task factory is set and no task name is provided to asyncio.create_task, task name provided by task factory is overwritten to "None". #130033
Code below illustrate a behavior change in 3.13 which I believe is a bug, which "Task-2" the task name becomes "None" while calling asyncio.current_task().get_name()
importasynciodeftask_factory(loop, *args, **kwargs):
new_task=asyncio.Task(*args, **kwargs)
name=new_task.get_name()
# Python 3.9 to 3.13 prints name='Task-2'# 'Task-3' and 'Task-4' is also printed because loop is shutting down, which is not in the scope of (possible) bugprint(f"{name=}")
returnnew_taskasyncdefprint_task_name():
current_task=asyncio.current_task()
name=current_task.get_name()
# Python 3.13 prints name='None' (but why does it print 'Task-2' before it's returned from task_factory() ?)# Python 3.9 to 3.12 prints name='Task-2'print(f"{name=}")
asyncdefmain():
loop=asyncio.get_running_loop()
loop.set_task_factory(task_factory)
new_task=asyncio.create_task(print_task_name())
awaitnew_taskasyncio.run(main())
If using a task factory, the task name can't be generated by task factory because it gets rewritten to name provided by asyncio.create_task(), which I think most people doesn't provide one.
Suggestion: check if name parameter is None before overwriting task name in create_task(), otherwise keep task name generated by task factory, and probably pass "name" parameter to task factory.
Agree, loop.create_task() should call set_name() only if the name is not None.
The bug exists in 3.13 only, the main branch has a different code and it should work fine.
Activity
asvetlov commentedon Feb 12, 2025
Agree, loop.create_task() should call set_name() only if the name is not None.
The bug exists in 3.13 only, the main branch has a different code and it should work fine.
gvanrossum commentedon Feb 12, 2025
Worth making a 3.13-specific fix though, right?
asvetlov commentedon Feb 13, 2025
I'll do it
asvetlov commentedon Feb 13, 2025
I think if we backport #128308, the fix covers the bug report well.
asvetlov commentedon Feb 13, 2025
The backport #130084 is ready for review.
asvetlov commentedon Feb 14, 2025
The fix was merged into the 3.13 branch.