[HN Gopher] The Fundamentals of Asyncio
       ___________________________________________________________________
        
       The Fundamentals of Asyncio
        
       Author : anordin95
       Score  : 79 points
       Date   : 2025-07-21 18:32 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | anordin95 wrote:
       | I've used Python's asyncio a couple times now, but never really
       | felt confident in my mental model of how it fundamentally works
       | and therefore how I can best leverage it. The official docs
       | provide decent documentation for each specific function in the
       | package, but, in my opinion, lack a cohesive overview of the
       | systems design and architecture. Something that could help the
       | user understand the why and how behind the recommended patterns.
       | And a way to help the user make informed decisions about which
       | tool in the asyncio toolkit they ought to grab, or to recognize
       | when asyncio is the entirely wrong toolkit. This is my attempt to
       | fill that gap.
        
         | sandeep1998 wrote:
         | thank you for that.
        
       | whinvik wrote:
       | This is excellent. Thanks.
        
       | omh1280 wrote:
       | Great read!
       | 
       | Python asyncio can really screw up your runtime performance if
       | you use it poorly. And it's _really_ easy to use poorly.
       | 
       | Consider a FastAPI server using asyncio instead of threading.
       | _Any_ time you drop down into a synchrononous API, you better be
       | sure that you're not doing anything slow. For example, encoding
       | or decoding JSON in Python actually grabs the GIL depending on
       | what library you're using, and then you have no hope of releasing
       | control back to asyncio.
        
         | kccqzy wrote:
         | That's a GIL problem not an async problem. Even if you choose
         | to ditch asyncio and use threads, you still need to care about
         | the GIL. And when I use asyncio I don't worry about CPU-bound
         | tasks like encoding or decoding JSON; I worry about some
         | library doing I/O synchronously regardless of whether such
         | library releases the GIL or not.
        
           | bb88 wrote:
           | This is spot on. GIL-less python will be a thing, and when it
           | happens, there will still be no reason to combine asyncIO
           | with thread primitives. Waiting for IO can be spun off into a
           | new thread, and it will work as you expect it would.
           | 
           | Trying to combine mental models of asyncio and threading is a
           | model for pure insanity.
        
       | alex5207 wrote:
       | [About the event loop]
       | 
       | > She's behind the scenes managing resources. Some power is
       | explicitly granted to her, but a lot of her ability to get things
       | done comes from the respect & cooperation of her subordinates.
       | 
       | What a wonderful paragraph. Playful, yet with a deep meaning. It
       | makes the article a joy to read.
        
       | cadamsdotcom wrote:
       | Awesome job closing a gap in the asyncio docs - wonder if it
       | could be contributed back & be added!
        
       | paulgb wrote:
       | This is great! Thanks for writing it.
       | 
       | One nit, the unquoted quotes in this file seem to be a parse
       | error (I replaced the inner ones with single quotes and it ran)
       | https://github.com/anordin95/a-conceptual-overview-of-asynci...
        
         | anordin95 wrote:
         | Ah, I'm so glad to hear it. And, thank you for the
         | nit/feedback! I generally use python3.12 for my work which
         | doesn't error out on that line. However, python3.11 and below
         | will raise a SyntaxError on it. I've fixed the issue there and
         | in a few other places and pushed the changes :)
        
       | Izkata wrote:
       | > Frankly, I'm not sure why that design decision was made and
       | find it rather confuses the meaning of await: asynchronously
       | wait.
       | 
       | I've always understood it to mean "wait for asynchronous object",
       | not that the wait itself is asynchronous. It's just an English
       | word that roughly means "wait for", that was chosen for the nice
       | "a" prefix for asynchronous stuff.
        
         | anordin95 wrote:
         | Mmm fair point! Though, coroutines aren't really asynchronous
         | objects in that usage, right? Since `await coroutine` would run
         | that coroutine synchronously.
        
       | ISO-morphism wrote:
       | This is great, thank you! Python's asyncio has certainly confused
       | me more than other languages' async-await implementations.
       | 
       | Nit in [1]: When timing durations inside of a program it's best
       | to avoid the system clock as it can and does jump around. For
       | Python, prefer time.monotonic() or time.perf_counter() over
       | time.time() in those situations.
       | 
       | [1] https://github.com/anordin95/a-conceptual-overview-of-
       | asynci...
        
       ___________________________________________________________________
       (page generated 2025-07-21 23:00 UTC)