The State of Python in 2026: A Visual Guide to Talk Python Episode 566

For most of Talk Python's history, the editor question had a settled answer. In the show's early years, Michael closed every interview by asking guests which editor they used, and the answers were all over the place, full of little tools he'd never heard of. Over six or seven years they narrowed to two. VS Code, VS Code, PyCharm, PyCharm. So he stopped asking.

AI has scrambled that answer. Even VS Code's own homepage now calls it "the open source AI code editor."

Sydney's path shows how far things have moved. She went PyCharm, then VS Code, then Cursor, because Cursor put agents into the editor before the others did. And today? About 90% of her work happens in Slack.

How does that work? LangChain has coding agents you can tag in a Slack message and hand a task to. Slack is already where the team talks through ideas and problems, so that's where the work starts. She reviews what the agent produced on GitHub, and if she leaves review comments there, the same agent picks them up and addresses them. Code only comes down to her own machine when she really needs to get into the weeds.

It's not as far out as it sounds. Michael has done something similar from his phone: he dictated what he wanted built to an agent, checked back later in chat to ask how it was going, and never touched an editor.

For contrast, Reuven went from Emacs to Jupyter to spending most of the past year in Claude Code, and figured that made him about as modern as it gets. (He tells his children he's as cool as it gets, too, and says one day they'll believe him.) By his own account, Sydney massively upstaged him. Calvin remembers the Zope days, writing code into a text area on a web page, which drove him a little batty. Doing it through a Slack agent "also kind of blows my mind."

Editors are only the start. Package managers, terminals, type checkers, docs and hosting are all moving too, and in most of them the reason is the same: tools now get picked partly for how well an AI agent can use them.

“My brain is melting thinking of Slack as your main coding editor. That is super wild.”

Reuven Lerner

The tools now run from manual editors through assisted ones to agentic tools. Does anyone actually march from one end to the other? Not on this panel. Most of them use something from each, depending on the job.

Calvin is the clearest case of the editor turning into a control room. He doesn't have VS Code installed, or any of its variants. His coding happens in two agent harnesses, Pi and Claude Code. To look at a file he uses bat, a nicer cat, and PyCharm is his "fallback fallback fallback" for when he really needs to dig in. So where does his time actually go? Reading Markdown. The Superpowers skills he uses have the agent write specs and plans first, and he reads those in a Markdown viewer before he tells the agent to build anything.

The habits underneath haven't changed, though. He's been a vi person for life - vi, then Vim, then Neovim - which made one PyCon lightning talk memorable for the wrong reasons, as the quote below explains.

Reuven's path ran Emacs, a bit of PyCharm, a lot of Jupyter, and for the past year mostly Claude Code. Back in school, he says, there were rumors of people who used an editor called vi, and everyone agreed those people clearly weren't serious programmers. It took him about a decade out of school to discover that smart people and good programmers use it too.

Pat has the longest editor history, easily. Pascal on punched cards at Iowa State, then IBM mainframes and the XEDIT editor. When work moved to PCs, Mansfield Software built KEdit to mimic XEDIT under DOS, and Pat still uses its Windows version today. Day to day, though, he's in VS Code because it connects remotely to AWS instances and in-house VMware machines, with Kiro, from AWS, for AI help. Last-minute tweaks on a running server happen in Vim, or in Nano when a server's Vim defaults block pasting.

For a richer AI client than a terminal, Calvin's picks are the JetBrains agentic client, OpenAI's Codex, or the Claude desktop app, which now includes Cowork and Code.

“I got on stage once at PyCon to do a lightning talk and somehow VI mode got disabled on my PyCharm and I was absolutely petrified.”

Calvin Hendryx-Parker

Terminals sound like a solved problem. Everyone just opens Terminal on the Mac, right? Not on this panel, and new terminals keep arriving.

Calvin hasn't used the stock Terminal in years. He's a big fan of Kitty, a cross-platform, GPU-accelerated terminal that scrolls text faster than just about anything. He kept it through three years of running only Linux on the desktop, a protest against Apple's Touch Bar, and kept it when Apple went back to a regular keyboard and he came back to the Mac. Kitty's built-in window management replaced tmux for him, and lately he's moved to herdr, an "AI native" multiplexer that handles remote sessions and agent management. He uses Mosh over a VPN so he can stay connected to agents running on any server, from any of his devices.

