Re (1), there are only two places where asyncio calls `iscouroutinefunction()`, and in both cases it raises a TypeError to remind the user that a coroutine/awaitable object is required. So, it doesn't really offer much of an advantage and I wouldn't worry about it.

On Thu, Nov 2, 2017 at 4:51 PM, Chris Jerdonek <> wrote:

I have a 2-part question:

1) Say you have a function that returns an awaitable (but not a
coroutine object). Are there any advantages or disadvantages to
replacing this with a function for which asyncio.iscoroutinefunction()
returns True and asyncio.iscoroutine() returns True for the return
value? An advantage might be, say, additional checks that asyncio

2) If there are advantages, is there a straightforward way to
construct such a replacement? In the case I have in mind (from an open
source project), the "function" you'd be starting with is the class
constructor for an async context manager that is also awaitable. So
the class has both __aenter__ and __await__ methods.

As an example naive attempt, the following _wouldn't_ work:

    def connect():
        return AsyncConnectManager()

The reason this doesn't work is that wrapping connect() in
@asyncio.coroutine() means the return value is no longer an async
context manager (it no longer has an __aenter__ method). You have to
await to get the underlying async context manager.

Async-sig mailing list
Code of Conduct:

--Guido van Rossum (