PyCon 2026<br>PyCon 2026<br>May 22, 2026<br>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?<br>— 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")'<br>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 and actually running.

It turns out that a lot happens.

At a high level, uv performs three things before 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...