Comment by zbentley

This article's incomplete/flawed, I'm afraid.

And like ... I take no pleasure in calling that out, because I have been exactly where the author is when they wrote it: dealing with reams of async code that doesn't actually make anything concurrent, droves of engineers convinced that "if my code says async/await then it's automagically performant a la Golang", and complex and buggy async control flows which all wrap synchronous, blocking operations in a threadpool at the bottom anyway.

But it's still wrong and incomplete in several ways.

First, it conflates task creation with deferred task start. Those two behaviors are unrelated. Calling "await asyncfunc()" spins the generator in asyncfunc(); calling "await create_task(asyncfunc())" does, too. Calling "create_task(asyncfunc())" without "await" enqueues asyncfunc() on the task list so that the event loop spins its generator next time control is returned to the loop.

Second, as other commenters have pointed out, it mischaracterizes competing concurrency systems (Loom/C#/JS).

Third, its catchphrase of "you must call create_task() to be concurrent" is incomplete--some very common parts of the stdlib call create_task() for you, e.g. asyncio.gather() and others. Search for "automatically scheduled as a Task" in https://docs.python.org/3/library/asyncio-task.html

Fourth--and this seems like a nitpicky edge case but I've seen a surprising amount of code that ends up depending on it without knowing that it is--"await on coroutine doesn't suspend to the event loop" is only usually true. There are a few special non-Task awaitables that do yield back to the loop (the equivalent of process.nextTick from JavaScript).

To illustrate this, consider the following code:

    async def sleep_loop():
        while True:
            await asyncio.sleep(1)
            print("Sleep loop")

    async def noop():
        return None

    async def main():
        asyncio.create_task(sleep_loop())
        while True:
            await noop()

As written, this supports the article's first section: the code will busy-wait forever in while-True-await-noop() and never print "Sleep loop".

Related to my first point above, if "await noop()" is replaced with "await create_task(noop())" the code will still busy loop, but will yield/nextTick-equivalent each iteration of the busy loop, so "Sleep loop" will be printed. Good so far.

But what if "await noop()" is replaced with "await asyncio.sleep(0)"? asyncio.sleep is special: it's a regular pure-python "async def", but it uses a pair of async intrinsic behaviors (a tasks.coroutine whose body is just "yield" for sleep-0, or a asyncio.Future for sleep-nonzero). Even if the busy-wait is awaiting sleep-0 and no futures/tasks are being touched, it still yields. This special behavior confuses several of the examples in the article's code, since "await returns-right-away" and "await asyncio.sleep(0)" are not behaviorally equivalent.

Similarly, if "await noop()" is replaced with "await asyncio.futures.Future()", the task runs. This hints at the real Python asyncio maxims (which, credit where it's due, the article gets pretty close to!):

    Async operations in Python can only interleave (and thus be concurrent) if a given coroutine's stack calls "await" on:
       1. A non-completed future.
       2. An internal intrinsic awaitable which yields to the loop.
       3. One of a few special Python function forms which are treated equivalently to the above.
     Tasks do two things:
       1. Schedule a coroutine to be "await"ed by the event loop itself when it is next yielded to.
       2. Provide a Future-based handle that can optionally be used to directly wait for that coroutine's completion when the loop runs it.
     (As underlined in the article) everything interesting with Python's async concurrency uses Tasks. 
     Wrapping Tasks are often automatically/implicitly created by the stdlib or other functions that run supplied coroutines.