I attended PyCon 2026 in Long Beach, CA this year and had a blast. It was by far the largest conference I’ve attended, with just over 2000 attendees and over 100 speakers.
The only wrinkle in the conference I would say is that the first keynote (literally the first talk of the whole conference) ended up just being one long paid ad for Fireworks AI.
@pycon This keynote sucked. What went wrong?
— Guido van Rossum (@gvanrossum) May 15, 2026
Unsurprisingly, many people began walking out midway - myself included.
Anyways - below are some of my notes from this great weekend.
Container-Enabled AsyncIO
By Niels Bantilan.
This talk didn’t really introduce much new - but it did reaffirm that we at CoPlane are onto something. Namely that agentic workflows are meant to be written in Python and not some bespoke YAML dag DSL.
Niels talked about how he started building agentic workflows in something akin to Dagster, but over time grew frustrated by how difficult it was to express simple ideas like looping.
Effectively his conclusion was that all you need is python’s asyncio api along with some orchestration layer like Kubernetes to have fine control over the configuration of each node in your AI workflow. Perhaps some phases require low specs while others may require seriously beefy machines including perhaps dedicated GPUs.
So honestly I didn’t learn much here but it did feel nice to know that Niels and our team at CoPlane have effectively arrived at the same conclusions.
Free-threaded Python: past, present and future
Python Core Team member, Thomas Wouters gave an interesting talk on the future of multi-threaded python.
As of version 3.13 there is a unique python build that disables the Global Interpreter Lock (GIL), which means that a GIL-less multithreaded application will see marked improvements in performance - enabling true multi-core parallelism for CPU-bound work.
In future versions of python, the default build will be GIL-less and in some future release (Thomas hinted at this being several years down the road), the GIL will be entirely removed.
The talk went into the challenges with implementing GIL-less python and was interesting - but not necessarily that relevant to my day-to-day work since CoPlane’s python applications are mainly IO bound and not thread-heavy apps.
Here are some links to this subject:
- https://docs.python.org/3/howto/free-threading-python.html
- https://www.danilchenko.dev/posts/python-314-free-threading
- https://til.simonwillison.net/python/trying-free-threaded-python
- https://codspeed.io/blog/state-of-python-3-13-performance-free-threading
The Art of Live Process Manipulation
I regret not having attended this talk by Savannah Ostrowski as it was one of the more relevant ones for my day job.
In any case, as of python 3.14 - you can now connect to a live running python application (so long as you know the process id) and execute any arbitrary code within that running process via the new sys.remote_exec function. You have access to all the live objects and imported modules while you execute code remotely.
This is interesting because there are certain things we may want to inspect that aren’t easily serializeable. But with remote_exec we can run a script and debug on live in memory objects!!
This is also a pretty big deal for debugging an application because this means that you don’t need to run a new deployment to issue more logs or generate debugging metadata - you can run any code to introspect and debug your live app.
It’s as easy as:
sudo uv run python -c 'import sys;sys.remote_exec(59096, "/Users/gio/path/to/my/remote_exec_script.py")'The remote_exec_script.py script runs inside of the python process at 59096.
Savannah then showed that she built a tool on top of this new remote_exec api to be able to connect to running Kubernetes clusters and debug them as they’re running!
https://github.com/savannahostrowski/debugwand
She advertises that this only be used for locally running k8s clusters … but I just wonder if there may be ways to connect to live remote clusters in a safe way. Or maybe we just ssh into the relevant pod and do debugging from an ssh session?
Peeking under the hood of uv run
One of the creators of uv did a deep dive on what happens in the few milliseconds between when you run uv run <some_program> and <some_program> actually running.
It turns out that a lot happens.
At a high level, uv performs three things before <some_program> runs:
- discovery
- locking
- syncing
The duration of which depends on whether the project / working dir is in a “cold”, “warm” or “hot” path.
Where cold means no packages (nor their dependencies) have been fetched, there isn’t a lock file present (yet), and there aren’t any cached assets to reduce round trips. And warm and hot effectively move the project further down the spectrum of such things as having all dependencies prefetched and cached and the lockfile is present (and valid).
Discovery
During the discovery phase, uv must answer these questions:
- Which subset of the lock is selected?
- Do we need to create an environment?
- What packages are in the environment?
- What packages need to be downloaded?
- What packages need to be built?
- What packages need to be un/installed?
Locking
- Is there an existing Lock file? Is it usable?
- What are the dependencies of the project?
- What are the dependencies of those dependencies?
- Which sources should be used?
- What versions satisfy the constraints?
- Are the dependencies conditional?
Syncing
- Which subset of the lock is selected?
- Do we need to create an environment?
- What packages are in the environment?
- What packages need to be downloaded?
- What packages need to be built?
- What packages need to be un/installed?
The wild thing is that on the hot path this can all be performed in about 10ms (irrespective of project size)! This is because of how aggressive uv’s caching is. And the same set of ops can be performed in about 5seconds for moderately large projects on a fresh install of the project (cold path with no caching).
I have more notes, but these talks were the coolest I think.
Hope you learned something new :)
Liked this post? Consider buying me a coffee :)