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
Remove deprecated asyncio.iscoroutinefunction for 3.16 #149600
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.
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 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.
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, 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 on Aug 9, 2024. Following the old process.
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 :)
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.
Activity
pythongh-149600: Remove deprecated `asyncio.iscoroutinefunction` func…
cdce8p commentedon 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
sobolevn commentedon May 9, 2026
@cdce8p
backoffis archieved.I don't think that it will ever change its API.
So, what can be different next year / release?
cdce8p commentedon May 9, 2026
Yeah, I mentioned as much in my message.
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 commentedon May 9, 2026
In my opinion - yes, it is :)
Older API had multiple real technical problems that were solved with
inspect.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.
cdce8p commentedon May 10, 2026
I agree and that's always greatly appreciated!
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
gh-149600: Remove deprecated `asyncio.iscoroutinefunction` function (#…
[-]Remove deprecated `async.iscoroutinefunction` for 3.16[/-][+]Remove deprecated `asyncio.iscoroutinefunction` for 3.16[/+]colesbury commentedon 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 commentedon 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 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.
In my opinion code like
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 :)kumaraditya303 commentedon May 13, 2026
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.