On `inspect.iscoroutine` and `coroutine.iscoroutine` parity

inspect.iscoroutine tests whether an object is of type.CoroutineType

coroutine.iscoroutine tests both type.CoroutineType and collections.abc.Coroutine, as well as, cache the object types for faster lookup on subsequent calls to the function.

What is the reasoning between having these distinct implementations?? Should there be parity between them?

I have a similar inquiry in regards to the inspect.iscoroutinefunction and coroutine.iscoroutinefunction.

What is coroutine ?

I assumed it meant this https://docs.python.org/3/glossary.html#term-coroutine.

You mentioned coroutine.iscoroutine which implies a coroutine module (or object?) with an iscoroutine function (or method?). I believe Éric was asking what that coroutine is, which I’m also confused about :slight_smile:. There is no standard library coroutine module, and coroutine objects do not have an iscoroutine method, so we’re not sure what you’re comparing to inspect.iscoroutine.

Module, yes :joy: . I was so puzzled by his response. asyncio.coroutines.iscoroutine. Apologies for the confusion.

asyncio.iscoroutinefunction has been deprecated: bpo-43216: Remove @asyncio.coroutine by illia-v · Pull Request #26369 · python/cpython · GitHub

1 Like

“inspect functions should really be tailored for checking for native types”

1 Like