Bug report

Bug description:

During a rebuild of all packages in Debian unstable, the uvloop test suitefailed due to a new behavior in asyncio.

This suite runs each test twice: once with uvloop implementation (which passes) and once with Python’s asyncio implementation (which fails).

Since

Commit: 38a99568763604ccec5d5027f0658100ad76876fPR: https://github.com/python/cpython/pull/128768

asyncio.BaseEventLoop.create_task() no longer callsset_name(name). This breaks compatibility with any factory that does not set the name manually.

Expected behavior

When usingcreate_task(..., name="example name"), the task's name should always be set - even when using a custom task factory - as it was before the regression.

Actual behavior

With a custom factory that returns asubclassed asyncio.Task, the task name isNone unless the factory manually callsset_name(name). This is a silent behavioral change that breaks code relying onset_name() being called by the event loop.

My Environment

Python version: 3.13.2
Debian testing

Script to reproduce

importasyncioasyncdefmain():names= []asyncdefget_name():names.append(asyncio.current_task().get_name())asyncwithasyncio.TaskGroup()astg:tg.create_task(get_name(),name="example name")print(names)asyncio.run(main())# Output: ['example name']deffactory():loop=asyncio.new_event_loop()loop.set_task_factory(asyncio.eager_task_factory)returnloopasyncio.run(main(),loop_factory=factory)# Output: ['example name']# Fails silently with custom task_factoryresult=NoneclassMyTask(asyncio.Task):defset_name(self,name):globalresultprint(name)# never reachedresult=name+"!"defget_name(self):globalresultreturnresultdefloop_factory():loop=asyncio.new_event_loop()loop.set_task_factory(asyncio.create_eager_task_factory(MyTask))returnloopasyncio.run(main(),loop_factory=loop_factory)# Output: ['None']

CPython versions tested on:

3.13

Operating systems tested on:

Linux