Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

> Awaiting a coroutine does not give control back to the event loop.

I think this is a subtler point than one might think on first read, which is muddled due to the poorly chosen examples.

Here's a better illustration:

  import asyncio
  
  async def child():
      print("child start")
      await asyncio.sleep(0)
      print("child end")
  
  async def parent():
      print("parent before")
      await child()        # <-- awaiting a coroutine (not a task)
      print("parent after")
  
  async def other():
      for _ in range(5):
          print("other")
          await asyncio.sleep(0)
  
  async def main():
      other_task = asyncio.create_task(other())
      parent_task = asyncio.create_task(parent())
      await asyncio.gather(other_task, parent_task)
      
  asyncio.run(main())

It prints:

  other
  parent before
  child start
  other
  child end
  parent after
  other
  other
  other

So the author's point is that "other" can never appear in-between "parent before" and "child start".

Edit: clarification

This is gold.

Here’s a horror story for you.

A few years ago I worked for this startup as a principal engineer. The engineering manager kept touting how he was from XYZ and that he ran Pythonista meetups and how vast his knowledge of Python was. We were building a security product and needed to scan hundreds of thousands of documents quickly so we built a fan out with coroutines. I came on board well into this effort to assist in adding another adapter to this other platform that worked similarly. After seeing all the coroutines, being pickled and stored in S3, so that nodes could “resume” if they crashed yet - not a single create_task was present. All of this awaiting, pickling, attempting to resume, check, stuff, report, pickle, happened synchronously.

When trying to point out the issue with the architecture and getting into a shouting match with Mr. Ego, I was let go.

My New Year’s Resolution will be to give up complaining about this on hn, but for now:

I find ChatGPT’s style and tone condescending and bland to the point of obfuscating whatever was unique, thoughtful and insightful in the original prompt.

Trying to reverse-engineer the “Not this: That!” phrasing, artificial narrative drama & bizarre use of emphasis to recapture that insight and thought is not something I’m at all enthusiastic to do.

Perhaps a middle ground: HN could support a “prompt” link to the actual creative seed?

I may be misunderstanding it, but the examples shown don't seem to be illustrative? It seems reasonably obvious that the prints will happen in this order in any language, because in example 1 we are explicitly (a)waiting for the child to finish, and in example 2 both of the parent prints are above the await. So I don't feel like either of these makes the point the author is trying to get across?

Sorry if I've got this wrong, but wouldn't the first example behave the same way in Javascript as well? The function parent() "awaits" the completion of child(), so it wouldn't be possible to interleave the print statements.

The example from this StackOverflow question might be a better demonstration: https://stackoverflow.com/q/63455683

Maybe I'm nitpicking a bit but the second concrete example shows different flow in the parent method compared to the first one. If the second example would be a modification of the first one like shown below the output would be the same in both cases.

  async def parent():
      print("parent before")
      task = asyncio.create_task(child())   # <-- spawn a task
      await task
      print("parent after")

Personally, I've never been able to make async work properly with Python. In Node.js I can schedule enough S3 ListBucket network requests in parallel to use 100% of my CPU core, by just mapping an array of prefixes into an array of ListBucket Promises. I can then do a Promise.all() and let them happen.

In Python there's asyncio vs threading, and I feel there's just too much to navigate to quickly get up and running. Do people just somehow learn this just when they need it? Is anyone having fun here?

The article’s understanding of Java’s Virtual Threads is incorrect. Virtual threads have a preemptive concurrency model, not a co-operative one, so suspension points are not only at calls to things like Future.get()

Asynchronous and parallel programming are concepts I've never really learned, and admittedly scared to use, because I never really understand what the code is doing or even the right way of writing such code. Does anyone have any good resources that helped you learn this and have a good mental model of the concepts involved?

I asked a question about exactly this on Stack Overflow, many years ago, which I think received a nice answer: https://stackoverflow.com/questions/57966935/asyncio-task-vs...

I'm confused, of course if you await immediately it's not going to have a chance to do anything else _before_ returning.

If you do the following it works as expected

    async def child():
        print("child start")
        await asyncio.sleep(0)
        print("child end")
    
    async def parent():
        print("parent before")
        task = child()
        print("parent after")
        await task

The real difference is that the coroutine is not going to do _anything_ until it is awaited, but I don't think the asyncio task is really different in a meaningful way. It's just a wrapper with an actual task manager so you can run things 'concurrently'.

Python does have two different coroutines, but they're generators and async functions. You can go from one to the other,

