2026-07-21 –, Room 1.38 (Ground Floor, Turing)
Your simulation is 40 hours into a 48-hour SLURM allocation and it has stopped making progress. You can't restart it, and you didn't instrument it. Until recently, Python's official answer was "you should have thought about that earlier." That answer has changed.
Python 3.14 and 3.15 quietly shipped the biggest upgrade to observability in the language's history: a safe, supported way to attach a debugger to any live Python process (pdb -p), and Tachyon, a sampling profiler in the standard library that attaches to a running process with virtually zero overhead and can tell you -- among other things -- which thread is hogging the GIL, at up to a million samples per second.
But scientific Python is observability's hardest case: long-running, thread-heavy, mostly native code underneath, and increasingly on the GPU. I'll demo what the new tools do on live processes, but will also be honest about where they still go dark today -- native frames, free-threaded builds, GPU timelines -- and lay out a plan for Python 3.16, which you can help shape as well.
Scientific workloads are the worst case for Python observability: they run for days, they can't be restarted, they're thread-heavy, most of their time is spent inside compiled extensions, and more of them run on GPUs every year. For most of Python's life, the tooling answer to "what is my process doing?" was: restart it with instrumentation and hope the problem reproduces.
Between 2024 and 2026, that changed. This keynote is a guided tour of the new reality, live on stage, plus an honest map of what's still missing -- and a plan.
Act I: Observe without restarts.
Python 3.14 shipped PEP 768, a safe external debugger interface that ended a decade of tools force-injecting code into running interpreters via GDB. Its first consumer is in everyone's hands already: python -m pdb -p PID. Python 3.15 builds on the same machinery with Tachyon (PEP 799), a statistical sampling profiler in the standard library: attach to a live process by PID without pausing it, sample at up to 1 MHz, and view wall-clock, CPU, or GIL-contention profiles as flame graphs, live terminal dashboards, or line-level heatmaps. I'll attach to a hung "simulation" and find the problem without restarting it -- including answering the question every multithreaded NumPy user has asked: which thread is starving the others?
Act II: The three hard places.
Where the new tools still go dark, demonstrated rather than hand-waved:
- native code: your NumPy kernel is currently one opaque frame,
- free-threaded builds where the standard library leads and popular ecosystem tools still lag, and
- GPUs where excellent vendor timelines exist but nothing speaks Python natively and no common trace format connects them.
Act III: The near future.
Python 3.16 is in its alpha phase right now, so let's dream big: real native stack unwinding in the standard profiler, a stable introspection contract for external tools, contention metrics designed for the free-threaded world, a vendor-neutral bridge between Python stacks and GPU timelines... wouldn't that be something? Some of those things CPython cannot do alone, because they live in the build systems and wheels the scientific community maintains.
You'll leave with tools you can use on your cluster the week you get home, a clear-eyed picture of their limits, and a reason to contribute to Python 3.16's development. It's the perfect time.
No prior profiling experience required. Everything shown works from the command line on stock CPython: 3.14 features are in stable releases today, and 3.15 features are demonstrated on the betas of the release shipping this October.
CPython expert specializing in asynchronous programming and gradual typing. Over 15 years as a core developer of CPython. Former Python release manager. Former CPython Developer in Residence at the PSF. Original creator of the auto-formatter Black. Currently a software engineer for the Python Language Foundation team at Meta.