GeezerVison is showing github.com — Remove deprecated `asyncio.iscoroutinefunction` for 3.16 · Issue #149600 · python/cpython
Remove deprecated asyncio.iscoroutinefunction for 3.16 #149600DescriptionFeature or enhancement
Refs #122858
Refs #122875
It is scheduled to be removed in 3.16:
|
# A marker for iscoroutinefunction. |
|
_is_coroutine = object() |
|
|
|
|
|
def iscoroutinefunction(func): |
|
import warnings |
|
"""Return True if func is a decorated coroutine function.""" |
|
warnings._deprecated("asyncio.iscoroutinefunction", |
|
f"{warnings._DEPRECATED_MSG}; " |
|
"use inspect.iscoroutinefunction() instead", |
|
remove=(3,16)) |
|
return _iscoroutinefunction(func) |
|
|
|
|
|
def _iscoroutinefunction(func): |
|
return (inspect.iscoroutinefunction(func) or |
|
getattr(func, '_is_coroutine', None) is _is_coroutine) |
Linked PRs
Activitycdce8p commented on May 9, 2026 Would it be too much hassle to hold off on the removal a bit longer? While switching to inspect isn't difficult, there are unfortunately packages which are no longer maintained and thus would be broken. In particular backoff with 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 sobolevn commented on May 9, 2026 @cdce8p backoff is archieved.
I don't think that it will ever change its API.
So, what can be different next year / release? cdce8p commented on May 9, 2026
@cdce8p backoff is 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. sobolevn commented on May 9, 2026
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 with inspect.markcoroutinefunction and inspect.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. cdce8p commented on May 10, 2026
Plus, 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.iscoroutinefunction basically an alias for inspect.iscoroutinefunction at 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 of typing.Union from 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 changed the title [-]Remove deprecated `async.iscoroutinefunction` for 3.16[/-] [+]Remove deprecated `asyncio.iscoroutinefunction` for 3.16[/+] on May 12, 2026colesbury commented 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. sobolevn commented on May 12, 2026 @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 on Aug 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 asyncio maintainers / SC to decide :) kumaraditya303 commented on May 13, 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.
asyncio.iscoroutinefunction function is a undocumented API and is not extensible, it requires accessing the private _coroutine_marker object to allows other objects. To fix this Python 3.12 introduced inspect.markcoroutinefunction primarily to support django which is incompatible with asyncio.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 with markcoroutinefunction.
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.
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|