Python Bytes is a weekly podcast hosted by Michael Kennedy and Brian Okken. The show is a short discussion on the headlines and noteworthy news in the Python, developer, and data science space.

#503 It’s not 85% HTML

November 02, 2026 0:30:21 5.15 MB ( 24.1 MB less) Downloads: 0
Topics covered in this episode:
Watch on YouTube

About the show

Sponsored by us! Support our work through:

Michael #1: Your GitHub language bar is lying (how to fix it)

GitHub's language bar comes from Linguist, which counts every tracked byte in the repo. Michael's chameleon-rs project read as 75.5% HTML because committed docs-site output and test suites outweighed the Rust engine. Three .gitattributes attributes changed the story: linguist-generated for build output, linguist-vendored for an upstream test suite, and linguist-detectable=false for tests and benchmarks on both sides. The bar now shows the real mix, roughly 62% Rust and 38% Python.

  • That bar is one of the first things people see on your repo; if generated files skew it, a few lines of .gitattributes tell the truth.
  • The bar is byte-proportional, so a 9 MB committed docs build can make a Rust project read as mostly HTML
  • linguist-generated hides build output and collapses those diffs in pull requests too
  • linguist-vendored covers copied-in code; linguist-detectable=false drops anything from the stats
  • chameleon-rs went from 75.5% HTML to roughly 62% Rust and 38% Python after a few lines of config
  • Tests and benchmarks were excluded symmetrically, on both the Rust and Python sides, so neither skews the ratio
  • Check patterns before pushing with git check-attr; GitHub recalculates a few minutes after the push

Calvin #2: Python Typing Survey 2026: developers mix type checkers, and AI is writing the hints

  • Meta's 2026 Python Typing Survey results: 1,794 responses, Aug 5 - Sep 2. Pyrefly (Meta), JetBrains, Microsoft and Astral's ty team helped write it.
  • Typing is stable: 85.5% use hints often or always (88.0% in 2024). Which checker people use is not stable.
  • 49.9% run two or more checkers (46.0% in 2025), and 83.3% of Pyrefly users also run another one. Speed is the top reason for picking a checker (56.5%).
  • Checkers disagree: 33.3% report inconsistencies between them, rising to 42.7% among multi-checker users.
  • AI is writing the types: 42.5% had AI write hints, and 38.4% say types make AI code more reliable (18.5% last year).
  • 29.8% are "not sure" whether types help AI-assisted coding, about 4x the uncertainty on any other benefit.
  • Help sources flipped: Stack Overflow 46.4% to 22.9% and LLM chat 26.0% to 41.7%, 2024 to 2026.
  • Top pain is still missing library types (65.1%; Django, SQLAlchemy, pandas, NumPy). The most-wanted feature is better Callable syntax (45.7%). Raw data zip is linked.

Michael #3: Flask Vibe - Build Apps You Can Understand

Flask Vibe is a new tutorial site from Frederick Tubiermont, a developer who started coding at 47 and builds with Flask, PostgreSQL, raw SQL, and vanilla JS. The pitch: AI assistants generate more reliable, easier-to-verify code when the stack has no build step, no ORM, and no hydration. It ships a manifesto, tutorials on modular vanilla JS and AI-friendly coding patterns, and a Flask plus psycopg2 CRUD walkthrough.

  • For vibe coders burned by Next.js defaults on Lovable or Replit, this is a concrete, opinionated case that simpler Python stacks pair better with AI-generated code.
  • Claims a structural 1.8x LCP win over Next.js on the same dashboard app: 905ms vs 1.66s, both scoring Lighthouse 100
  • Tutorials cover modular vanilla JS, AI-friendly coding patterns, and Flask CRUD with raw psycopg2 SQL and no ORM
  • Creator started Python at 47 in 2022 and runs the site on the stack it teaches; the homepage is 42 KB with Lighthouse 100
  • Solo London-based project (adsyme Ltd), launched via an r/flask self-post in February 2026; early, opinionated, and the benchmark leans on one self-run comparison with its methodology published on site

Calvin #4: Python on my wrist: MicroPython on a PineTime

  • Michiel (Python Leiden user group) runs MicroPython on a PineTime, Pine64's ~$26 open smartwatch: 64 MHz Cortex-M4, 64 KB RAM, 512 KB flash.
  • He revived wasp-os, a dormant MicroPython watch OS stuck on a 2019 MicroPython fork whose maintainer is asking for new maintainers (issue #536).
  • The build is now one command with uv. Bluetooth flashing uses bleak instead of the deprecated gatttool, cutting update time from over 8 minutes to about 3.5.
  • Free RAM at boot went from 7.1 KB to 12.4 KB by using the flash chip's real 4 KB blocks. He also added a watchdog, plus vibration, touch and I2C dead-battery fixes.
  • His three upstream PRs (frozen native code, PWM, ADC sample time) are merged, so wasp-os now runs on mainline MicroPython. They're targeted for MicroPython 1.30, planned for December.
  • New faces: a Dutch week clock, and an 8-bit pixel clock that draws its digits without any font data and shows a live Unix epoch counter.
  • The Guido app: a 16-color, 80x80 run-length-encoded portrait (photo by Kushal Das, CC BY-SA). All four images total under 12 KB, versus 112 KB for one raw screen.
  • Next up is the PineTime Pro (AMOLED, GPS, dual-core M33), with no release date yet. Code is on the pinetime-upstream-micropython branch of mbeijen/wasp-os.

Extras

Calvin:

  • PyPI now caps version strings at 128 characters — https://blog.pypi.org/posts/2026-10-23-version-length-limit/
  • Wagtail Space — https://wagtail.org/wagtail-space-2026/

Michael:

Joke: Binging red buttons