Reuven used iTerm2 for many years until he realized he was using maybe 10% of it. He never did figure out the tmux integration, or why he'd want it. A few months ago he switched to Ghostty and has been "super, super happy." When Claude Code started flickering and acting strangely with scrollback, he put it into its full-screen TUI mode, which gave him searchable history and a diff pane on the right.

Michael spent a long time on Warp but cooled on it as it tried to become its own coding agent. His friend Mark pointed him to cmux, which remembers workspace layouts, restores SSH connections when you reopen it, has an iPhone version, and is built on Ghostty. It seems to be catching on. While the two of them were looking at it in a coffee shop, a stranger came over, apologized, and showed off their own cmux setup. "So apparently at least three of us use it now."

Pat lives in Bash, often under WSL, and uses Royal TS to keep his saved SSH, RDP, SFTP and VNC connections organized on both Mac and Windows. He still uses tmux so long-running tests survive when credentials expire and the connection drops. Sydney's answer, by her own admission, is boring: she mostly uses the terminal built into whatever IDE she has open.

So why all the new terminals? Reuven's guess is that AI is driving the rush. Pat adds that they "have to rewrite it in Rust, too" (for the record, Kitty is written in C and Python and Ghostty in Zig). Calvin's point goes further. Terminal UIs and CLIs are turning out to be a great interface for agents. His email client, Spark, now ships a CLI. He can tell an agent to use it, or use it himself without leaving the terminal, and for local integrations he prefers that to an MCP server. The Talk Python CLI follows the same idea: install it with uv tool install, no authentication, and your AI can answer questions like "what did Sydney say on her first episode?"

“Can I just say how wild it is that in 2026, people are still developing new terminals.”

Reuven Lerner

Every panelist uses uv, which should make for a short conversation. What makes it interesting is why uv won so completely, and so quickly.

Calvin's explanation is the most honest. uv didn't change his opinions, it packaged them. He was already using pyenv for Python versions, pip with lock files and extra pinning flags for reliable installs, and pipx for installing tools. uv took all of that, made it consistent, and made it fast. Speed, he says, was the true feature. He's diplomatic about Poetry (it's a good tool if you're all in on it, and he wasn't), but he does admit that typing "poetry" in Six Feet Up's Slack used to trigger a bot reply with a haiku that was not favorable to it.

Sydney puts it bigger: uv sped up package management about as much as AI agents sped up coding. Reuven has the long view from years of PyCon talks. There were always two, three, four talks explaining the packaging mess, and they'd all end with some version of "if only we could solve this mess." Then uv showed up and handled versions, packaging, uploads to PyPI and Python installs, and did all of it fast. Speed was the gateway drug, but the real win for him was never having to activate and deactivate virtual environments again. "That was like magical." Things had gotten bad enough that xkcd once ran a comic declaring someone's Python setup a Superfund site.

Should anyone worry that OpenAI now owns Astral? This panel isn't worried. Pat says things carried on so normally he'd almost forgotten it happened. Reuven points out that corporate sponsorship of open source is nothing new, and that Astral has been a reliable steward so far.

uv also isn't tied to Python's own release cycle, as Calvin noted, and the recording date proved it. The episode was recorded on October 1st, Python 3.15's scheduled release day, and python.org still listed 3.14.8. Calvin had already run the 3.15 release candidate through uv python install for a Python Bytes demo, and Reuven's "get ready for Python 3.15" YouTube playlist told viewers to install it with uv months ago.

Why do AI agents like uv so much? Sydney's answer: models are trained on huge amounts of code, and code is verifiable. It runs or it doesn't, a test passes or it doesn't. uv was the leading package manager before AI took off, so models know it at the level of their weights, and they use it well to control the environment their code runs in. That matters beyond coding agents, too, because general-purpose agents also write code to get things done.

“I feel like uv was the speed up for package management that rivaled what AI agents did for coding.”

Sydney Runkle

