Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Async, Python, and the Future
Search
Andrew Godwin
March 23, 2021
Programming
770
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Async, Python, and the Future
A keynote I gave at Python Web Conference 2021.
Andrew Godwin
March 23, 2021
More Decks by Andrew Godwin
See All by Andrew Godwin
Working With Risk: Lessons From Mountain Rescue
andrewgodwin
1
26
Reconciling Everything
andrewgodwin
1
420
Django Through The Years
andrewgodwin
0
350
Writing Maintainable Software At Scale
andrewgodwin
0
560
A Newcomer's Guide To Airflow's Architecture
andrewgodwin
0
440
How To Break Django: With Async
andrewgodwin
1
850
Taking Django's ORM Async
andrewgodwin
0
880
The Long Road To Asynchrony
andrewgodwin
0
790
The Scientist & The Engineer
andrewgodwin
1
880
Other Decks in Programming
See All in Programming
Inertia Rails: The One-Person Framework with React & Friends
skryukov
0
190
Compiling a real-world CLI tool to native with Static Hermes
tmikov2023
0
140
當我們開始不讀 Code - AI Agent 時代,Code Review 與 Clean Code 還剩下什麼?
jame2408
1
340
月間100万人のサービス刷新で、 技術選定をHonoに振り切った話
yutobara
8
7.1k
GraphQL の onError と Nullability のこれから
quramy
0
200
作って学ぶSpring BootのAuto Configuration / JJUG Night Seminar 2026-10-19
rshindo
0
210
社内AIエージェント「Askワンバン」における コストチューニングの取り組み
t0yohei
0
110
パスワード再設定メールのURLについて知っておこう
uyuki234
0
200
続・コーディングルールの鮮度を保ちたい / keep-fresh-go-internal-conventions-again
handlename
0
150
조합이폭발하는디자인시스템이걸눈으로도테스트하라고요
giljongyu
0
650
Snowflake Openflow Connector利用の勘所 / 20261024developersio2026tokyo-snowflake-openflow
kasacchiful
PRO
0
250
Optunaを作ったときにやりたかったこと、その後 (2026/10/16, Optuna Meetup #3)
iwiwi
4
1.4k
Featured
See All Featured
How to Talk to Developers About Accessibility
jct
2
600
HDC tutorial
michielstock
2
990
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
35
2.9k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
330
Practical Orchestrator
shlominoach
192
12k
How STYLIGHT went responsive
nonsquared
100
6.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
550
Context Engineering - Making Every Token Count
addyosmani
9
1.2k
Leo the Paperboy
mayatellez
10
2.4k
Done Done
chrislema
187
17k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
780
Transcript
ASYNC, PYTHON, AND ANDREW GODWIN // @andrewgodwin THE FUTURE
Hi, I’m Andrew Godwin • Django core developer • Worked
on Migrations, Channels & Async • Dabbled with Python async since 2009
None
The Past What is all this async business anyway? The
Present The long road and where we've got to The Future Is there a perfect solution to all this?
The path was forged by other languages And continues to
be - we're all one community in the end
1998 threading module, Stackless Python 2002 Twisted 2006 Greenlets (later
gevent, eventlet) 2008 multiprocessing module 2012 Tulip, PEP 3156 2014 asyncio module 2005 Coroutine-friendly generators (PEP 342)
Threading & Multiprocessing They're concurrency, but not really "async" in
the way we use it now
Twisted The original, and ahead of its time!
Greenlets & Gevent An almost drop-in solution… but it's never
that easy
Generators & Tulip The foundation of our current, cooperative async
1998 threading module, Stackless Python 2002 Twisted 2006 Greenlets (later
gevent, eventlet) 2008 multiprocessing module 2012 Tulip, PEP 3156 2014 asyncio module 2005 Coroutine-friendly generators (PEP 342)
What did we learn? A lot, but not everything.
Let's talk about the present And, of course, asyncio
Asyncio is here, and it's gaining traction Library support! Framework
support!
# Ready when a timer finishes await asyncio.sleep(1) # Ready
when network packets return await client.get("http://example.com") # Ready when the coroutine exits await my_function("hello", 64.2)
Network/timer updates An event loop's flow Select a ready task
Run task Add new tasks to queue await
Coroutines Time →
It is, however, not yet perfect. Turns out, it's a
really hard problem to solve
Everything must cooperate! One bit of synchronous code will ruin
the whole thing.
Can't tell if a function returns a coroutine! There are
standard hints, but no actual guaranteed way
async def calculate(x): result = await coroutine(x) return result #
These both return a coroutine def calculate(x): result = coroutine(x) return result
Can't have one function service both How we got here
makes sense, but it's still annoying sometimes.
You have to namespace async functions I really, really wish
we didn't have to
instance = MyModel.objects.get(id=3) instance = await MyModel.objects.a.get(id=3)
WSGIHandler __call__ WSGI Server WSGIRequest URLs Middleware View __call__ ASGIHandler
__call__ ASGI Server ASGIRequest Asynchronous request path BaseHandler get_response_async BaseHandler get_response URLs Middleware Async View __call__ Django's dual request flows
But, in many ways, the future is here You can
just write full async Python now, and it works pretty well.
So what does the future hold? Apart from, in my
case, a very delicious meal.
Obviously, more library support Databases & common services are still
thin on the ground
Safety, Safety, Safety Async code is HARD. Really hard.
How do we design out silent failure? Deadlocks, livelocks, race
conditions...
How do we prioritise? It's not like you have all
day to add new things.
Horizontal scalability is more important It's the difference between life
and death for a web service.
Long-polling and sockets need async Or your server bill will,
instead, be the death of you
I think we need both Sync and async code both
have their place.
Some things don't need async They're better off a little
slower and safer
Asyncio only benefits IO-bound code Code that thrashes the CPU
doesn't benefit at all
What does this mean for the Web? Our roles are
changing along with our technology
Parallel Queries After all, we're the experts in fetching data
Notifications & Events Polling will absolutely wreck your servers Microservices / API aggregation It's a lot quicker to call those 10 things in parallel
What does this mean for you? You're probably not in
quite as deep as I am
Mixed-mode is coming Django has it, Flask is really close.
Think about your architecture Group things that all do I/O
& requests together, for future parallelisation
Experiment! Take some async code for a spin.
Be the change you want to see. There's a lot
of work to be done, and never enough of us to do it.
Thanks. Andrew Godwin @andrewgodwin // aeracode.org