Topics covered in this episode:
- A quick chat with Brian looking back
- Extras
- Joke
Watch on YouTubeAbout the show
Brian #1: A quick chat with Brian looking back
Nick #2: Jev and the Case for Boring ML
Vincent Warmerdam from marimo benchmarked Jev, a new "System 1" decision model from TypeSafe AI. In his video It handles classification without the latency or token cost of generative LLMs, which raises a practical question for data teams: where does this fit alongside traditional machine learning?
- He tested Jev against classical machine learning models to see if its speed and accuracy hold up on real-world datasets.
- General LLMs work well for reasoning, but generating full token streams just to assign a category adds unnecessary latency and cloud cost.
- Jev avoids generation entirely by evaluating the input and returning only the decision, which makes it much faster and cheaper than standard chat APIs.
- It consistently outperformed eight-shot sentence transformer setups like SetFit out of the box, especially on datasets with dozens of target categories.
- Traditional models like logistic regression still matter because they run in single-digit milliseconds on basic CPUs, cost nothing per inference, and keep private data within your own network.
- You cannot fine-tune Jev directly, so standard models remain the better choice when your data contains internal company acronyms, product names, or domain slang.
- The most practical approach is using Jev to bootstrap initial labels or audit bad training data, then training a small model you can own and run locally.
Brett #3: Announcing the 2026 Python Packaging Council Election Results!
The inaugural Python packaging council (PPC) has been elected and started meeting!
- Introduced via PEP 772
- 5 members elected
- Top 2 vote-getters get two-year terms
- Other 3 get one-year terms
- All members will get two-year terms going forward, staggering the elections
- There have been 4 meetings far as well as a meeting with the SC
- As the inaugural packaging council still working out basic logistics like how to take notes
- Also working out what the packaging council should do as PEP 772 explicitly says packaging.python.org falls under the PPC, but otherwise tries not to dictate what the PPC is in charge of
Calvin #4: Parsing JSON at tens of gigabytes per second in Python
- Daniel Lemire (Oct 12) benchmarks fastsimdjson 0.6.0, a Python binding for simdjson on PyPI, repo at simdjson/fastpysimdjson. Its map_many function runs a callback per JSON line across N threads.
- Workload: Eight hours of GH Archive data, 7.6 GB and 2.2M events. The task counts event types and looks up the target repo's language for each opened PR, and it only touches a few fields per event.
- Lazy trick: With lazy=True, the whole event is parsed but Python objects are created only for the fields you access. The idea comes from Tyler Kennedy's pysimdjson.
- Single core: stdlib json gets 0.18 GB/s (about 42 s for the whole set), orjson 0.42, msgspec 1.29, fastsimdjson lazy 2.13 (3.6 s).
- 64 cores: stdlib json gets 3.17 GB/s, msgspec 24.6, fastsimdjson eager 29.8, and fastsimdjson lazy 65.7. That's the full 7.6 GB in about 0.12 s, roughly 31x its own single-core speed.
- Requires free-threading: It ran on Python 3.14.6 free-threaded (3.14t) on a 64-core dual-Xeon box.
- Grain of salt:
- It's one machine and one dataset.
- It's an embarrassingly parallel job with per-thread counters.
- The lazy win only shows up when you read a few fields from big objects.
- msgspec was handed a schema declaring only the needed fields.
- The post itself doesn't say whether this generalizes.
Michael #5: Grinberg's annual benchmark says 3.15 is flat, but the JIT finally pays off
Miguel Grinberg ran his annual release-eve benchmark, comparing Python 3.15.0rc3 against every interpreter back to 3.10, plus PyPy, Node.js, and Rust, using his usual two CPU-bound programs: recursive Fibonacci and bubble sort. The standard 3.15 interpreter lands within noise of 3.14 on his workloads, while the experimental JIT build is roughly 20 to 28 percent faster and finally beats the standard interpreter, which has not happened before. The free-threaded build holds up well in the 4-thread tests. He is candid that the workloads are just Fibonacci and bubble sort, and the official release lands days after his measurements.
- It is an independent, workload-based counterpoint to the official 7-8 percent JIT geometric-mean claim, from a series with real trend data back to 3.10.
- He did the same exercise for 3.12, 3.13, and 3.14, so there is a multi-year trend line to draw on.
- Methodology is two hand-picked CPU-bound programs, recursive Fibonacci plus bubble sort, not a pyperformance-style suite, which cuts both ways.
- PyPy 3.12 still runs circles around every CPython in the single-threaded tests, and Rust is about 77x faster on Fibonacci.
- The JIT gain is real in these numbers, but the JIT stays experimental, so he will not use it in production yet.
- Free-threaded fibo at 4 threads ran about 4.5x faster than the standard interpreter with the GIL.
- His verdict: not worth rushing an upgrade for speed alone, though lazy imports may tempt production projects.
Carol #6: Transparent and trusted AI Our Way - Satyrn AI
Paul Everitt, Georgi Ker and I were discussing Python, its community and AI back in March at the JetBrains PyTV event. Python is the foundational language for data science and AI tools. We wanted something that reflects the Python community's strengths: language and learning.
- Mission: https://satyrn.ai/mission/
- Python 3.15 trained model is on Hugging Face
- After Paul's Europython keynote, he asked for folks to join the community (think of it as a collective of individuals putting their talents together
- We used some of the organizational tips from Jupyter and JupyterHub's early days on scaling community and emphasizing leveling up individuals
- Paul will be keynoting in Africa and sharing progress made by a team of dedicated volunteers
- Putting AI tools and knowledge in the hands of Pythonistas makes good sense and over time will benefit people (A theme that I have spoken about since PyCon 2023 and most recently PyCon JP 2026
Extras
Michael:
- Adobe Creative Suite was mostly cloned in Rust
- ArtCraft released seven free, open-source desktop apps that mirror the Adobe lineup: PhotoCraft for Photoshop, VectorCraft, FilmCraft, LightCraft, PrintCraft, EffectCraft, and DesignCraft. Everything is written from scratch in Rust with WebAssembly builds for the browser, and developer Brandon Thomas says the apps are AI-built clean-room reimplementations, a claim Ars Technica covered alongside the predictable skepticism.
- The clean-room story matters: reimplementing Adobe from public specs and behavior with AI is legally defensible, and building the apps for agents to drive, not just humans, is a genuinely different design bet.
- PhotoCraft already shows real depth: layers, masks, adjustment layers, layer styles, and real PSD support, with over 1,700 tests and dual CPU and GPU compositors tested against each other.
- The agent story: an MCP server and JSON control protocol let an agent headless-edit documents or drive the live app, useful for bulk edits and first drafts.
- Tradeoffs are real: reviewers call most of the apps super early alpha, and trade dress claims from Adobe remain a live legal risk even for clean-room code.
- Sustainability matters: the founder says token sales from their ArtCraft AI model fund the work so it does not become an orphaned small-team project.
- What happens when open-source alternatives that once took years of community work can be built by a model in weeks?
- Reminds me of the chardet story we covered awhile ago. The reason I put this topic here is I think it encapsulates a lot of what's happening in the industry for devs now. Building software has changed, creating is easy - sustaining is hard, owning an idea is more fleeting than before, Rust obviously, MCP and CLIs. It's just an interesting bridge from the first 500 episodes and the next 500 likely.
Calvin:
Nick:
Brett:
Joke:
- Exceptional by Derrick Chambers
- Interviewer: It says here on your résumé that you’re an “exceptional Python developer.” Can you prove it?
- Me: Sure. Run any of my code. It raises exceptions a lot of the time.