The main takeaway for me is that in Python, this doesn't work:

    async def somethingLongRunning():
       ...

    x = somethingLongRunning()
    ... other work that will take a lot of time ...
    await x  # with the expectation that this will be instant if the other work was long enough

That's counterintuitive coming from other languages and seems to defeat one of the key benefits of async/await (easy writing of async operations)?

I've seen so many scripts where tasks that should be concurrent weren't simply because the author couldn't be arsed to deal with all the boilerplate needed for async. JavaScript-style async/await solves this.

Both examples do the same in C#, together with explanation that couroutine is executed synchronously until hitting a real pause point. Change `asyncio.create_task` to `Task.Run` and that's exactly the same behavior in the second example as well.

For the JS developers: similar useful behavior (and more!) can be implemented in JS using the wonderful Effection library.

https://effection-www.deno.dev/

Ironically, by trying to explain awaitables in Python through comparison with other languages, the author shows how much he doesn’t understand the asynchronous models of other languages lol

For anyone somewhat interested in task & scheduling I highly recommend phil-op tutorial on building a kernel - there is a late branch on the github that specifically focus on asynchronous task - I implemented multi-core this week and it high a profound enlightenment on what the f* was actually going on. This is something Claude / Gemini helped me achieve so I didn't require me to spend nights on kernel debugging methodology & documentation ; Best experience I could get on async

Is this the same as the distinction between a model in which async functions "run synchronously to the first await" vs one in which they "always yield once before executing", as discussed here?

https://www.reddit.com/r/rust/comments/8aaywk/async_await_in...

Just to note the it's the same in Rust with tokio::spawn (and alternatives).

How many people just avoid working with await in Python at all costs (e.g., favoring something like multiprocessing instead?). It’s always felt less comfortable in Python than in other languages

A common use of asyncio is a server framework like fastapi that schedules tasks. I used such a framework for a while before realizing that I needed to create_task for within-task concurrency.

I'm pretty sure that this post is not right. JS behaves the same way Python does in this example. Not sure about C#, though I suspect it is no different.

The example with parent() awaiting a child() is showing.. nothing? Maybe I am missing some subtlety but here is a JS example that is equivalent:

  async function sleep(t) {
    return new Promise((resolve) => {
      setTimeout (() => resolve(), t)
    }）
  }

  async function child() {
    console.log("child start")
    await sleep(500)
    console.log("child end")
  }

  async function parent () {
    console.log("parent start")
    await child()
    console.log("parent end")
  }

  parent()

It will print:

  parent start
  child start
  child end
  parent end

Just like the Python version. This article is confusing the fact that JS has a lot more code that returns a promise than Python and thinks it means the behavior is different. It isn’t.

You can roll your own event loop without asyncio by accumulating coroutines in Python and awaiting them in whatever order you want. There is no built-in event loop, however. You can do the same in JavaScript but there you do have a fairly complex event loop (see microtasks) as in there is no running environment without it and if you want a secondary one you have to roll it yourself.

create_task() simply registers a coroutine with the event loop and returns a “future” which basically says “once the main event loop is done awaiting your coroutine this is the ticket to get the result/exception”. That’s the whole magic of an event loop. It is the difference between dropping off a shirt at a dry cleaner and waiting there for them to be done with it (no you aren’t doing the work but you are also not doing anything else), and dropping it off then leaving to get lunch then coming back to wait until the cleaner is done with your pickup ticket in hand (concurrency).

But fundamentally awaiting an async function that doesn’t actually do anything async won’t give you parallelism in a single-threaded environment. More at 11.

I haven't done much async Python (much more gevent, years ago) but must admit I had exactly the misconception this is describing... Good to know!

but how would you systematically audit a large async codebase to find all the hidden interleave points, unnecessary locks?

How does this compare to Kotlin's supend and coroutines ? (which I am most familiar with)

I mean of course the post does have a very valid point but it almost repeats like a mantra if there are no asyncio.create_task in your code it’s not concurrent. I mean it should probably at least mention asyncio.gather which IMO would be also much better to explain the examples with

I think this article is missing the point a bit.

It's saying that the action of calling an async function (e.g. one you've written) isn't itself a yield point. The only yield points are places where we the call would block for external events like IO or time - `await asyncio.sleep(100)` would be one of those.

This is true, but surely fairly irrelevant? Any async function call has somewhere in its possible call tree one of those yield points. If it didn't then it wouldn't need to be marked async.

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.

If this

await asyncio.sleep(0)

doesn't yield control back to an event loop, then what the heck is it actually for?