Topics covered in this episode:

Watch on YouTube

About 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.

Rss Apple Podcaster
Podden och tillhörande omslagsbild på den här sidan tillhör Michael Kennedy and Calvin Hendryx-Parker. Innehållet i podden är skapat av Michael Kennedy and Calvin Hendryx-Parker och inte av, eller tillsammans med, Poddtoppen.