Repository navigation
Remove deprecated asyncio.iscoroutinefunction for 3.16 #149600
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancementstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on May 9, 2026 Would it be too much hassle to hold off on the removal a bit longer? While switching to
inspectisn't difficult, there are unfortunately packages which are no longer maintained and thus would be broken. In particularbackoffwith over 144 mil. downloads last month. I just checked the dependency tree for Home Assistant and it's still used by at least 22 of our dependencies.The repo was archived last year.
https://github.com/litl/backoff/
litl/backoff#220@cdce8p
backoffis archieved.
I don't think that it will ever change its API.
So, what can be different next year / release?@cdce8p
backoffis archieved.Yeah, I mentioned as much in my message.
So, what can be different next year / release?
Not much. I guess it's just a question if the removal is worth it. A few on-off projects are one thing but backoff is still used by a lot of packages which would all need to adapt. That's a huge cascading change which has the potential to significantly impact the adoption of 3.16 across the ecosystem.
I guess it's just a question if the removal is worth it.
In my opinion - yes, it is :)
Older API had multiple real technical problems that were solved withinspect.markcoroutinefunctionandinspect.iscoroutinefunction. We issued a warning for this a long time ago, no issues from users were created because of that: https://github.com/python/cpython/issues?q=is%3Aissue%20state%3Aopen%20iscoroutinefunction Plus, there's a clear migration path.If you want to discuss the deprecation cancelation / prolongation, there must be real solid technical reasons that outweight all the pro's.
Reacted by Zachary WarePlus, there's a clear migration path.
I agree and that's always greatly appreciated!
If you want to discuss the deprecation cancelation / prolongation, there must be real solid technical reasons that outweight all the pro's.
Must admit that I only skimmed #149601 but isn't
asyncio.iscoroutinefunctionbasically an alias forinspect.iscoroutinefunctionat this point? That's why I thought to comment here at all. I fully agree that cleanup, especially of problematic APIs, is worth it. That calculation is a bit different for aliases though at least IMO. E.g. while someday I'd love to get rid oftyping.Unionfrom a cleanup perspective, I don't expect that will ever happen. The ecosystem cost might simply be too high for it to be worth it.Anyway, I checked the fork network on Github and it looks like a replacement fork might be
python-backoff. It's already at 5M monthly downloads.
https://github.com/python-backoff/backoff- added a commit that references this issue
on May 12, 2026 - changed the title
[-]Remove deprecated `async.iscoroutinefunction` for 3.16[/-][+]Remove deprecated `asyncio.iscoroutinefunction` for 3.16[/+]on May 12, 2026 Why the rush to remove this? The maintenance burden of keeping the existing function seems small, and many projects still use it.
Removing widely used deprecated APIs, even after the scheduled 2 year deprecation period, creates a significant ecosystem cost.
The preferred deprecation period before removal is 5 years, but this also seems like something where the "maintenance overhead and security risk of the deprecated behavior is small", in which case it may make sense to keep the deprecated function for a longer period.
@colesbury I guess the main point of confusion is that the preffered deprecation period was changed on
2025-Jan-27, while this feature was deprecated before that onAug 9, 2024. Following the old process.I am not sure that https://peps.python.org/pep-0387 proposes a clear path for such cases.
creates a significant ecosystem cost.
In my opinion code like
--- from asyncio import iscoroutinefunction +++ from inspect import iscoroutinefunction
is not a signigicant ecosystem cost. Yes, packages need to be updated, but it happens for most (all?) new python versions.
I don't have any strong feelings about this specific case though. If others strongly believe that we should wait 3 more years, then - let's do this. It is up to
asynciomaintainers / SC to decide :)Why the rush to remove this? The maintenance burden of keeping the existing function seems small, and many projects still use it. Removing widely used deprecated APIs, even after the scheduled 2 year deprecation period, creates a significant ecosystem cost.
asyncio.iscoroutinefunctionfunction is a undocumented API and is not extensible, it requires accessing the private_coroutine_markerobject to allows other objects. To fix this Python 3.12 introducedinspect.markcoroutinefunctionprimarily to support django which is incompatible withasyncio.iscoroutinefunction. I waited for 2 releases before even deprecating it, it was deprecated in 3.14 and is being removed in 3.16. The migration for this is a one line change but the main benefit is that any project would now automatically support objects marked withmarkcoroutinefunction.I am not convinced that delaying the removal has any benefit, it burdens the ecosystem with libraries having to support two different flavors of what is considered a coroutine function and I would prefer to simplify it.
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
Feature or enhancement
Refs #122858
Refs #122875
It is scheduled to be removed in 3.16:
cpython/Lib/asyncio/coroutines.py
Lines 16 to 32 in 46a2c11
Linked PRs
asyncio.iscoroutinefunctionfunction #149601