PEP 723 inline script metadata lets a single Python file carry its own dependency list. You put a small comment block at the top of the file, and uv run builds the environment on the fly. For Pat, that's an everyday tool: 90-some percent of what he writes is a single-file script. (For side projects he still uses virtual environments, managed by uv now.)

One more line and the script doesn't even need a command in front of it. Calvin had been prompting his DevOps agents to use the PEP 723 section, and one of them, unprompted, also added a shebang that calls uv run. Run chmod 755 on that file and it's fully executable. "Nothing else needed. The magic just happens." At that point a Python script feels almost like a Bash script. Here's a file, just run it.

To make that concrete, here's a complete version you can copy:

#!/usr/bin/env -S uv run --script
# /// script
# dependencies = ["httpx", "rich"]
# ///
import httpx
from rich import print

print(httpx.get('https://talkpython.fm').status_code)

Save it, chmod +x it, and ./script.py runs with its dependencies in place. Every metadata line starts with #, because to Python the whole block is just a comment.

Why does this matter so much? Michael calls it uv's killer feature. uv lives outside Python, so it can be your way into Python. With Pat's style of script, the target machine doesn't need Python installed at all; uv fetches the interpreter and the dependencies. None of the older packaging tools could do that. You always had to set up Python first, then install the tool into it. A few years ago Calvin was seriously considering a containers-only approach just to get reliable installs, and uv made that unnecessary.

Is there a catch? Pat hit one. Corporate machine policies often block installing Python, and uv runs into the same wall. His workaround is WSL, where the rules are looser.

For tools rather than scripts, uvx is even easier than uv tool install, as Calvin points out. Type uvx and the package name, and it runs without you thinking about installing anything.

“I think one of its killer features is it lives outside Python, and it can be the way into Python.”

Michael Kennedy

Python isn't a strongly typed language, and that brings real challenges. Pydantic is a way to opt in to strong typing when you want it, for data modeling and validation. That's how Sydney frames it, and she knows it well: her open source start came from trying to make Pydantic work well with Django, and she later led maintenance of pydantic-core.

It's also why Pydantic is the backbone of FastAPI. Requests and responses are the bread and butter of an API, and they need structure.

So what's changed? In Sydney's view, FastAPI is what first made Pydantic popular, and LLMs are what made it more popular still. A language model produces text. Your application needs predictable, structured data. Pydantic sits in the middle, validating what came out of the model and turning it into objects the rest of your code can trust. "Here I am again on my like AI rant," she said, but it's a good rant.

Reuven arrived at the same place from the other direction, and admits it happened "embarrassingly recently." Type hints are great, he says, but Pydantic is amazing. His analogy: plain type hints are like Postgres columns having types. Pydantic is like adding CHECK constraints on top, so you can say a value must be greater than zero or below some limit and really tighten what's acceptable. He also gives the core developers credit for letting people slide into typing at whatever pace suits them.

“LLMs produce text and Pydantic is kind of the bridge back into like, let's validate that data and turn it into a predictable model that we can then use in code driven applications.”

Sydney Runkle

