Graham Dumpleton

There is now a Workshops page on this site listing seventy free hands-on workshops, spread across five collections.

Yesterday's post introduced jupyterlab-workshop and showed one page of a workshop.

When I released the 24 wrapture workshops last week, they ran in JupyterLab on mybinder with the instructions in a side panel, and I said at the end of that post that the panel deserved a post of its own.

At PyCon AU 2026 I gave a talk in the DevRel track titled "Hands-on learning in the age of AI", with the subtitle "Are developer workshops still relevant?".

Since introducing wrapture at the end of August I have been putting out a post every day or so, first working through how it is used in unit tests and then how the same bindings trace a running application.

Everything in the last four posts rendered a trace for a person to read or wrote it to a file for later.

The /order endpoint of the Flask shop is slow.

For a web application the natural unit of tracing is the request: one HTTP request, its method, path and status, and every observed call made while handling it, as one tree.

The previous post traced the shop with three bindings and a sink, all applied from the program's own entry point.

When I wrote about unit testing with wrapture the pattern in every test was the same: create a binding on a method, open a timeline(), run the code, and read the recorded calls off the tape.

Every example in this series so far has wrapped a call.

Most of what a test configures on a patch holds until the test changes it.

In unit testing with wrapture the tests leaned on a timeline and a tape to assert on what happened, and I skipped over what those actually are.

In introducing wrapture I said the one idea everything sits on is to wrap rather than replace.

For the best part of two decades, through wrapt, I have been dealing with the mechanics of monkey patching in Python.