Topics covered in this episode:Watch on YouTubeAbout the show
Sponsored by us! Support our work through:
Connect with the hosts
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:
Michael:
Jokes:
- What's the object-oriented way to become wealthy? Inheritance
- To understand what recursion is... You must first understand what recursion is
- 3 SQL statements walk into a NoSQL bar. Soon, they walk out They couldn't find a table.