Should you type hint your Python? In 2026 the answer depends on who's writing the code. For code written by hand, this panel doesn't agree at all. For code an agent writes, they agree almost completely. (A pronunciation note first: Charlie Marsh says Astral's type checker is "ty," as in the letters T and Y.)

Here's where each of them landed:

• Sydney: all in. No surprise given her Pydantic years. The core team has made types much easier to express, ty makes checking very fast, and agents take on most of the boilerplate that used to make typing feel like a chore.
• Calvin: not by hand, yes for agents. What brought him to Python was a language that stays out of your way: duck typing, meaningful whitespace, none of the "hash rockets" and ASCII art of other languages. When he hand codes, he usually skips type hints. When AI writes the code, he wants them, for determinism and to catch whole classes of bugs before the code runs. He's glad Python doesn't force them on him, and he's not going anywhere: "I love the language."
• Pat: depends on the code. His single-file DevOps scripts go untyped. His AI-heavy side projects, some of which may go public, get types.
• Reuven: converted. He grew up a dynamic-language guy who thought types were for people who weren't, in his words, a "smart person like me." Then he noticed that people on a team make mistakes, and that developers coming from statically typed languages want the safety net. Now he's all in, maybe not for his own code, but for LLMs.
• Michael: public surface plus hard gates. He started on C++ and C#, so typed Python still looks clean to him. A package's public functions should be typed so callers can check their usage, but the internals don't need hints everywhere. For agents, the rule is strict: run ty, run Ruff, run the tests, and you aren't done until everything passes with zero warnings.

Which type checker? The answers split between ty and mypy. Sydney moved from mypy and Pyright to ty. Reuven still uses mypy, "embarrassingly old school," though he says this episode alone might change that. Pat ends up with mypy because that's what LLMs reach for. Calvin's best guess is that Six Feet Up's standards have moved to ty. Michael also likes Pyrefly, which is Rust-based and fast too, and he wore the Pyrefly shirt to prove it.

“I sometimes say to people that the things we can tell agents and LLMs are the sorts of things that would get us like written up for being of abusive behavior as a manager if we were to do all these things to the software developers on our team.”

Reuven Lerner

How do you pick a web framework when an LLM writes a lot of the code? Project size and raw speed still matter. But there's a new question now: how much of that framework's code have the models already seen?

Start with the classic matchup. Calvin and Frank Wiles just gave a DjangoCon talk comparing Django plus Django Ninja against FastAPI. The verdict? FastAPI is still faster, but not by a huge amount. Six Feet Up uses both and picks per job. Calvin's rule of thumb: if something may grow into something bigger, start with Django. If you need good-quality APIs up quickly for a specific use case, FastAPI fits, and you don't have to bring along Django's whole surface area. You can also change roughly one import and move FastAPI-style code to Django Ninja, so he still puts in a big plug for Django.

Michael's view is that FastAPI's "fast" was never really about raw performance. It's fast development done right, with Pydantic, OpenAPI and validation built in. Sebastián Ramírez, whose "little project" this is, has also leaned into the AI angle. Calvin praised his library skills project, which packages agent skills so your coding agent follows FastAPI best practices.

That question of what the models know is where Pat's reasoning starts. At work he uses Flask, specifically because LLMs have seen so much Flask code that they can easily produce something that works. For personal projects he uses Robyn, which is Flask-like, written in Rust and multi-threaded. He likes it, but there's far less Robyn code out there for models to learn from, so "you have to herd your agent to write the correct code."

Michael has a fix for exactly that problem. For lesser-known libraries like Robyn, he downloads the whole repo, docs included, opens a Claude Code session, and asks it to review every bit of the documentation and quick starts, ground it in the actual code, and generate a skill. That skill then goes into the project he's really building. It's been very successful for him.

Reuven, who doesn't do much web work, is fairly neutral. He used to reach for Flask because it was small and simple, and lately he built the back end of the practice system on his site with FastAPI. Either way, he sees the huge volume of existing Flask, FastAPI and Django code as a real advantage when an LLM is helping.

And one sad note: Calvin and Michael both miss Pyramid. Neither sees it as a real option today.

“To me, FastAPI is not about fast performance. It's like fast development of doing things right and comprehensively with Pydantic and OpenAPI and all those different things that it brings and validation.”

Michael Kennedy

Postgres is still the default. That part of the database story is quick. The movement is happening further down, in embedded databases.

First, the default. Reuven's entire answer was "Love Postgres, period." Calvin is on Postgres too, with a fond nod to ZODB, the Zope object database that served him well for decades. Pat's production systems are almost all Postgres. Sydney starts with Postgres for a lot of things, with an AI twist: the artifacts agents produce tend to be large, so she often pairs Postgres with blob storage. She also thinks data models are "back in vogue." If agents are going to query your data at scale, it has to be structured well.

Michael is the outlier. He's Team MongoDB, mostly because it's so easy to run. Most of his migrations amount to adding a column, and the code and the database just grow together.

So what's on the rise? Michael is on what he called an absolute kick for embedded databases. SQLite has had a lot of work to make it production ready: the write-ahead log, certain connection modes, durability through failures, cross-process locking. If what you're running lives on a single machine, he's starting to think an embedded database works a lot of the time. (WAL still allows only one writer at a time, but readers no longer block it.)

DuckDB has fans here too. Calvin likes its JSON features for building quick little CLI tools. Reuven has never used it as a database at all. He uses it as a query engine over Pandas data, where it's shockingly faster than Pandas itself. Pat has SQLite and DuckDB in the mix, and one of his side projects runs on LMDB, the Lightning Memory-Mapped Database, mostly because it sounded cool.

DuckLake pushes the embedded idea toward scale. Michael had just covered it on the show: you put Parquet files on S3 and use DuckDB, SQLite or Postgres as the metadata catalog in front of them, which scales a very long way.

“I've used it as a query system on pandas where it is shockingly faster than pandas itself on pandas data. I don't know how they pull that trick, but kudos to them.”

Reuven Lerner

This is about documentation for a package, library or framework, not a team wiki. Say you pull up the FastAPI docs. What's powering them?

These days, Zensical, the next-generation docs tool from the Material for MkDocs team. Calvin's team uses MkDocs itself and loves it. (Whether you spell out the M and K or say it as one word is still unsettled.)

Great Docs, from Posit, is Michael's favorite, and he feels it "doesn't get nearly enough love." He had a pile of little libraries that needed more than a README, so he finally moved them all to Great Docs. It comes from the same people who built Great Tables, as Reuven spotted. He's not publishing packages, so he has less use for it, but Calvin's case is that it doesn't matter. Even for personal projects, he wants beautiful rendered docs.

What makes these tools interesting in 2026 is the second audience: agents. Sydney recommends Mintlify, which LangChain's docs run on. Every page has buttons to copy the MCP URL, copy the page as Markdown for an LLM, and copy a prompt you can hand to your LLM so it can use that page. She believes Pydantic moved to Mintlify too, though nobody could confirm it on air.

Great Docs does much the same thing on its own. Each library gets a generated skills section that shows how to install the skill. Swap .html for .md in any page's URL and you get a Markdown version, so agents can read your docs directly. There's a copy-as-Markdown button, and it generates llms.txt and llms-full.txt for you. You can write any of this yourself, but if you don't, Great Docs creates it automatically.

“Even so, I still love these things for my own personal needs. I want beautiful rendered versions of my docs.”

Calvin Hendryx-Parker

Start with a price tag. Michael moved from DigitalOcean to Hetzner when Hetzner arrived in the US, and he's still there. But AI demand has changed hardware pricing "just a little bit." He has an 8-core, 16 GB Hetzner server that he pays $35 a month for. Its list price today? $130. So for all the talk about Hetzner being the cheap option, by his math DigitalOcean is now the better deal dollar for dollar. Shout-out to DigitalOcean for staying true.

The simple end of hosting still goes a long way. Reuven runs plain DigitalOcean droplets and says he's not a good example "unless you have very small, simple things." Michael doesn't think he should undersell it. If you run your stuff in Docker on a decent-sized server, you can go a really long way bringing your own stack instead of tying yourself to a pile of cloud services.

Calvin is all in on containers and works in two modes. One is full Kubernetes, either Talos Linux in a large cluster or K3s on a single node. The other is Cloudflare Workers, where Python is now a first-class language. He's been using Workers to replace Zapier zaps that had oddities or hoops to jump through. He just codes it up and releases it. (The Python Cloudflare Workers team is coming on Talk Python in a few weeks.)

At corporate scale, it looks different again. Pat's company runs 90% or more on AWS, with multiple EKS clusters and an ECS cluster, so lots of containers. It also has some workloads and authentication on Azure. And it "sort of backed into" Oracle Cloud: Oracle bought Zenedge, which Pat's company already used as a CDN, and that's how Oracle now runs their WAF.

“That's the real killer feature for me for Kubernetes is the control plane URL for releasing code without having to shell into a box and clone or pull anything.”

Calvin Hendryx-Parker

If agents are writing your code, how do you know how well they're doing it?

Start with what they actually do. The latest models lean hard on writing code, as Sydney points out. Watch the tool calls in a Claude Code session and it's no longer read file, write file. It's bash, bash, bash. You'll also see python -c followed by a giant string. Calvin doesn't love that. Every one of those calls needs his approval, and it makes his session reports harder to read. He'd like harnesses to grow more Python-native tools.

Those reports come from AgentsView, which he uses to review his own coding sessions and see how well he's working with the agent. It grades your context window usage, scores bad behaviors and points them out, and shows things like how much of a session went to bash calls. That's where the 85% comes from: Calvin has looked at sessions where 85% of the work was bash tool calls and wished he could tell at a glance what they were doing.

Normally AgentsView runs on one machine. Michael and Calvin found it at about the same time, on Python Bytes, and neither stopped there. Michael runs it as a daemon with a web view, and his Mac Mini, Mac Studio and MacBook all push to a central Postgres database in a Docker container, so he gets one view of all his AI work. Calvin has the same multi-machine setup. The scariest part, Michael warns, is the page that shows what your tokens would have cost at true API prices.

What should that kind of observability tell you? Sydney thinks about this a lot, and she frames the questions well. When an agent is inefficient, is it because of how the agent is structured, because you prompted it badly, or because it just isn't equipped for the task? Reuven had never heard of AgentsView and thought it looked amazing. Pat's team, which is keeping an eye on token spend, plans to take a look too.

“When I see 85% of the session was just bash tool calls, I'm like, I wish it kind of knew more granularly what those things were at a glance.”

Calvin Hendryx-Parker

One idea ties the episode together: a good tool now has two users, the developer and the agent working alongside them. Here's how that plays out, category by category:

• Running code. A PEP 723 script with a uv run shebang is as easy for a person to run as a Bash script, and just as easy for an agent to write. See PEP 723 and the uv shebang.
• Interfaces. CLIs and terminal UIs work for both. Calvin prefers a good CLI to an MCP server for local tools. See Terminals and CLIs.
• Packages. uv won on speed for people and on familiarity for models. See How uv won.
• Types and validation. Hand-written hints still split the panel, agent-written code nearly unites it, and Pydantic handles LLM output. See Type hints in 2026 and Pydantic as the bridge.
• Docs. Beautiful HTML for people, Markdown and llms.txt for agents, ideally from the same source. See Documentation for people and agents.

It isn't a clean split everywhere. When Calvin writes code by hand, he still prefers plain duck typing.

AI ran through nearly every category above. Here's what each panelist's own AI setup looks like - the people, not a list of tools.

Calvin mostly uses Pi, plus Claude Code, with the Superpowers skills. For models he likes Sonnet 5.5 or OpenAI's latest for most things. What annoys him is when a new release makes the latest Opus the default and it starts eating through tokens before he notices. For self-hosting, he recommends a Qwen model that runs on most machines with 32 GB of RAM or more.

Sydney thinks broader than one tool. Have a coding agent, sure, but also an agent in Slack and an agent wherever you keep your documents (Notion, for her). She's bullish on MCP for connecting your data and on skills for distilling domain knowledge. What excites her most is agents that improve over time through memory: coding agents that remember her preferences, and agents that help with blog edits by learning from past human reviewers' feedback. For more of that, she points to the LangChain blog.

Pat lets the tooling pick models automatically, while his team watches token spend. He uses Kiro and VS Code. He's tried running models locally, but the hosted ones have spoiled him and local feels "a little underwhelming."

Reuven uses Claude Code for about 95% of what he does and is very happy with it. He's also played with OpenCode, and Pi is on his "I really have to play with it" list because everyone keeps praising it.

Michael also lives in Claude Code, usually inside VS Code. For personal automations he's been using GLM models through inexpensive hosted providers, around five to ten dollars a month. Running them at home is out: by his estimate the Flash version needs around 750 GB of RAM, and the full model about 1.5 TB.

Even at this length, plenty went uncovered - "We didn't even touch on a bunch of topics," as Michael put it. Almost every part of the Python toolchain is moving at once. You don't need to adopt everything this panel uses. But it's worth asking yourself one question: if you were starting fresh today, which of your tools would you still pick?

If you want to go deeper on the two ideas the panel kept coming back to, working with AI agents and using types to keep code (and agents) honest, see Talk Python Training's Agentic AI Programming for Python and Rock Solid Python with Python Typing.

“I feel like Claude Code is like the Mac and OpenCode is like Linux, where it's like instantly extensible, but you have to spend a little more time with it and configuring and so forth.”

Reuven Lerner