Topics covered in this episode:

The trusted-publishing debate: how to do it right vs. why you shouldn't trust it
JupyterLab 4.6 and Notebook 7.6 are out!
Tau – new small, readable terminal coding agent
Django Tasks and Django 6.1
Extras
Joke

About the show

Sponsored by us! Support our work through:

Our courses at Talk Python
Consulting from Six Feet Up

Connect with the hosts

Michael: Mastodon / BlueSky / X / LinkedIn
Calvin: Mastodon / BlueSky / X / LinkedIn
Show: Mastodon / BlueSky / X

Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesday at 7am PT. Older video versions available there too.

Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it.

Calvin #1: The trusted-publishing debate: how to do it right vs. why you shouldn't trust it

https://snarky.ca/how-to-publish-to-pypi-using-github-actions-securely/ (Brett Cannon) and https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing (William Woodruff)

Trusted Publishing (PyPI's OIDC-based auth scheme, also now used by npm, RubyGems, crates.io, NuGet) replaces long-lived API tokens with short-lived, auto-scoped credentials tied to CI/CD machine identity.
Yossarian's post: it's purely an authentication mechanism between a machine identity and a package — it says nothing about package safety or quality. PyPI deliberately avoids any "verified/trusted" badge for it, unlike its verified-URL checkmarks.
Same logic applies to PyPI attestations: anyone can sign with any machine identity they control, so an attestation's presence isn't itself a trust signal.
Bottom line from that post: don't confuse "trusted" (machine-to-machine) with "trustworthy" (human judgment about the package).
Snarky.ca's companion piece is more practical: given GitHub Actions compromises in the news, the real fix is 3 concrete steps — run zizmor to lock down workflow permissions/checkout credentials and pin actions to commit hashes, adopt Trusted Publishing to eliminate stored PyPI tokens, and require manual approval via a GitHub environment before any publish job runs.
Takeaway for listeners: Trusted Publishing is good hygiene for how you authenticate to PyPI, but it's not a substitute for securing your CI pipeline itself — or for actually vetting the packages you install.

Michael #2: JupyterLab 4.6 and Notebook 7.6 are out!

Michał Krassowski's rundown - a chunky minor release: 68 features, 97 bug fixes, 95 contributors, one of the biggest ever.

Scratchpad console (Notebook 7.6 headliner) - a console next to your notebook sharing its kernel, for throwaway experiments. Ctrl+B.
Jump to last-edited cell - new commands hop through recently edited cells.
File browser glow-up - Date Created column, editable breadcrumbs with Tab-completion, and Open in Terminal.
Debugger - sources open in the main area, floating step/continue overlay, live kernel-sources filter.
Custom layouts (Lab) - activity bar top/bottom, draggable panels, four-way tab splits, per-panel Ctrl+scroll zoom.
~5x faster extension builds - webpack → Rspack, and jupyter-builder means no full Lab install needed to build extensions.
Keyboard/a11y - add shortcuts from the UI (no JSON), Find & Replace in Edit menu (Ctrl+H).

Calvin #3: Tau – new small, readable terminal coding agent

Tau – new small, readable terminal coding agent (Python 3.12+), built as both a working tool and a teaching project for how coding agents work under the hood
Install via uv tool install tau-ai, pipx, or pip; ships a tau CLI
Three-layer architecture: tau_ai (provider-neutral model layer) → tau_agent (reusable "brain": messages, tools, events, loop) → tau_coding (CLI/TUI, file & shell tools, sessions)
Supports OpenAI, Anthropic, OpenAI Codex, OpenRouter, Hugging Face, and custom/local OpenAI-compatible endpoints
Built-in tools (read/write/edit/bash), durable JSONL sessions with resume/branching, project instructions via AGENTS.md, and context compaction
Core harness is UI-agnostic — same brain can power the TUI, print mode, or a custom frontend — usable as a standalone library too

Michael #4: Django Tasks and Django 6.1

Django 6.0 finally ships first-party background tasks (django.tasks) - out of Jake Howard's DEP 14, accepted May 2024, after two decades of everyone bolting on Celery/RQ/Huey.
It's an API, not a worker. Django handles task definition, validation, queuing, and result storage - it does not execute them. You bring the backend.
The default backend traps people. ImmediateBackend runs tasks inline on the request thread and blocks until done - so out of the box .enqueue() backgrounds nothing (a 5-second task means a 5-second response). The other built-in, DummyBackend, runs nothing at all. Both are dev/test only.
Nice API otherwise: slap @task on a function, call .enqueue(), get back a TaskResult you look up later by id - with async twins like aenqueue(). Gotcha: args and return values must survive a JSON round-trip, so a tuple sneakily comes back as a list.
The community local backend to know: django-tasks-local by Chris Beaven (SmileyChris). A ThreadPoolExecutor backend that gives real background threads with zero infrastructure - no Redis, no Celery, no database - plus a ProcessPoolBackend for CPU-bound work → github.com/lincolnloop/django-tasks-local
Its catch: results live in memory, so pending tasks vanish on restart or deploy. Great for dev and low-traffic production; for persistence, drop to Jake Howard's django-tasks (DatabaseBackend + worker command).

Extras

Calvin:

Fixing the dictionary with Python 3.14 — Hugo van Kemenade stumbled on - and got fixed - a markup bug in the OED's own citation of a 1706 use of the pi symbol.

Michael:

Bunny DNS is now free

Jokes: