Michael Kennedy's Thoughts on Technology

Cutting Python Web App Memory Over 31%

michael@mkennedy.tech (Michael Kennedy) — Wed, 01 Apr 2026 08:52:18 -0700

tl;dr; I cut 3.2 GB of memory usage from our Python web apps using five techniques: async workers, import isolation, the Raw+DC database pattern, local imports for heavy libraries, and disk-based caching. Here are the exact before-and-after numbers for each optimization.

Over the past few weeks, I’ve been ruthlessly focused on reducing memory usage on my web apps, APIs, and daemons. I’ve been following the one big server pattern for deploying all the Talk Python web apps, APIs, background services, and supporting infrastructure.

There are a ridiculous number of containers running to make everything go around here at Talk Python (23 apps, APIs, and database servers in total).

Even with that many apps running, the actual server CPU load is quite low. But memory usage is creeping up. The server was running at 65% memory usage on a 16GB server. While that may be fine - the server’s not that expensive - I decided to take some time and see if there were some code level optimizations available.

What I learned was interesting and much of it was a surprise to me. So, I thought I’d share it here with you. I was able to drop the memory usage by 3.2GB basically for free just by changing some settings, changing how I import packages in Python, and proper use of offloading some caching to disk.

How much memory were the Python apps using before optimization?

For this blog post, I’m going to focus on just two applications. However, I applied this to most of the apps that we own the source code for (as opposed to Umami, etc). Take these as concrete examples more than the entire use case.

Here are the initial stats we’ll be improving on along the way.

Application	Starting Memory
Talk Python Training	1,280 MB
Training Search Indexer Daemon	708 MB
Total	1,988 MB

How async workers and Quart cut Python web app memory in half

I knew that starting with a core architectural change in how we run our apps and access our database would have huge implications. You see, we’re running our web apps as a web garden, one orchestrator, multiple worker processes via the lovely Granian.

I’ve wanted to migrate our remaining web applications to some fully asynchronous application framework. See Talk Python rewritten in Quart (async Flask) for a detailed discussion on this topic. If we have a truly async-capable application server (Granian) and a truly async web framework (Quart), then we can change our deployment style to one worker running fully asynchronous code. Much less blocking code means a single worker is more responsive now. Thus we can work with a single worker instance.

This one change alone would cut the memory usage nearly in half. To facilitate this, we needed two actions:

Action 1: Rewrite Talk Python Training in Quart

The first thing I had to do was rewrite Talk Python Training, the app I was mostly focused on at the time, in Quart. This was a lot of work. You might not know it from the outside, but Talk Python Training is a significant application.

178,000 lines of code! Rewriting this from the older framework, Pyramid, to async Flask (aka Quart), was a lot of work, but I pulled it off last week.

Action 2: Rewrite data access to raw + dc design pattern

Data access was based on MongoEngine, a barely maintained older database ODM for talking to MongoDB, which does not support async code and never will support async code. Even though we have Quart as a runtime option, we hardly can do anything async without the data access layer.

So I spent some time removing MongoEngine and implementing the Raw + DC design pattern. That saved us a ton of memory, facilitated writing async queries, and almost doubled our requests per second.

I actually wrote this up in isolation here with some nice graphs: Raw+DC Database Pattern: A Retrospective. Switching from a formalized ODM to raw database queries along with data classes with slots saved us 100 MB per worker process, or in this case, 200 MB of working memory. Given that it also sped up the app significantly, that’s a serious win.

Change	Memory Saved	Bonus
Rewrite to Quart (async Flask)	Enabled single-worker mode	Async capable
Raw + DC database pattern	200 MB (100 MB per worker)	Almost 2x requests/sec

How switching to a single async Granian worker saved 542 MB

Now that our web app runs asynchronously and our database queries fully support it, we could trim our web garden down to a single, fully asynchronous worker process using Granian. When every request is run in a blocking mode, one worker not ideal. But now the requests all interleave using Python concurrency.

This brought things down to a whopping 536 MB in total (a savings of 542 MB!) I could have stopped there, and things would have been excellent compared to where we were before, but I wanted to see what else was a possibility.

Metric	Value
Before (multi-worker)	1,280 MB
After (single async worker and raw+dc)	536 MB
Savings	542 MB

How isolating Python imports in a subprocess cut memory from 708 MB to 22 MB

The next biggest problem was that the Talk Python Training search indexer. It reads literally everything from the many gigabyte database backing Talk Python Training, indexes it, and stores it into a custom data structure that we use for our ultra-fast search. It was running at 708 MB in its own container.

Surely, this could be more efficient.

And boy, was it. There were two main takeaways here. I noticed first that even if no indexing ran, just at startup, this process was using almost 200 megabytes of memory. Why? Import chains.

The short version is it was importing almost all of the files of Talk Python Training and their in third-party dependencies because that was just the easiest way to write the code and because of PEP 8. When the app starts, it imports a few utilities from Talk Python Training. That, in turn, pulls in the entire mega application plus all of the dependencies that the application itself is using, bloating the memory way, way up.

All this little daemon needs to do is every few hours re-index the site. It sits there, does nothing in particular related to our app, loops around, waits for exit commands from Docker, and if enough time has elapsed, then it runs the search process with our code.

We could move all of that search indexing code into a subprocess. And only that subprocess’s code actually imports anything of significance. When the search index has to run, that process kicks off for maybe 30 seconds, builds the index, uses a bunch of memory, but once the indexing is done, it shuts down and even the imports are unloaded.

What was the change? Amazing. The search indexer went from 708 MB to just 22 MB! All we had to do was isolate imports into its own separate file and then run that separately using a Python subprocess. That’s it, 32x less memory used.

Metric	Value
Before (monolithic process)	708 MB
After (subprocess isolation)	22 MB
Reduction	32x

How much memory do Python imports like boto3, pandas, and matplotlib use?

When we write simple code such as import boto3 it looks like no big deal. You’re just telling Python you need to use this library. But as I hinted at above, what it actually does is load up that library in total, and any static data or singleton-style data is created, as well as transitive dependencies for that library.

Unbeknownst to me, boto3 takes a ton of memory.

Import Statement	Memory Cost (3.14)
`import boto3`	25 MB
`import matplotlib`	17 MB
`import pandas`	44 MB

Yet for our application, these are very rarely used. Maybe we need to upload a file to blob storage using boto3, or use matplotlib and pandas to generate some report that we rarely run.

By moving these to be local imports, we are able to save a ton of memory. What do I mean by that? Simply don’t follow PEP 8 here - instead of putting these at the top of your file, put them inside of the functions that use them, and they will only be imported if those functions are called.

def generate_usage_report():
  import matplotlib
  import pandas
  
  # Write code with these libs...

Now eventually, this generate_usage_report function probably will get called, but that’s where you go back to DevOps. We can simply set a time-to-live on the worker process. Granian will gracefully shut down the worker process and start a new one every six hours or once a day or whatever you choose.

PEP 810 – Explicit lazy imports

This makes me very excited for Python 3.15. That’s where the lazy imports feature will land. That should make this behavior entirely automatic without the need to jump through hoops.

How moving Python caches to diskcache reduced memory usage

Finally I addressed our caches. This was probably the smallest of the improvements, but still relevant. We had quite a few things that were small to medium-sized caches being kept in memory. For example, the site takes a fragment of markdown which is repeatedly used, and instead of regenerating it every time, we would stash the generated markdown and just return that from cache.

We moved most of this caching to diskcache. If you want to hear me and Vincent nerd out on how powerful this little library is, listen to the Talk Python episode diskcache: Your secret Python perf weapon.

Total memory savings: from 1,988 MB to 472 MB

So where are things today after applying these optimizations?

Application	Before	After	Savings
Talk Python Training	1,280 MB	450 MB	1.8x
Training Search Indexer Daemon	708 MB	22 MB	32x
Total	1,988 MB	472 MB	3.2x

Applying these techniques and more to all of our web apps reduced our server load by 3.2 GB of memory. Memory is often the most expensive and scarce resource in production servers. This is a huge win for us.

Raw+DC Database Pattern: A Retrospective

michael@mkennedy.tech (Michael Kennedy) — Mon, 30 Mar 2026 08:31:17 -0700

TL;DR; After migrating three production Python web apps from MongoEngine to the Raw+DC database pattern, I measured nearly 2x the requests per second, 18% less memory, and gained native async support. Raw+DC delivered real-world performance gains, not just synthetic benchmarks.

About a month ago, I wrote about a new design pattern I’m seeing gain traction in the software space: Raw+DC: The ORM pattern of 2026. This article generated a lot of interest and a lot of debate. The short version: instead of using an ORM or ODM, you write raw database queries paired with Python dataclasses for type safety. This gives AI coding assistants a much larger training base to work from, reduces dependency risk, and delivers comparable or better performance.

Putting Raw+DC into practice

Now that some time has passed and I’ve thought about it more, I’ve had a chance to migrate three of my most important web apps to Raw+DC: Talk Python the podcast, Talk Python Courses, and Python Bytes.

So how did it go? From a pure functionality perspective, it went great. There were maybe one to three problems per web app. This might not sound great, and I didn’t love it, but given this is thousands and thousands of lines of code per app, that’s a small percentage of issues, given how many things went right.

More importantly, I was able to remove a dependency on two faltering database libraries. Mongoengine, the one that I’m going to pull numbers from for Talk Python Training below, has not had a meaningful release in years. It was one of the two core blockers that prevented me from using async programming patterns on the website entirely.

How much faster is Raw+DC than MongoEngine?

I said I imagined that we would save in memory and CPU costs, but did it actually pan out in a practical application? After all, we saw that Robyn, the web framework, is 25 times faster than Flask. However, in practice, it was almost a dead even heat.

I’m thrilled to report that yes, the web app is much faster using Raw+DC.

Below is an apples-to-apples comparison for Talk Python Training using MongoEngine and the Raw+DC pattern.

Metric	MongoEngine (ODM)	Raw+DC	Improvement
Requests/sec	baseline	~1.75x	1.75x faster
Response time	baseline	~50% less	~50% faster
Memory usage	baseline	200 MB less	18% less

The memory story is really great as well. After letting the web app run for over 24 hours for each mode, we saw a 200 MB memory usage decrease using Raw+DC.

That amount of memory might still look high to you. This Raw+DC transformation actually facilitates future work that will cut it in half again, down to about 500 MB for the full app, up and running in production at equilibrium.

Is Raw+DC worth migrating to?

To me, this seems 100% worth it. I’ve gained four important things with Raw+DC.

1.75x the requests per second on the exact same hardware and codebase (sans data layer swap)
18% less memory usage with much more savings on the horizon
New data layer natively supports async/await
Removal of problematic, core data access library

All of these benefits and none of that even touches on whether or not this new programming model is better for AI (it is).

Fire and Forget at Textual

michael@mkennedy.tech (Michael Kennedy) — Sun, 29 Mar 2026 09:37:44 -0700

If you read my Fire and Forget (or Never) about Python and asynchronous programming, you could think it’s a super odd edge case. But a reader/listener, Richard, pointed me at Will McGugan’s article The Heisenbug lurking in your async code. This is basically the same article, but in Will-style.

Will does say “This behavior is well documented, as you can see from this excerpt.” True, but the documentation got this emphasis and warning in Python 3.12 whereas the feature create_task was added in Python 3.6/3.5 timeframe. So it’s not just a matter of did we read the docs carefully. It’s a matter of did we reread the docs carefully, years later?

Luckily Will added some nice concrete numbers I didn’t have:

https://github.com/search?q=%22asyncio.create_task%28%22&type=code

This appears in over 0.5M separate code files on GitHub. To be clear, not every search result for create_task uses the fire-and-forget pattern, but just on the first page of results there are 5 instances.

If the design pattern to fix this is to:

Create a global set
When a task is added to the event loop, add it to the set
Remove it from the set when it’s done

Wouldn’t it have been better for the Python team to add this to the event loop internally once and solve this problem for everyone globally across the entire Python ecosystem?

It doesn’t look like that’s going to happen. So make sure you double check your code for create_task. And don’t let the Heisenbugs bite.

And yes, I know about task groups. Several people told me that we could use task groups to hang on to the task. Yes, that’s true. But task groups are incongruent with the fire-and-forget design pattern. Why? Because you create the group in a context manager and then you wait for all the tasks in the group to be finished. That doesn’t allow you to fire off a task and then continue working. So task groups may or may not have fixed Will’s problem, but they don’t solve the one I was originally talking about.

Replacing Flask with Robyn wasn't worth it

michael@mkennedy.tech (Michael Kennedy) — Mon, 23 Mar 2026 09:31:19 -0700

TL;DR; I converted Python Bytes from Quart/Flask to the Rust-backed Robyn framework and benchmarked it with Locust. There was no meaningful speed or memory improvement - and Robyn actually used more memory. Framework maturity, ecosystem depth, and app server flexibility still matter more than raw benchmark numbers.

Last week I played with the idea of replacing Quart (async Flask ) with Robyn for our bigger web apps. Robyn is built almost entirely in Rust, and in the benchmarks, it looks dramatically better. Not just a little bit faster, but 25 times faster. However, if you’ve been around the block for a while, you know that benchmarks and how things work for your app and your situation are not always the same thing.

So I picked the simplest complex app that I run, Python Bytes, and converted it entirely to run on the Robyn framework. This took a few hours of careful work and experimenting, and I even had to create a Python package to allow Robyn to run the Chameleon template language.

When I was done, it was time to fire up Locust and see if there was any dramatic performance improvements. I certainly wasn’t expecting 25x, but 2x? 1.5x? That would have been really impressive.

Did Robyn improve speed or memory over Flask?

The results were in and the answer was just about no difference in RPS or latency. It turns out that almost all the computational time is in the logic of our app, which of course doesn’t change and I never intended to change it.

Requests per second: No meaningful difference between Robyn and Quart/Granian
Latency: Essentially identical under load
Memory: Robyn actually used more memory, not less

Another area I was hoping to optimize is memory. Our web apps use a lot of memory for what they are. They’re certainly not trivial. But running a couple of copies of the app in a web garden was using way more than I expected that they should. And I thought moving closer to Rust might have positive influences for memory too.

It turns out the Robyn fork actually used more memory, not less, than the current setup. After all, our web apps run on Granian, which is mostly Rust right up to the Flask framework itself already.

Why Flask’s maturity still beats Robyn’s speed

So our fun little spike to explore the Robyn framework is going to remain just that. I’m sticking with Flask. I’ve talked about this before, but maturity in a library or framework is a big plus. The ecosystem for Flask/Quart is much bigger and more polished than for the smaller Robyn framework.

More than that, the app server runtime for Robyn is much less polished than some of the pluggable app servers out there. Think Granian, Gunicorn, uvicorn, etc. For example, Robyn does not support web garden process recycling. In many servers you can say after five hours or 10,000 requests or something like that, just slowly take the request out of a process, spin up a new one and shut down the old one just to keep things fresh. This helps if you’re using some library that holds on to too many caches or some other weird memory thing.

Was the Robyn experiment a waste of time?

Even though I spent maybe close to six hours working on this exploration and decided not to use it, I still found it super valuable. I created the fun Chameleon Robyn package to help people using Robyn have a greater choice of template languages. I got to see my apps from multiple perspectives. I built out some tooling for Claude that I’m going to write about later that is generally really awesome. And I ended up saving significant memory for some of my biggest web apps by just spending more time thinking about how I’m running them currently in Granian and Flask.

Use Chameleon templates in the Robyn web framework

michael@mkennedy.tech (Michael Kennedy) — Thu, 19 Mar 2026 16:18:41 -0700

TL;DR; Chameleon-robyn is a new Python package I created that brings Chameleon template support to the Robyn web framework. If you prefer Chameleon’s structured, HTML-first approach over Jinja and want to try Robyn’s Rust-powered performance, this package bridges the two.

People who have known me for a while know that I’m very much not a fan of the Jinja templating language. Neither am I a fan of the Django templating language, since it’s very similar. I dislike the fact that you’re mostly programming with interlaced HTML rather than having mostly HTML that is very restricted in what it allows in terms of coding. While nowhere near perfect, I prefer Chameleon because it requires you to write well-structured code. Sadly, I think Jinja won exactly because it allows you to write whatever Python code in your HTML you want. For most frameworks, Jinja is the only templating language they support.

Why migrate Chameleon templates to a new framework?

I’d love to try out some new frameworks, but I have so much existing Chameleon code that any sort of migration will never include converting to Jinja, if I have a say in it. Not because of my dislike for it, but because it’s incredibly error prone, and it would mean changing my entire web design, not just my code.

Here’s the code breakdown for just Talk Python Training.

That design category is 14,650 lines of HTML and 11,104 lines of CSS! If I can get Chameleon running on a framework, it will 100% reuse every line of that to perfection. If I cannot, I’m rewriting them all. No thanks.

How does Robyn use Rust to speed up Python web apps?

I’ve been thinking a lot about what if our web frameworks actually ran in Rust? Right now I’m running Quart (async Flask) on top of Granian. So Rust is the base of my web server and processing. But there is a lot of infrastructure provided by Flask and Werkzueg leading up to my code actually running that is all based on Python.

Would it be a lot faster? Maybe. My exploring this idea was inspired by TurboAPI. TurboAPI did exactly this as I was thinking about, but with Zig and for FastAPI. While I am not recommending people leave FastAPI, their headline “FastAPI-compatible. Zig HTTP core. 22x faster,” does catch one’s attention.

Eventually I found my way to Robyn. Robyn merges Python’s async capabilities with a Rust runtime for reliable, scalable web solutions. Here are a few key highlights:

Runtime: Rust-based request handling for high throughput
API style: Flask-like Python API, making migration straightforward
Async: Built-in async support out of the box

There’s this quite interesting performance graph from Robyn’s benchmarks. Of course, take it with all the caveats that benchmarks come with.

How to use Chameleon templates with Robyn

I want to try this framework on real projects that I’m running in production to see how they size up. However, given all of my web UI is written in Chameleon, there’s absolutely no way I’m converting to Jinja. I can hear everyone now, “So just use it for something simple and new, Michael.” For me that defeats the point. Thus, my obsession with getting Chameleon to work.

I created the integration for Chameleon for Flask with my chameleon-flask package. Could I do the same thing for Robyn?

It turns out that I can! Without further ado, introducing chameleon-robyn:

GitHub: github.com/mikeckennedy/chameleon-robyn
PyPI: pypi.org/project/chameleon_robyn

It’s super early days and I’m just starting to use this package for my prototype. I’m sure as I put it into production in a real app, I’ll see if it’s feature complete or not.

For now, it’s out there on GitHub and on PyPI. If Chameleon + Robyn sounds like an interesting combo to you as well, give this a try. PRs are welcome.

Fire and forget (or never) with Python’s asyncio

michael@mkennedy.tech (Michael Kennedy) — Wed, 18 Mar 2026 20:22:27 -0700

TL;DR; Python’s asyncio.create_task() can silently garbage collect your fire-and-forget tasks starting in Python 3.12 - they may never run. The fix: store task references in a set and register a done_callback to clean them up.

Do you use Python’s async/await in programming? Often you have some async task that needs to run, but you don’t care to monitor it, know when it’s done, or even if it errors.

Let’s imagine you have an async function that logs to a remote service. You want its execution out of the main-line execution. Maybe it looks like this:

async def log_account_created(username: str): ...

Someone new to Python’s odd version of async would think they could write code like this (hint, they cannot):

async def register_user():
    data = get_form_data()
    user = user_service.create_user(data)
    
    # Log in the background (actually no, but we try)
    log_account_created(user.name) # BUG!
    
    return redirect('/account/welcome')

You cannot just run an async function, you fool! Why? I don’t know. It’s a massively needless complication of modern Python. You either have to await it (which would block the main execution foiling our fire and forget intention) or you have to start it as a task separately. Here’s the working version (at least in Python 3.11 it works, Python 3.12+? Sometimes):

async def register_user():
    data = get_form_data()
    user = user_service.create_user(data)
    
    # Log in the background?
    # Runs on the asyncio loop, fixed, maybe
    asyncio.create_task(log_account_created(user.name)) 
    
    return redirect('/account/welcome')

Why asyncio.create_task loses tasks in Python 3.12+

Actually that fixed version has a tremendously subtle race condition that was introduced in Python 3.12 (seriously). In Python 3.11 or before, the async loop holds the new task and will just run it at some point soon.

Here is the first line in the docs for create_task:

Wrap the coro coroutine into a Task and schedule its execution. Return the Task object.

It schedules its execution. But in Python 3.12, it might forget about it!

I call functions like log_account_created fire and forget async functions. You don’t care to wait for it or even check its outcome. What are you going to do if logging fails anyway? Log it more? But check this out, straight from Python 3.14’s documentation:

Important: Save a reference to the result of [ asyncio.create_task ], to avoid a task disappearing mid-execution. The event loop only keeps weak references to tasks. A task that isn’t referenced elsewhere may get garbage collected at any time, even before it’s done. For reliable “fire-and-forget” background tasks, gather them in a collection:

background_tasks = set()

for i in range(10):
    task = asyncio.create_task(some_coro(param=i))

    # Add task to the set. This creates a strong reference.
    background_tasks.add(task)

    # To prevent keeping references to finished tasks forever,
    # make each task remove its own reference from the set after
    # completion:
    task.add_done_callback(background_tasks.discard)

Wait, what? If I start a Python async task it might be GC’ed before it even starts? Wow, just wow.

The fix? Well, you just create a set to track them (keep a strong reference in GC-parlance). In our example, it looks like this:

background_tasks = set()

async def register_user():
    data = get_form_data()
    user = user_service.create_user(data)
    
    # Log in the background
    task = asyncio.create_task(log_account_created(user.name)) 
    background_tasks.add(task)                       # prevent GC
    task.add_done_callback(background_tasks.discard) # cleanup when done
    
    return redirect('/account/welcome')

One obvious way to do it

This set hack is entirely non-obvious that this is required. After all, the Zen of Python states:

There should be one – and preferably only one – obvious way to do it.

But Zen doesn’t always apply, does it? I’m sure there is a reason for this change, though I’m not sure it was worth it.

If it were up to me, Python would come with one omnipresent event loop running on a background thread. Just calling an async function would schedule and run it there. The await keyword would be a control flow only construct, not the thing that actually does the execution.

But it doesn’t work that way and so we get oddities here and there I guess.

Update: See my follow up post Fire and Forget at Textual for more details.

Will AI Kill Open Source?

michael@mkennedy.tech (Michael Kennedy) — Thu, 12 Mar 2026 11:39:47 -0700

TL;DR; No - AI won’t kill open source, but it will reshape it. Small, single-purpose packages (micro open source) are likely to languish as AI agents write trivial utility code on the fly. But major frameworks, databases, and runtimes like Django, Postgres, and Python itself aren’t going anywhere - AI agents actually prefer reaching for established building blocks over reinventing them. The key is staying in the architect’s seat.

AI will replace the trivial, leave the foundational, and force us to rethink everything in between:

Micro open source (utility packages): Likely to decline – AI writes trivial code faster than importing it
Mid-level libraries: Case-by-case – depends on complexity and maintenance burden
Major frameworks and infrastructure: Safe – AI agents prefer uv pip install over reinventing Django

I sat down with Paul Everitt to debate this question, and it turns out the answer is way more nuanced than a simple yes or no.

Watch the full conversation on YouTube →

Why would AI rebuild what frameworks already provide?

Paul kicked things off with a great framing. Think of building an app like a 100-meter soccer field. A framework like Flask or Django gets you 95 meters down the field. You and your AI agent only need to handle the last 5 meters – the part that’s unique to your app.

Why would an agent rebuild those 95 meters from scratch when it can just uv pip install the framework and focus on the hard part? Software is a liability, not an asset, and owning all of that code means owning all of those future bugs.

But there’s a counterargument: if you only need 10% of a framework, you’re still dragging in the other 90% – attack surface, security issues, maintenance burden. Maybe you’re better off owning a small thing than renting a large one?

Will AI replace small open source packages?

I think the real casualty here is micro open source – those tiny packages that wrap a single function or a handful of utility classes.

Evidence? Tailwind usage: It’s up 600% in the last 18 months, largely because AI loves reaching for it. But the revenue story for Tailwind is heading in the opposite direction. AI can easily write the 47 utility classes you actually need instead of pulling in the whole framework.

What should go? Micro-packages: There’s the left-pad cautionary tale. A single trivial function as a standalone package took down huge swaths of the JavaScript ecosystem when its maintainer pulled it. AI should absolutely be writing those two functions for us instead of importing a package for them.

Can AI replace major frameworks like Django or Postgres?

Here’s what I don’t see happening: an AI saying “let me rebuild Postgres for you” or “give me an hour, I’ll recreate Django from scratch.” Even if it could, why would it? The agent’s goal is to solve your problem well and quickly. uv pip install django is faster and more reliable than conjuring up a bespoke web framework.

At the macro level, frameworks, databases, runtimes, open source is safe.

Will AI coding costs make open source irrelevant?

Paul raised an important point: what happens when AI pricing subsidies end and costs go up 5x? My take is that hardware costs are dropping even faster.

NVIDIA’s latest inference hardware is roughly 10x cheaper per token than two years ago:

“NVIDIA GB200 NVL72 with extreme hardware and software codesign delivers more than 10x more tokens per watt, resulting in one-tenth the cost per token.”

And the Apple Silicon trajectory means serious local model capability is coming to everyone’s laptop. The bubble isn’t as extreme as people imagine.

How should developers work with AI agents on open source projects?

We also dug into the “just send it” overnight agent workflow – and neither of us is a fan. Working in small, reviewable chunks is the way. Think spec-driven development, not “agents devour this, I’ll see you in the morning.”

Our job was never to type characters. It’s to ship quality software. If you apply engineering discipline – specs, tests, architecture decisions – then AI-assisted code is absolutely something you can put your name on. Paul shared his crisis of confidence the first time he hit Enter on twine upload for an AI-assisted package. I think a lot of developers can relate to that moment. But the question comes down to: did you ship something well-built that serves a purpose? If yes, the tooling you used to get there matters a lot less than you think.

Here’s the workflow that actually works:

Choose your frameworks and specify your stack up front
Work in small, reviewable chunks – not overnight agent runs
Use spec-driven development with tests and architecture decisions
Review all AI-generated output before shipping

Will AI kill open source? The verdict

Micro open source is probably toast. The big building blocks aren’t going anywhere. But the key is to stay in the architect’s seat – choose your frameworks, specify your stack, review the output. Be the architect handing specs to the contractor, and don’t give that role away to the AI.

There’s a lot more in the full conversation including anti-AI vigilante groups shaming people for publishing agent-assisted packages, the open source gift economy, and why none of us really know where this is all heading yet.

Watch the full video with Paul Everitt →

What hyper-personal software looks like

michael@mkennedy.tech (Michael Kennedy) — Fri, 06 Mar 2026 11:32:30 -0800

Have you heard that the age of hyper-personal software is upon us?

Typically what people mean is that agentic AI allows the creation of simple and small software built by individuals, often not super technical individuals, to solve a personal problem. As a result, we will see this explosion of software and the death of SaaS.

Naysayers point to the lack of many new software projects being launched as proof that agentic AI is all hype.

It’s not hype. It’s just that much of this software is hidden. Maybe we’ll call it dark matter software.

Hyper-personal software, an example

I personally have many of these dark matter software projects. So I thought I would share an incredibly straightforward one to inspire you as well as make the concepts concrete.

I’ve stopped using Google search a long time ago. I’m not a big fan of how it works, the tracking, and so much more. I bounced around from different search engines, even used the paid Kagi one for a while.

These days I’m using Start Page at https://www.startpage.com. It’s great, very fast, has good results, and cleans up much of the extra junk that Google adds to its results.

However, recently they started adding advertisements, sponsored links to their results. Now, if these were chill, small, little sponsored links, I would have absolutely had no complaint with them. After all, I do want to support Start Page. But the amount of ads that were included is pretty egregious.

Here are the results for searching for an AI course on my 5k monitor:

Check this out. Even on a huge monitor, not a single organic result is visible. This is expected from Google, but not here (not for me anyway).

Claude, I need a browser extension

I am very hesitant to install third-party browser extensions. A few hundred are outright malicious. And most frightening of all, sometimes the good ones get hijacked, phished, or outright purchased by less well-meaning folks.

But what I need to solve this problem is a browser extension.

I could create one from scratch. I could go through all the tutorials and so on and actually create one. It wouldn’t take that much time. Maybe half a day? But this problem is not that bad. I can page down once or hit the space bar after a search and deal with it. I don’t want to waste half a day which likely turns into 2 days. ;)

This is where agentic coding comes in. Instead of continuing to be frustrated yet again after doing a search, I fired up Claude Code inside of my editor and asked for a web browser extension that would remove just the ads from Start Page. I gave it the exact example HTML that is used. I described what I want, I hit enter, and I walked away.

I came back 15 minutes later and I had a local browser extension. Of course, instead of publishing it to the Chrome Web Store, I just loaded it locally.

I was so ready to run my next search. I gave it a try and there were literally no results on the page. It didn’t work. But after one or two more exchanges with Claude to narrow down the selectors, I have a perfectly crisp start page result set.

Look at that crystal clear search page. My hyper-personal browser extension solved my problem perfectly.

Startpage-clean is just for me

It’s a small project as you can see from Tallyman.

Even so, I have no intention of sharing it with the world. I don’t want to create or maintain yet another ad blocker. If something like Ad Block Plus or whatever wants to take this on they can.

I had a problem that software would solve. I spent 10 active minutes and I had that software created exactly as I wanted it. That’s hyper-personal software.

So where is this explosion of software?

Now, when you hear people claim that agentic AI is a productivity bust, think back to this example. It’s the perfect use-case on an absolutely zero stakes project that tangibly changes my day-to-day work, and yet no one will ever see it. You wouldn’t even know it existed if I didn’t take the time to use it as an example.

There’s a lot of dark matter software out there, and its genesis is just beginning.

More to come

Beyond dark matter software, I think there will legitimately be an explosion of new software because of AI. I have a lot more to say on this with concrete examples as well. So be sure to subscribe to the blog if you’re not already.

Raw+DC: The ORM pattern of 2026?

michael@mkennedy.tech (Michael Kennedy) — Mon, 09 Feb 2026 19:29:08 -0800

Recently I have started going Raw+DC on my databases. I think I love it. Let me explain.

TL;DR; After 25+ years championing ORMs, I’ve switched to raw database queries paired with Python dataclasses. I’m calling it the Raw+DC pattern. The result: better AI coding assistance, fewer aging dependencies, comparable or better performance, and type safety where it counts.

	ORM/ODM	Raw+DC Pattern
Type safety	Built-in via entity classes	Dataclasses at the data access boundary
AI coding support	Limited by library popularity	Excellent - vanilla query syntax is 1,000x more common
Dependency risk	High: ORMs can go unmaintained	Low: only the DB driver
Performance	Overhead from serialization/validation	Near-raw speed
Query complexity	Abstracted by ORM	Native queries

Why developers use ORMs and ODMs

For almost my entire programming career I have been a massive proponent of the concept of an ORM (relational) and ODM (document) for talking to a database. ORMs provide several key benefits:

Type-safe entity classes mapped directly to database tables
SQL injection prevention - no more little bobby tables wrecking your day
Complex query abstraction - eager joins expressed in Python, not SQL
IDE autocompletion on every entity field

People would tell me that I’d get better performance if I just did raw db queries that returned tuples or documents. I didn’t care. I still don’t.

But ORMs come with trade-offs (going forward assume ORM and/or ODMs ;) ). You have the entity classes sure. But the ORM usually has some dependencies that can be a hassle. They can be finicky in ways that go beyond what you care about.

How raw database queries work (pymongo example)

There is something lovely about the pure simplicity of a direct query in the native query language of the database. Here’s a pymongo example:

db = get_db(ctx)
doc: dict = db.orders.find_one(
    {'order_number': order_number},
    {'customer_email': 1, '_id': 0}
)

Go to the table orders
Find the one with the order number order_number
Return only the customer_email (not even the primary key id)
Done.

This query is simple, but they can get increasingly complex. ORMs seriously help for complex queries (think multiple eager joins!) Maybe you don’t want to write those complex queries. I sure don’t and didn’t see the benefit of doing so except in a very narrow high-traffic use-cases.

Another benefit of ORMs is that your IDEs and type checkers can tell you exactly where an ORM class is being used since every query is expressed in terms of one or more of these classes.

Why AI coding assistants work better with raw queries

You see, I have this friend named Claude. He’s really good at programming. Gets distracted, but if kept on track he can nail a three-way eager join in SQL.

Seriously now. After a significant amount of experience programming ORM-backed projects with Claude Opus/Sonnet, it dawned on me that I’m writing fewer of the queries by hand and just telling Claude what to do. And we have to keep in mind one of the key rules of working with agentic coding:

My universal 7th rule of agentic coding: AI coding works best for extremely popular languages, tools, and platforms. Given a specialized tool or framework vs. a general “vanilla” one, choose vanilla if everything else is equal.

Claude knows the Beanie ODM great (which I use for some of my apps). But do you know what it knows better? Pure, native MongoDB query syntax. Vanilla.

Look at these stats:

Beanie: 1.4M downloads/month PyPI Stats
PyMongo: 74.2M downloads/month PyPI Stats

PyMongo is 53x times more popular. The syntax it needs is actually identical across the Node/Deno/Bun ecosystem, the PHP ecosystem, and many others. This makes the examples of pymongo (aka native MongoDB) queries likely 1,000x more common. Agentic AI will likely do much better with this query foundation.

How to keep type safety without an ORM

Remember my adoration of the type safety and the IDE support? Coding with classes returned from the DB queries is unquestionably better in most cases. You specify the return type (db class), get a return value named result, type result. and boom, a list of fields appears before your eyes. This also works for powering ty, pyrefly, and all the other type checkers.

My realization is that we don’t actually need the types baked entirely into the queries. I just want to talk in Python classes beyond the data access layer.

Enter dataclasses.

If we just make the data access layer convert results to data classes when it’s to our benefit and keep them as single values (scalars) for basic queries, we get almost all the benefits of a full ORM without many of the drawbacks. This is the core of the Raw+DC pattern.

Here’s an example from MongoDB/pymongo. Notice the embedded data classes Address, Payment, StatusEntry, and LineItem.

@dataclass(slots=True)
class Order:
    id: ObjectId
    order_number: str
    customer_email: str
    status: str
    total_cents: int
    item_count: int
    created_at: datetime
    updated_at: datetime
    shipping_address: Address
    payment: Payment
    line_items: list[LineItem]
    status_history: list[StatusEntry]

We just write a to/from dictionary method to handle the top-level classes and we have a much lighter weight data access layer.

def order_from_doc(doc: dict) -> Order:
    return Order(
        id=doc['_id'],
        order_number=doc['order_number'],
        customer_email=doc['customer_email'],
        status=doc['status'],
        total_cents=doc['total_cents'],
        item_count=doc['item_count'],
        created_at=doc['created_at'],
        updated_at=doc['updated_at'],
        shipping_address=Address(**doc['shipping_address']),
        payment=Payment(**doc['payment']),
        line_items=[LineItem(**li) for li in doc['line_items']],
        status_history=[StatusEntry(**sh) for sh in doc['status_history']],
    )

I can already hear the critics: “You’ve just built a worse ORM by hand!” Fair point. But this thin conversion layer is exactly the kind of boilerplate that AI coding assistants excel at generating and maintaining. When your dataclass changes, Claude can update order_from_doc in seconds. It’s fully transparent (no framework magic to debug), has zero dependencies beyond the standard library, and you own every line of it.

Now, before you close your browser in disgust, let me share two bits of data:

Why ORMs go unmaintained (and raw queries don’t)
Performance benchmarks

Why ORMs go unmaintained (and raw queries don’t)

This one makes me sad. But I’ve been doing Python and working with amazing packages from PyPI long enough to see it over and over.

Some of these ORMs just start to fade into obscurity due to neglect.

My beloved Beanie ODM has only had a few releases in 2025. Latest release: 4 months ago. Open issues: 91. Pending PRs: 18 (one of which is for a bug I’ve been chasing for years now).

Before Beanie, I was using mongoengine. Some of my major apps still run on mongoengine. But it hasn’t seen a release in years. It never got updated to async. Sad face.

Working closer to the DB means you only really go into unmaintained mode if the DB itself does. For example, pymongo had a release just a few weeks ago. Plus, we can always move the raw queries to another library like motor if needed.

Raw queries vs ORM performance: dataclasses + pymongo benchmarks

The Raw+DC pattern is as fast as pure raw queries and significantly faster than ORMs for large datasets. No one would question whether just running dictionaries in/out in raw queries would be faster than doing full entity class serialization and validation on top of that same layer.

But what actually is the cost of my recommended frankenstein raw queries + data classes? Is it actually worse than the ORMs?

Spoiler: low and not at all.

Check out the graph (click to zoom). Data classes + raw = purple, orange = Beanie, green = mongoengine. The - - - - blue line is pure pymongo.

You can see any time you’re working with large amounts of data, Raw+DC is actually much faster. Beanie represents well all things considered. MongoEngine is seriously showing its age.

Performance comparisons are always fraught with pitfalls. But you get a sense of things from the picture nonetheless. You can explore all of this code and run it for yourself. Check out the GitHub repo at:

ORM vs Raw MongoDB Benchmarks: github.com/mikeckennedy/orm-vs-raw-mongo

You’ll need MongoDB running. Just run this docker command then you can run the demos:

docker pull mongo:latest && docker run -d --rm -p 0.0.0.0:27017:27017 --name mongosvr mongo:latest

Then run this in the main repo:

uv sync
uv run main.py run

Should you switch from an ORM to raw queries?

Here’s my final case for the Raw+DC pattern, letting Claude (or you) write raw queries, adapted to light-weight dataclasses at the data access layer.

Your query library and code is much less likely to go out of support
It’s very fast
You still get typed support anywhere you are writing code
You have fewer (often many fewer) dependencies

So are you going to go Raw+DC? Give it a try and see what you think.

Just be careful to always use safe query practices when using user input. That means parameterized queries for SQL and always convert user input to strings (not dictionaries) in MongoDB.

Frequently asked questions about ditching your ORM

Is it safe to use raw database queries instead of an ORM?

Yes, as long as you follow safe query practices. For SQL, always use parameterized queries, never string concatenation. For MongoDB, always convert user input to strings (not dictionaries) to prevent query injection. The ORM’s safety comes from parameterization, and you can do that yourself.

Are raw database queries faster than ORMs in Python?

Yes. Raw queries with dataclasses (the Raw+DC pattern) perform nearly identically to pure raw dictionary queries and significantly outperform ORMs like Beanie and mongoengine on large datasets. The dataclass conversion overhead is minimal compared to full ORM entity serialization and validation.

How do you get type safety without an ORM?

Use Python dataclasses (or Pydantic models) as your entity types. Write a thin conversion layer, to_dict() and from_doc() methods, at the data access boundary. Beyond that boundary, all your application code works with fully typed classes, giving you IDE autocompletion and type checker support.

Do AI coding assistants work better with raw queries or ORMs?

AI assistants like Claude work dramatically better with raw/native query syntax. PyMongo has 53x the downloads of Beanie, and native MongoDB query syntax is shared across Node.js, PHP, and other ecosystems, making training examples 1,000 of times more common. More training data means more accurate, reliable code generation.

Your Terminal Tabs Are Fragile. I Built Something Better.

michael@mkennedy.tech (Michael Kennedy) — Thu, 05 Feb 2026 18:54:46 -0800

TL;DR: I built Command Book, a native macOS app that gives your long-running terminal commands a permanent home. Free to download at commandbookapp.com.

Terminal pain points

I’ve been a terminal power user for over 20 years. And I’m done using terminal tabs as a process manager. Here’s why.

It’s a familiar tale. You sit down to work in the morning and you have to get a host of apps up and running before you can start coding. Maybe your terminal looks a bit like this.

------------------------- Terminal -----------------------------
| python | [python] | python | python | docker | tail | zsh     |
-----------------------------------------------------------------
|  $ python src/app.py --reload                                 |
|  Flask app starting up... listening on http://127.0.0.1:5000  |
|  ...                                                          |

It’s pretty common! And until recently, that’s how I started my day.

First tab is running a background daemon for processing long running requests.
Second is my flask app in dev mode (restart on changes)
Third is another python script watching the design files for changes
Fourth is docker running the database
Fifth, tailing the production log from changes I just posted to keep an eye on them
Sixth, an inactive shell that I can run various ad-hoc commands on

Each of these commands requires that I remember which working directory to start in (the daemon runs somewhere else than the flask app for example). Getting them up and running is a bit tedious. Certainly doable, but tedious.

You’re working through the day, and you realize some part of your app isn’t working. It crashed. Why? You had --reload set and it dutifully reloaded on file changes. But the code was half-ready. You or Claude wrote the import statement, import new_feature, but you haven’t yet created that module. Or maybe it reloaded while you were mid-function having written def scan_files( and you get an unmatched brace. Reload fails and you’re hunting through terminal tabs for which part stopped working and needs to be restarted.

What I actually needed

Terminals are great for interactive work, exploration, quick commands. But they are terrible as a process manager. What I wanted was a command/process manager for long running commands currently living in my terminal.

I wanted them to be reproducible, instant, reliable and auto restarting if code changes, not just reloading unless the code gets out of sync.

I wanted a terminal companion.

Introducing Command Book

I didn’t find this app. So I built it. After 10 years of running Talk Python, Talk Python Training, and a handful of other production apps, I knew exactly what I needed, and what was missing.

Introducing Command Book: A native macOS app built with SwiftUI – no Electron, no Chromium, just a fast, lightweight experience that feels at home on your Mac.

Command Book is for people like me: Developers juggling a web server, a database, a couple of background workers, and a log tail every day. Data scientists who kick off long training runs and need to know when they crash. Anyone who’s tired of Electron apps chewing through 500 MB of RAM to do something a 21 MB native app handles just fine.

How it works

——— Save a command once, run it forever ———

Create a command, specify a working directory, env vars, pre-commands like git pull, and the main command to run. For example, to work on talkpython.fm I have this command:

Command: python talk-python/web_app.py --reload
Working directory: ~/github/talk-python-web/
Pre-command: git pull

——— Auto-restart on crash ———

Command Book can go into Honey Badger mode to keep you productive. You can check a box to always restart the command when it crashes. This is perfect for that dev-server --reload command, except when something goes wrong like an unmatched brace then reload becomes crashes. Now Command Book will restart it until the code is fixed.

It is configurable with a delay so it doesn’t go too Honey Badger.

——— Keyboard-first with ⌘K ———

Command Book is a GUI, but one built for developers. So it’s very keyboard focused (it also comes with a CLI interface). Many actions are keyboard first. This is most evident with our command palette. Pressing ⌘K, you can search, run, and create saved or ad-hoc commands.

——— URL detection ———

Another papercut Command Book looks to solve is getting back to your dev server. Did you click the link when the server started but absent-mindedly close the browser an hour later? Now the terminal output has scrolled back 1,000 lines and you have to hunt for the URL to get back?

This is a common problem with Flask, Django, Node, Jupyter Notebooks, and many more.

So when a command runs, Command Book grabs the first few urls and keeps them accessible at the top of the command output. That way, you can always get back to the running app regardless of how much output has streamed by.

——— CLI integration ———

Command Book’s GUI lets you configure commands with precision: working directories, pre-commands, environment variables, auto-restart behavior, and more. The CLI brings all of that to your terminal with zero extra setup.

Instead of remembering the full incantation, you just run commandbook run talk-python-dev and it does exactly what the GUI would do - same directory, same env vars, same everything.

$ commandbook run talk-python-dev

Download Command Book for free

Command Book comes with a free personal license as well as a paid, pro edition. You should definitely be able to see if the app is useful for you with the personal edition. To get started, just download Command Book for free at:

commandbookapp.com/download

If you do decide to upgrade, it’s just $14.99 one-time. No subscription. No account. No tracking.

There’s no VC runway behind this app, no enterprise upsell waiting in the wings, and no tracker phoning home. Just a tool that gets better because users support it directly. Zero enshittification. If Command Book saves you from rebuilding your terminal setup even once, it’s paid for itself.

Feedback and roadmap

I’d really appreciate it if you gave it a look, shared it with your team, and sent me feedback. Feel free to email me with feedback. Consider signing up for announcements (the newsletter) too.

The app is still getting final touches. So community input can truly drive the direction of what comes next. For example, a Windows version is under consideration and more features planned.

It's not vibe coding: Agentic engineering

michael@mkennedy.tech (Michael Kennedy) — Thu, 05 Feb 2026 16:21:01 -0800

I’ve been bewildered by the wide range of experiences that software developers observe when working with AI. This has led many of us to outright reject AI for coding.

There are reasons for this variance.

Skeptics want to lightly dip their foot in the water to see what it’s about. This manifests as using the cheapest or free models and “just send it” styles of programming. Then they lament that what comes out is not what they would have built nor is it what they wanted.

Meanwhile, professional developers adopting agentic AI for coding operate differently. They see spending $100+/mo on AI tools as a great bargain. They spend hours planning and refining and decomposing a problem before they send a single request to their fancy AIs. Code carefully matching their request is often the outcome.

Is it a surprise they are getting different results? I’ve seen both styles and it’s no surprise to me.

These two experiences often get lumped under the same term: Vibe Coding.

They are not the same.

Today I ran across an essay by Addy Osmani, “Agentic Engineering.”

Addy really nails this difference and spells out a term that I’m keen to adopt: Agentic Engineering.

Vibe coding means going with the vibes and not reviewing the code. That’s the defining characteristic. You prompt, you accept, you run it, you see if it works. If it doesn’t, you paste the error back and try again. You keep prompting. The human is a prompt DJ, not an engineer.

…

Here’s the thing: a lot of experienced engineers are now getting massive productivity gains from AI - 2x, 5x, sometimes more - while maintaining code quality. But the way they work looks nothing like vibe coding. They’re writing specs before prompting. They’re reviewing every diff. They’re running test suites. They’re treating the AI like a fast but unreliable junior developer who needs constant oversight. I’ve personally liked “AI-assisted engineering” and have talked about how this describes that end of the spectrum where the human remains in the loop.

…

It draws a clean line. Vibe coding = YOLO. Agentic engineering = AI does the implementation, human owns the architecture, quality, and correctness. The terminology itself enforces the distinction.

Give the full article a read.

That last quote is important. Many devs dread AI because they don’t want to be a full time reviewer for marginal code. But if “AI does the implementation, human owns the architecture, quality, and correctness”, that sounds like senior developers’ job descriptions to me.

It’s something to think about.

Blocking AI crawlers might be a bad idea

michael@mkennedy.tech (Michael Kennedy) — Wed, 21 Jan 2026 12:04:53 -0800

TL;DR: You can’t stop people from using AI or put it back in the box. Blocking AI crawlers feels satisfying but just makes you invisible to users who rely on AI recommendations. This post covers the tradeoffs content creators face in an AI world and why embracing AI integrations beats hiding from them.

Over at Talk Python To Me, I added a couple of deep AI integrations. You can read about them here at talkpython.fm/blog/posts/announcing-talk-python-ai-integrations/. A couple of folks in the community asked what I thought about how embracing AI consumption of our content would affect us. Or, how in the light of the tailwind situation, it might even undermine us.

Wait, what happened to Tailwind?

If you’re not familiar with the Tailwind situation, the TLDR is that their usage has gone up 6x over the last year while the revenue has fallen to one-fifth of what it was a year prior. Basically, AI is using and recommending Tailwind like crazy, which counterintuitively has destroyed their web traffic, and hence reduced people seeing and upgrading to their pro offers.

Fear of AI ingestion

I know many content creators (writers, podcasters, and so on), are pretty frustrated with AI. I totally get it. We all work very hard to create content that gets ingested by AI. Then people ask questions of the AI. AI uses our content to answer the question, usually without referencing our work.

This has led a lot of people to think that maybe they should block AI from even reading what they’re doing. Here are some examples:

I get the frustration and the ick factor. But I fear that blocking AI is going to end up in a similar situation as if you decided to block Google in 1998. For sure, those suckers will not be able to train on your content. But as users rely more and more on AI for recommendations, you will vanish from awareness in much the same way as if you had vanished from Google search results.

You’re welcome to block AI crawlers, and most of them will respect it. But that won’t make AI go away, nor will it make users stop using AI.

If you’re going to be in AI results…

If you’re going to be in AI results anyway, you should want the very best experience for current and potential users.

First, you do want to be recommended. After all, that’s how I sold this to you, right? The new Google. It’s a bit of the Wild West still, but there are tools that you can use to check how you appear in AI results. Here’s an example from ProductRank.ai for Python Podcasts.

Talk Python to Me is the number one recommended podcast when users ask ChatGPT, Claude, or Perplexity for a Python podcast. And my other podcast, Python Bytes, is number three. Honestly, I’m thrilled at this result. If anyone is talking to these AIs and says, “Hey, I would love a podcast to listen to. Do you have recommendations?” Here you go.

What would the experience be if I got mad at AI and blocked it? I simply would be invisible to all of these users wanting to learn about Python podcasts. Whatever effect AI is going to have on Talk Python in the future, disappearing from its recommendations is not going to make it better.

What will make it better?

How can we improve our situation of, say, decreased traffic or fewer customers? And I’m not even saying that that has actually happened for Talk Python, the podcast. It’s still going strong, just speaking generally.

Obviously, getting recommended more is key, so see above. Offering a better experience to your users when they ask questions about topics your content covers or even specifically about your content in particular.

That is why I added the AI integrations to Talk Python. Not so that AI could undermine us even more, but so that our users would get more value from years and years of content we’ve already created. Counting the transcripts, deep dives, and episode pages, we have well over 7 million words of content at talkpython.fm.

If users want to ask AI about that content, I want AI to give them as good and accurate of a response as possible. Here are some super frustrating experiences that you sometimes get from AI.

Outdated data: My training only goes back to the summer of 2025, so here are the most recent results according to that.
Imaginary data: My mistake. You’re absolutely right! President Obama did appear on Talk Python back in 2008! Here’s a link to that interview …

Out of date data, and especially, hallucinated data is why so many people are creeped out by AI and want to use AI less. The AI integrations that I created significantly reduced this by providing real-time information to AI, as well as tools to verify what it thinks exists, actually does, and link back to it.

How it looks with AI integrations

Check out this response from Claude when I asked what the latest 5 episodes of Talk Python To Me are:

This is real-time information. If I publish a new episode, or heck, even change the title of an older one, and ask this question again in a separate chat conversation 10 seconds later I will get up-to-date information.

There are many tools that the AIs can use that we’ve provided so that our content is more accurate, more up-to-date, and more useful. This can only mean that AI will recommend our content more and link back to it more accurately.

Here is another example which I posed in a totally fresh chat: Can you recommend a Python course on agentic AI and cursor?

Notice, I did not ask Claude to recommend a Talk Python course on Agentic AI. I simply asked it for any Python-based Agentic AI and Cursor course. Now, I have installed the Talk Python MCP server, so that probably influenced Claude, but still this is very powerful.

Blocking AI crawlers might be a bad idea

This is exactly why I think blocking AI crawlers is probably a bad idea. Yes, it’ll make you feel great if you’re pissed at AI: “You’ll show them!" But it likely will not further your cause in sharing ideas, gaining awareness, and much more.

So for all of you who have asked me why I’m willing to make Talk Python more accessible to AI in the immediate shadow of Tailwind and Stack Overflow suffering greatly from AI, this is why.

Thanks for checking out my content, whether you got here through an RSS reader, web search, or maybe even an AI recommendation. ;)

Cheers, Michael.

Always activate the venv (a shell script)

michael@mkennedy.tech (Michael Kennedy) — Wed, 07 Jan 2026 10:15:37 -0800

TL;DR: Add this Zsh script to your .zshrc to automatically activate/deactivate venv or .venv as you navigate directories. It includes a whitelist feature for security.

Using a virtual environment is a well-known and important best practice for working on Python projects that use third-party dependencies, i.e. pretty much every Python project out there.

But it’s a hassle to make sure you always have the right one activated, that you have one activated, and checking if there’s even one present. Maybe you haven’t created one for this project yet, yet where you’ve checked it out from source control.

This post shares a simple shell script that will automatically find and activate your Python virtual environment. (* See security warning at the end.)

As you navigate through your source code, it seeks out virtual enviornemnts (named venv or .venv) and turns them on and off as in enter/leave that tree of your file system.

Why not just direnv?

Because direnv + Python seems to be a mess and it’s a sledgehammer when all you need is a thumbtack. Check out the still open issue Activate python venv by default? #1264 in the direnv project to get a sense.

Installing the script

Just save the script below to venv-auto-activate.sh and then add include it in your .zshrc file with source "venv-auto-activate.sh". Note that this only works on ZSH (not Bash) due to the use of the chpwd hook. Luckily ZSH is the default shell on macOS. If you use another shell, maybe this post will inspire you to create something similar.

Here’s the shell script:

# Virtual Environment Auto-Activation
# ===================================
# Automatically activates/deactivates Python virtual environments
# when changing directories

# Please read "A small security warning" on the post before continuing.

# Auto-activate virtual environment for any project with a venv directory
function chpwd() {
    # Function to find venv directory in current path or parent directories
    # Prefers 'venv' over '.venv' if both exist
    local find_venv() {
        local dir="$PWD"
        while [[ "$dir" != "/" ]]; do
            if [[ -d "$dir/venv" && -f "$dir/venv/bin/activate" ]]; then
                echo "$dir/venv"
                return 0
            elif [[ -d "$dir/.venv" && -f "$dir/.venv/bin/activate" ]]; then
                echo "$dir/.venv"
                return 0
            fi
            dir="$(dirname "$dir")"
        done
        return 1
    }
    
    local venv_path
    venv_path=$(find_venv)
    
    if [[ -n "$venv_path" ]]; then
        # Normalize paths for comparison (handles symlinks and path differences)
        # Use zsh :A modifier to resolve paths without triggering chpwd recursively
        local normalized_venv_path="${venv_path:A}"
        local normalized_current_venv=""
        if [[ -n "${VIRTUAL_ENV:-}" ]]; then
            normalized_current_venv="${VIRTUAL_ENV:A}"
        fi
        
        # We found a venv, check if it's already active
        if [[ "$normalized_current_venv" != "$normalized_venv_path" ]]; then
            # Deactivate current venv if different
            if [[ -n "${VIRTUAL_ENV:-}" ]] && type deactivate >/dev/null 2>&1; then
                deactivate
            fi
            # Activate the found venv
            source "$venv_path/bin/activate"
            local project_name=$(basename "$(dirname "$venv_path")")
            echo "🐍 Activated virtual environment \033[95m$project_name\033[0m."
        fi
    else
        # No venv found, deactivate if we have one active
        if [[ -n "${VIRTUAL_ENV:-}" ]] && type deactivate >/dev/null 2>&1; then
            local project_name=$(basename "$(dirname "${VIRTUAL_ENV}")")
            deactivate
            echo "🔒 Deactivated virtual environment \033[95m$project_name\033[0m."
        elif [[ -n "${VIRTUAL_ENV:-}" ]]; then
            # VIRTUAL_ENV is set but deactivate function is not available
            # This can happen when opening a new shell with VIRTUAL_ENV from previous session
            unset VIRTUAL_ENV
        fi
    fi
}

# Run the chpwd function when the shell starts
chpwd

A small security warning

While the script does not do anything shady, it does run code on your behalf. Normally, you’re using the terminal to go in and out of your projects with your virtual environments. In theory, someone could trick you into checking out or opening a directory structure that has a script named venv/bin/activate which runs via this script when you navigate into that tree structure.

If you interact with a lot of projects that you do not control or trust, maybe you want to have this feature as something you can turn on and off with a shell command command. Maybe update the script to give you a confirmation: Are you sure you want to activate SCRIPT_PATH? Something like that. As usual, it’s your call. Use at your own risk.

A security fix

After posting this article, a reader sent in a great idea:

What I did for the security concern was implement a whitelist. If it finds a venv but it’s not in the whitelist it informs me. Then I have a whitelist-venv command that will add that repo to the whitelist. – Scott H.

Amazing idea Scott. I think it balances safety with easy-of-use. I updated the script with a partner Python utlity to validate and manage this whitelist. Check it out at this Github Gist:

Security-aware always activate the venv for Python

Python Numbers Every Programmer Should Know

michael@mkennedy.tech (Michael Kennedy) — Wed, 31 Dec 2025 11:49:00 -0800

There are numbers every Python programmer should know. For example, how fast or slow is it to add an item to a list in Python? What about opening a file? Is that less than a millisecond? Is there something that makes that slower than you might have guessed? If you have a performance sensitive algorithm, which data structure should you use? How much memory does a floating point number use? What about a single character or the empty string? How fast is FastAPI compared to Django?

I wanted to take a moment and write down performance numbers specifically focused on Python developers. Below you will find an extensive table of such values. They are grouped by category. And I provided a couple of graphs for the more significant analysis below the table.

Acknowledgements: Inspired by Latency Numbers Every Programmer Should Know and similar resources.

Source code for the benchmarks

This article is posted without any code. I encourage you to dig into the benchmarks. The code is available on GitHub at:

https://github.com/mikeckennedy/python-numbers-everyone-should-know

📊 System Information

The benchmarks were run on the sytem described in this table. While yours may be faster or slower, the most important thing to consider is relative comparisons.

Property	Value
Python Version	CPython 3.14.2
Hardware	Mac Mini M4 Pro
Platform	macOS Tahoe (26.2)
Processor	ARM
CPU Cores	14 physical / 14 logical
RAM	24 GB
Timestamp	2025-12-30

TL;DR; Python Numbers

This first version is a quick “pyramid” of growing time/size for common Python ops. There is much more detail below.

Python Operation Latency Numbers (the pyramid)

Attribute read (obj.x)                              14   ns
Dict key lookup                                     22   ns              1.5x attr
Function call (empty)                               22   ns
List append                                         29   ns              2x attr
f-string formatting                                 65   ns              3x function
Exception raised + caught                          140   ns             10x attr
orjson.dumps() complex object                      310   ns        0.3 μs
json.loads() simple object                         714   ns        0.7 μs   2x orjson
sum() 1,000 integers                             1,900   ns        1.9 μs   3x json
SQLite SELECT by primary key                     3,600   ns        3.6 μs   5x json
Iterate 1,000-item list                          7,900   ns        7.9 μs   2x SQLite read
Open and close file                              9,100   ns        9.1 μs   2x SQLite read
asyncio run_until_complete (empty)              28,000   ns         28 μs   3x file open
Write 1KB file                                  35,000   ns         35 μs   4x file open
MongoDB find_one() by _id                      121,000   ns        121 μs   3x write 1KB
SQLite INSERT (with commit)                    192,000   ns        192 μs   5x write 1KB
Write 1MB file                                 207,000   ns        207 μs   6x write 1KB
import json                                  2,900,000   ns      2,900 μs   3 ms   15x write 1MB
import asyncio                              17,700,000   ns     17,700 μs  18 ms    6x import json
import fastapi                             104,000,000   ns    104,000 μs 104 ms    6x import asyncio

Python Memory Numbers (the pyramid)

Float                                               24   bytes
Small int (cached -5 to 256)                        28   bytes
Empty string                                        41   bytes
Empty list                                          56   bytes          2x int
Empty dict                                          64   bytes          2x int
Empty set                                          216   bytes          8x int
__slots__ class (5 attrs)                          212   bytes          8x int
Regular class (5 attrs)                            694   bytes         25x int
List of 1,000 ints                              36,856   bytes         36 KB
Dict of 1,000 items                             92,924   bytes         91 KB         
List of 1,000 __slots__ instances              220,856   bytes        216 KB
List of 1,000 regular instances                309,066   bytes        302 KB         1.4x slots list
Empty Python process                        16,000,000   bytes         16 MB

Python numbers you should know (detailed version)

Here is a deeper table comparing many more details.

Category	Operation	Time	Memory
💾 Memory	Empty Python process	—	15.77 MB
	Empty string	—	41 bytes
	100-char string	—	141 bytes
	Small int (-5 to 256)	—	28 bytes
	Large int	—	28 bytes
	Float	—	24 bytes
	Empty list	—	56 bytes
	List with 1,000 ints	—	36.0 KB
	List with 1,000 floats	—	32.1 KB
	Empty dict	—	64 bytes
	Dict with 1,000 items	—	90.7 KB
	Empty set	—	216 bytes
	Set with 1,000 items	—	59.6 KB
	Regular class instance (5 attrs)	—	694 bytes
	`__slots__` class instance (5 attrs)	—	212 bytes
	List of 1,000 regular class instances	—	301.8 KB
	List of 1,000 `__slots__` class instances	—	215.7 KB
	dataclass instance	—	694 bytes
	namedtuple instance	—	228 bytes
⚙️ Basic Ops	Add two integers	19.0 ns (52.7M ops/sec)	—
	Add two floats	18.4 ns (54.4M ops/sec)	—
	String concatenation (small)	39.1 ns (25.6M ops/sec)	—
	f-string formatting	64.9 ns (15.4M ops/sec)	—
	`.format()`	103 ns (9.7M ops/sec)	—
	`%` formatting	89.8 ns (11.1M ops/sec)	—
	List append	28.7 ns (34.8M ops/sec)	—
	List comprehension (1,000 items)	9.45 μs (105.8k ops/sec)	—
	Equivalent for-loop (1,000 items)	11.9 μs (83.9k ops/sec)	—
📦 Collections	Dict lookup by key	21.9 ns (45.7M ops/sec)	—
	Set membership check	19.0 ns (52.7M ops/sec)	—
	List index access	17.6 ns (56.8M ops/sec)	—
	List membership check (1,000 items)	3.85 μs (259.6k ops/sec)	—
	`len()` on list	18.8 ns (53.3M ops/sec)	—
	Iterate 1,000-item list	7.87 μs (127.0k ops/sec)	—
	Iterate 1,000-item dict	8.74 μs (114.5k ops/sec)	—
	`sum()` of 1,000 ints	1.87 μs (534.8k ops/sec)	—
🏷️ Attributes	Read from regular class	14.1 ns (70.9M ops/sec)	—
	Write to regular class	15.7 ns (63.6M ops/sec)	—
	Read from `__slots__` class	14.1 ns (70.7M ops/sec)	—
	Write to `__slots__` class	16.4 ns (60.8M ops/sec)	—
	Read from `@property`	19.0 ns (52.8M ops/sec)	—
	`getattr()`	13.8 ns (72.7M ops/sec)	—
	`hasattr()`	23.8 ns (41.9M ops/sec)	—
📄 JSON	`json.dumps()` (simple)	708 ns (1.4M ops/sec)	—
	`json.loads()` (simple)	714 ns (1.4M ops/sec)	—
	`json.dumps()` (complex)	2.65 μs (376.8k ops/sec)	—
	`json.loads()` (complex)	2.22 μs (449.9k ops/sec)	—
	`orjson.dumps()` (complex)	310 ns (3.2M ops/sec)	—
	`orjson.loads()` (complex)	839 ns (1.2M ops/sec)	—
	`ujson.dumps()` (complex)	1.64 μs (611.2k ops/sec)	—
	`msgspec` encode (complex)	445 ns (2.2M ops/sec)	—
	Pydantic `model_dump_json()`	1.54 μs (647.8k ops/sec)	—
	Pydantic `model_validate_json()`	2.99 μs (334.7k ops/sec)	—
🌐 Web Frameworks	Flask (return JSON)	16.5 μs (60.7k req/sec)	—
	Django (return JSON)	18.1 μs (55.4k req/sec)	—
	FastAPI (return JSON)	8.63 μs (115.9k req/sec)	—
	Starlette (return JSON)	8.01 μs (124.8k req/sec)	—
	Litestar (return JSON)	8.19 μs (122.1k req/sec)	—
📁 File I/O	Open and close file	9.05 μs (110.5k ops/sec)	—
	Read 1KB file	10.0 μs (99.5k ops/sec)	—
	Write 1KB file	35.1 μs (28.5k ops/sec)	—
	Write 1MB file	207 μs (4.8k ops/sec)	—
	`pickle.dumps()`	1.30 μs (769.6k ops/sec)	—
	`pickle.loads()`	1.44 μs (695.2k ops/sec)	—
🗄️ Database	SQLite insert (JSON blob)	192 μs (5.2k ops/sec)	—
	SQLite select by PK	3.57 μs (280.3k ops/sec)	—
	SQLite update one field	5.22 μs (191.7k ops/sec)	—
	diskcache set	23.9 μs (41.8k ops/sec)	—
	diskcache get	4.25 μs (235.5k ops/sec)	—
	MongoDB insert_one	119 μs (8.4k ops/sec)	—
	MongoDB find_one by _id	121 μs (8.2k ops/sec)	—
	MongoDB find_one by nested field	124 μs (8.1k ops/sec)	—
📞 Functions	Empty function call	22.4 ns (44.6M ops/sec)	—
	Function with 5 args	24.0 ns (41.7M ops/sec)	—
	Method call	23.3 ns (42.9M ops/sec)	—
	Lambda call	19.7 ns (50.9M ops/sec)	—
	try/except (no exception)	21.5 ns (46.5M ops/sec)	—
	try/except (exception raised)	139 ns (7.2M ops/sec)	—
	`isinstance()` check	18.3 ns (54.7M ops/sec)	—
⏱️ Async	Create coroutine object	47.0 ns (21.3M ops/sec)	—
	`run_until_complete(empty)`	27.6 μs (36.2k ops/sec)	—
	`asyncio.sleep(0)`	39.4 μs (25.4k ops/sec)	—
	`gather()` 10 coroutines	55.0 μs (18.2k ops/sec)	—
	`create_task()` + await	52.8 μs (18.9k ops/sec)	—
	`async with` (context manager)	29.5 μs (33.9k ops/sec)	—

Memory Costs

Understanding how much memory different Python objects consume.

An empty Python process uses 15.77 MB

Strings

The rule of thumb for ASCII strings is the core string object takes 41 bytes, with each additional character adding 1 byte. Note: Python uses different internal representations based on content—strings with Latin-1 characters use 1 byte/char, those with most Unicode use 2 bytes/char, and strings with emoji or rare characters use 4 bytes/char.

String	Size
Empty string `""`	41 bytes
1-char string `"a"`	42 bytes
100-char string	141 bytes

Numbers

Numbers are surprisingly large in Python. They have to derive from CPython’s PyObject and are subject to reference counting for garabage collection, they exceed our typical mental model many of:

2 bytes = short int
4 bytes = long int
etc.

Type	Size
Small int (-5 to 256, cached)	28 bytes
Large int (1000)	28 bytes
Very large int (10**100)	72 bytes
Float	24 bytes

Collections

Collections are amazing in Python. Dynamically growing lists. Ultra high-perf dictionaries and sets. Here is the empty and “full” overhead of each.

Collection	Empty	1,000 items
List (ints)	56 bytes	36.0 KB
List (floats)	56 bytes	32.1 KB
Dict	64 bytes	90.7 KB
Set	216 bytes	59.6 KB

Classes and Instances

Slots are an interesting addition to Python classes. They remove the entire concept of a __dict__ for tracking fields and other values. Even for a single instance, slots classes are significantly smaller (212 bytes vs 694 bytes for 5 attributes). If you are holding a large number of them in memory for a list or cache, the memory savings of a slots class becomes meaningful - about 30% less memory usage. Luckily for most use-cases, just adding a slots entry saves memory with minimal effort.

Type	Empty	5 attributes
Regular class	344 bytes	694 bytes
`__slots__` class	32 bytes	212 bytes
dataclass	—	694 bytes
`@dataclass(slots=True)`	—	212 bytes
namedtuple	—	228 bytes

Aggregate Memory Usage (1,000 instances):

Type	Total Memory
List of 1,000 regular class instances	301.8 KB
List of 1,000 `__slots__` class instances	215.7 KB

Basic Operations

The cost of fundamental Python operations: Way slower than C/C++/C# but still quite fast. I added a brief comparison to C# to the source repo.

Arithmetic

Operation	Time
Add two integers	19.0 ns (52.7M ops/sec)
Add two floats	18.4 ns (54.4M ops/sec)
Multiply two integers	19.4 ns (51.6M ops/sec)

String Operations

String operations in Python are fast as well. Among template-based formatting styles, f-strings are the fastest. Simple concatenation (+) is faster still for combining a couple strings, but f-strings scale better and are more readable. Even the slowest formatting style is still measured in just nanoseconds.

Operation	Time
Concatenation (`+`)	39.1 ns (25.6M ops/sec)
f-string	64.9 ns (15.4M ops/sec)
`.format()`	103 ns (9.7M ops/sec)
`%` formatting	89.8 ns (11.1M ops/sec)

List Operations

List operations are very fast in Python. Adding a single item usually requires 28ns. Said another way, you can do 35M appends per second. This is unless the list has to expand using something like a doubling algorithm. You can see this in the ops/sec for 1,000 items.

Surprisingly, list comprehensions are 26% faster than the equivalent for loops with append statements.

Operation	Time
`list.append()`	28.7 ns (34.8M ops/sec)
List comprehension (1,000 items)	9.45 μs (105.8k ops/sec)
Equivalent for-loop (1,000 items)	11.9 μs (83.9k ops/sec)

Collection Access and Iteration

How fast can you get data out of Python’s built-in collections? Here is a dramatic example of how much faster the correct data structure is. item in set or item in dict is 200x faster than item in list for just 1,000 items! This difference comes from algorithmic complexity: sets and dicts use O(1) hash lookups, while lists require O(n) linear scans—and this gap grows with collection size.

The graph below is non-linear in the x-axis.

Access by Key/Index

Operation	Time
Dict lookup by key	21.9 ns (45.7M ops/sec)
Set membership (`in`)	19.0 ns (52.7M ops/sec)
List index access	17.6 ns (56.8M ops/sec)
List membership (`in`, 1,000 items)	3.85 μs (259.6k ops/sec)

Length

len() is very fast. Maybe we don’t have to optimize it out of the test condition on a while loop looping 100 times after all.

Collection	`len()` time
List (1,000 items)	18.8 ns (53.3M ops/sec)
Dict (1,000 items)	17.6 ns (56.9M ops/sec)
Set (1,000 items)	18.0 ns (55.5M ops/sec)

Iteration

Operation	Time
Iterate 1,000-item list	7.87 μs (127.0k ops/sec)
Iterate 1,000-item dict (keys)	8.74 μs (114.5k ops/sec)
`sum()` of 1,000 integers	1.87 μs (534.8k ops/sec)

Class and Object Attributes

The cost of reading and writing attributes, and how __slots__ changes things. Slots saves ~30% memory on large collections, with virtually identical attribute access speed.

Attribute Access

Operation	Regular Class	`__slots__` Class
Read attribute	14.1 ns (70.9M ops/sec)	14.1 ns (70.7M ops/sec)
Write attribute	15.7 ns (63.6M ops/sec)	16.4 ns (60.8M ops/sec)

Other Attribute Operations

Operation	Time
Read `@property`	19.0 ns (52.8M ops/sec)
`getattr(obj, 'attr')`	13.8 ns (72.7M ops/sec)
`hasattr(obj, 'attr')`	23.8 ns (41.9M ops/sec)

JSON and Serialization

Comparing standard library JSON with optimized alternatives. orjson handles more data types and is over 8x faster than standard lib json for complex objects. Impressive!

Serialization (dumps)

Library	Simple Object	Complex Object
`json` (stdlib)	708 ns (1.4M ops/sec)	2.65 μs (376.8k ops/sec)
`orjson`	60.9 ns (16.4M ops/sec)	310 ns (3.2M ops/sec)
`ujson`	264 ns (3.8M ops/sec)	1.64 μs (611.2k ops/sec)
`msgspec`	92.3 ns (10.8M ops/sec)	445 ns (2.2M ops/sec)

Deserialization (loads)

Library	Simple Object	Complex Object
`json` (stdlib)	714 ns (1.4M ops/sec)	2.22 μs (449.9k ops/sec)
`orjson`	106 ns (9.4M ops/sec)	839 ns (1.2M ops/sec)
`ujson`	268 ns (3.7M ops/sec)	1.46 μs (682.8k ops/sec)
`msgspec`	101 ns (9.9M ops/sec)	850 ns (1.2M ops/sec)

Pydantic

Operation	Time
`model_dump_json()`	1.54 μs (647.8k ops/sec)
`model_validate_json()`	2.99 μs (334.7k ops/sec)
`model_dump()` (to dict)	1.71 μs (585.2k ops/sec)
`model_validate()` (from dict)	2.30 μs (435.5k ops/sec)

Web Frameworks

Returning a simple JSON response. Benchmarked with wrk against localhost running 4 works in Granian. Each framework returns the same JSON payload from a minimal endpoint. No database access or that sort of thing. This is just how much overhead/perf do we get from each framework itself. The code we write that runs within those view methods is largely the same.

Results

Framework	Requests/sec	Latency (p99)
Flask	16.5 μs (60.7k req/sec)	20.85 ms (48.0 ops/sec)
Django	18.1 μs (55.4k req/sec)	170.3 ms (5.9 ops/sec)
FastAPI	8.63 μs (115.9k req/sec)	1.530 ms (653.6 ops/sec)
Starlette	8.01 μs (124.8k req/sec)	930 μs (1.1k ops/sec)
Litestar	8.19 μs (122.1k req/sec)	1.010 ms (990.1 ops/sec)

File I/O

Reading and writing files of various sizes. Note that the graph is non-linear in y-axis.

Basic Operations

Operation	Time
Open and close (no read)	9.05 μs (110.5k ops/sec)
Read 1KB file	10.0 μs (99.5k ops/sec)
Read 1MB file	33.6 μs (29.8k ops/sec)
Write 1KB file	35.1 μs (28.5k ops/sec)
Write 1MB file	207 μs (4.8k ops/sec)

Pickle vs JSON (Serialization)

For more serialization options including orjson, msgspec, and pydantic, see JSON and Serialization above.

Operation	Time
`pickle.dumps()` (complex obj)	1.30 μs (769.6k ops/sec)
`pickle.loads()` (complex obj)	1.44 μs (695.2k ops/sec)
`json.dumps()` (complex obj)	2.72 μs (367.1k ops/sec)
`json.loads()` (complex obj)	2.35 μs (425.9k ops/sec)

Database and Persistence

Comparing SQLite, diskcache, and MongoDB using the same complex object.

Test Object

user_data = {
    "id": 12345,
    "username": "alice_dev",
    "email": "alice@example.com",
    "profile": {
        "bio": "Software engineer who loves Python",
        "location": "Portland, OR",
        "website": "https://alice.dev",
        "joined": "2020-03-15T08:30:00Z"
    },
    "posts": [
        {"id": 1, "title": "First Post", "tags": ["python", "tutorial"], "views": 1520},
        {"id": 2, "title": "Second Post", "tags": ["rust", "wasm"], "views": 843},
        {"id": 3, "title": "Third Post", "tags": ["python", "async"], "views": 2341},
    ],
    "settings": {
        "theme": "dark",
        "notifications": True,
        "email_frequency": "weekly"
    }
}

SQLite (JSON blob approach)

Operation	Time
Insert one object	192 μs (5.2k ops/sec)
Select by primary key	3.57 μs (280.3k ops/sec)
Update one field	5.22 μs (191.7k ops/sec)
Delete	191 μs (5.2k ops/sec)
Select with `json_extract()`	4.27 μs (234.2k ops/sec)

diskcache

Operation	Time
`cache.set(key, obj)`	23.9 μs (41.8k ops/sec)
`cache.get(key)`	4.25 μs (235.5k ops/sec)
`cache.delete(key)`	51.9 μs (19.3k ops/sec)
Check key exists	1.91 μs (523.2k ops/sec)

MongoDB

Operation	Time
`insert_one()`	119 μs (8.4k ops/sec)
`find_one()` by `_id`	121 μs (8.2k ops/sec)
`find_one()` by nested field	124 μs (8.1k ops/sec)
`update_one()`	115 μs (8.7k ops/sec)
`delete_one()`	30.4 ns (32.9M ops/sec)

Comparison Table

Operation	SQLite	diskcache	MongoDB
Write one object	192 μs (5.2k ops/sec)	23.9 μs (41.8k ops/sec)	119 μs (8.4k ops/sec)
Read by key/id	3.57 μs (280.3k ops/sec)	4.25 μs (235.5k ops/sec)	121 μs (8.2k ops/sec)
Read by nested field	4.27 μs (234.2k ops/sec)	N/A	124 μs (8.1k ops/sec)
Update one field	5.22 μs (191.7k ops/sec)	23.9 μs (41.8k ops/sec)	115 μs (8.7k ops/sec)
Delete	191 μs (5.2k ops/sec)	51.9 μs (19.3k ops/sec)	30.4 ns (32.9M ops/sec)

Note: MongoDB is a victim of network access version in-process access.

Function and Call Overhead

The hidden cost of function calls, exceptions, and async.

Function Calls

Operation	Time
Empty function call	22.4 ns (44.6M ops/sec)
Function with 5 arguments	24.0 ns (41.7M ops/sec)
Method call on object	23.3 ns (42.9M ops/sec)
Lambda call	19.7 ns (50.9M ops/sec)
Built-in function (`len()`)	17.1 ns (58.4M ops/sec)

Exceptions

Operation	Time
`try/except` (no exception raised)	21.5 ns (46.5M ops/sec)
`try/except` (exception raised)	139 ns (7.2M ops/sec)

Type Checking

Operation	Time
`isinstance()`	18.3 ns (54.7M ops/sec)
`type() == type`	21.8 ns (46.0M ops/sec)

Async Overhead

The cost of async machinery.

Coroutine Creation

Operation	Time
Create coroutine object (no await)	47.0 ns (21.3M ops/sec)
Create coroutine (with return value)	45.3 ns (22.1M ops/sec)

Running Coroutines

Operation	Time
`run_until_complete(empty)`	27.6 μs (36.2k ops/sec)
`run_until_complete(return value)`	26.6 μs (37.5k ops/sec)
Run nested await	28.9 μs (34.6k ops/sec)
Run 3 sequential awaits	27.9 μs (35.8k ops/sec)

asyncio.sleep()

Note: asyncio.sleep(0) is a special case in Python’s event loop—it yields control but schedules an immediate callback, making it faster than typical sleeps but not representative of general event loop overhead.

Operation	Time
`asyncio.sleep(0)`	39.4 μs (25.4k ops/sec)
Coroutine with `sleep(0)`	41.8 μs (23.9k ops/sec)

asyncio.gather()

Operation	Time
`gather()` 5 coroutines	49.7 μs (20.1k ops/sec)
`gather()` 10 coroutines	55.0 μs (18.2k ops/sec)
`gather()` 100 coroutines	155 μs (6.5k ops/sec)

Task Creation

Operation	Time
`create_task()` + await	52.8 μs (18.9k ops/sec)
Create 10 tasks + gather	85.5 μs (11.7k ops/sec)

Async Context Managers & Iteration

Operation	Time
`async with` (context manager)	29.5 μs (33.9k ops/sec)
`async for` (5 items)	30.0 μs (33.3k ops/sec)
`async for` (100 items)	36.4 μs (27.5k ops/sec)

Sync vs Async Comparison

Operation	Time
Sync function call	20.3 ns (49.2M ops/sec)
Async equivalent (`run_until_complete`)	28.2 μs (35.5k ops/sec)

Methodology

Benchmarking Approach

All benchmarks run multiple times and with warmup not timed
Timing uses timeit or perf_counter_ns as appropriate
Memory measured with sys.getsizeof() and tracemalloc
Results are median of N runs

Environment

OS: macOS 26.2
Python: 3.14.2 (CPython)
CPU: ARM - 14 cores (14 logical)
RAM: 24.0 GB

Code Repository

All benchmark code available at: https://github.com/mikeckennedy/python-numbers-everyone-should-know

Key Takeaways

Memory overhead: Python objects have significant memory overhead - even an empty list is 56 bytes
Dict/set speed: Dictionary and set lookups are extremely fast (O(1) average case) compared to list membership checks (O(n))
JSON performance: Alternative JSON libraries like orjson and msgspec are 3-8x faster than stdlib json
Async overhead: Creating and awaiting coroutines has measurable overhead - only use async when you need concurrency
__slots__ tradeoff: __slots__ saves memory (~30% for collections of instances) with virtually no performance impact

Last updated: 2026-01-01

DevOps Python Supply Chain Security

michael@mkennedy.tech (Michael Kennedy) — Fri, 26 Dec 2025 15:53:11 -0800

TL;DR: Run pip-audit in an isolated Docker container before installing updated dependencies on your dev machine. Build a reusable pipauditdocker image and alias pip-audit-proj to test requirements.txt in isolation before they touch your local environment.

In my last article, “Python Supply Chain Security Made Easy” I talked about how to automate pip-audit so you don’t accidentally ship malicious Python packages to production. While there was defense in depth with uv’s delayed installs, there wasn’t much safety beyond that for developers themselves on their machines.

This follow up fixes that so even dev machines stay safe.

Defending your dev machine

My recommendation is instead of installing directly into a local virtual environment and then running pip-audit, create a dedicated Docker image meant for testing dependencies with pip-audit in isolation.

Our workflow can go like this.

First, we update your local dependencies file:

uv pip compile requirements.piptools --output-file requirements.txt --exclude-newer 1 week

This will update the requirements.txt file, or tweak the command to update your uv.lock file, but it don’t install anything.

Second, run a command that uses this new requirements file inside of a temporary docker container to install the requirements and run pip-audit on them.

Third, only if that pip-audit test succeeds, install the updated requirements into your local venv.

uv pip install -r requirements.txt

The pip-audit docker image

What do we use for our Docker testing image? There are of course a million ways to do this. Here’s one optimized for building Python packages that deeply leverages uv’s and pip-audit’s caching to make subsequent runs much, much faster.

Create a Dockerfile with this content:

# Image for installing python packages with uv and testing with pip-audit
# Saved as Dockerfile
FROM ubuntu:latest

RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get autoremove -y

RUN apt-get -y install curl

# Dependencies for building Python packages
RUN apt-get install -y gcc 
RUN apt-get install -y build-essential
RUN apt-get install -y clang
RUN apt-get install -y openssl 
RUN apt-get install -y checkinstall 
RUN apt-get install -y libgdbm-dev 
RUN apt-get install -y libc6-dev
RUN apt-get install -y libtool
RUN apt-get install -y zlib1g-dev
RUN apt-get install -y libffi-dev
RUN apt-get install -y libxslt1-dev

ENV PATH=/venv/bin:$PATH
ENV PATH=/root/.cargo/bin:$PATH
ENV PATH=/root/.local/bin/:$PATH
ENV UV_LINK_MODE=copy

# Install uv
RUN curl -LsSf https://astral.sh/uv/install.sh | sh

# set up a virtual env to use for temp dependencies in isolation.
RUN --mount=type=cache,target=/root/.cache uv venv --python 3.14 /venv
# test that uv is working
RUN uv --version 

WORKDIR "/"

# Install pip-audit
RUN --mount=type=cache,target=/root/.cache uv pip install --python /venv/bin/python3 pip-audit

This installs a bunch of Linux libraries used for edge-case builds of Python packages. It takes a moment, but you only need to build the image once. Then you’ll run it again and again. If you want to use a newer version of Python later, change the version in uv venv --python 3.14 /venv. Even then on rebuilds, the apt-get steps are reused from cache.

Next you build with a fixed tag so you can create aliases to run using this image:

# In the same folder as the Dockerfile above.
docker build -t pipauditdocker .

Finally, we need to run the container with a few bells and whistles. Add caching via a volume so subsequent runs are very fast: -v pip-audit-cache:/root/.cache. And map a volume so whatever working directory you are in will find the local requirements.txt: -v \"\$(pwd)/requirements.txt:/workspace/requirements.txt:ro\"

Here is the alias to add to your .bashrc or .zshrc accomplishing this:

alias pip-audit-proj="echo '🐳 Launching isolated test env in Docker...' && \
docker run --rm \
  -v pip-audit-cache:/root/.cache \
  -v \"\$(pwd)/requirements.txt:/workspace/requirements.txt:ro\" \
  pipauditdocker \
  /bin/bash -c \"echo '📦 Installing requirements from /workspace/requirements.txt...' && \
    uv pip install --quiet -r /workspace/requirements.txt && \
    echo '🔍 Running pip-audit security scan...' && \
    /venv/bin/pip-audit \
      --ignore-vuln CVE-2025-53000 \
      --ignore-vuln PYSEC-2023-242 \
      --skip-editable\""

That’s it! Once you reload your shell, all you have to do is type is pip-audit-proj when you’re in the root of your project that contains your requirements.txt file. You should see something like this below. Slow the first time, fast afterwards.

Protecting Docker in production too

Let’s handle one more situation while we are at it. You’re running your Python app IN Docker. Part of the Docker build configures the image and installs your dependencies. We can add a pip-audit check there too:

# Dockerfile for your app (different than validation image above)
# All the steps to copy your app over and configure the image ...

# After creating a venv in /venv and copying your requirements.txt to /app

# Check for any sketchy packages.
# We are using mount rather than a volume because
# we want to cache build time activity, not runtime activity.

RUN --mount=type=cache,target=/root/.cache uv pip install --python /venv/bin/python3 --upgrade pip-audit
RUN --mount=type=cache,target=/root/.cache /venv/bin/pip-audit --ignore-vuln CVE-2025-53000 --ignore-vuln PYSEC-2023-242 --skip-editable

# ENTRYPOINT ... for your app

Conclusion

There you have it. Two birds, one Docker stone for both. Our first Dockerfile built a reusable Docker image named pipauditdocker to run isolated tests against a requirements file. This second one demonstrates how we can make our docker/docker compose build completely fail if there is a bad dependency saving us from letting it slip into production.

Cheers
Michael

Python Supply Chain Security Made Easy

michael@mkennedy.tech (Michael Kennedy) — Mon, 22 Dec 2025 16:16:49 -0800

TL;DR: Wire pip-audit into your CI and unit tests to automatically block known vulnerable dependencies. Add a delay with uv pip compile --exclude-newer "1 week" to avoid installing packages before security issues are discovered. See Part 2 for Docker-based protection.

Maybe you’ve heard that hackers have been trying to take advantage of open source software to inject code into your machine, and worst case scenario, even the consumers of your libraries or your applications machines. In this quick post, I’ll show you how to integrate Python’s “Official” package scanning technology directly into your continuous integration and your project’s unit tests. While pip-audit is maintained in part by Trail of Bits with support from Google, it’s part of the PyPA organization.

Why this matters

Here are 5 recent, high-danger PyPI security issues supply chain attacks where “pip install” can turn into “pip install a backdoor.” Afterwards, we talk about how to scan for and prevent these from making it to your users.

Compromised popular package release (ultralytics), malicious update pushed to PyPI

What happened: A malicious version (8.3.41) of the widely-used ultralytics package was published to PyPI, containing code that downloaded the XMRig coinminer. Follow-on versions also carried the malicious downloader, and the writeup attributes the initial compromise to a GitHub Actions script injection, plus later abuse consistent with a stolen PyPI API token. Source: ReversingLabs

Campaign of fake packages stealing cloud access tokens, 14,100+ downloads before removal

What happened: Researchers reported multiple bogus PyPI libraries (including “time-related utilities”) designed to exfiltrate cloud access tokens, with the campaign exceeding 14,100 downloads before takedown. If those tokens are real, this can turn into cloud account takeover. Source: The Hacker News

Typosquatting and name-confusion targeting `colorama`, with remote control and data theft payloads

What happened: A campaign uploaded lookalike package names to PyPI to catch developers intending to install colorama, with payloads described as enabling persistent remote access/remote control plus harvesting and exfiltration of sensitive data. High danger mainly because colorama is popular and typos happen. Source: Checkmarx

PyPI credential-phishing led to real account compromise and malicious releases of a legit project (`num2words`)

What happened: PyPI reported an email phishing campaign using a lookalike domain; 4 accounts were successfully phished, attacker-generated API tokens were revoked, and malicious releases of num2words were uploaded then removed. This is the “steal maintainer creds, ship malware via trusted package name” playbook. Source: Python Package Index Blog

SilentSync RAT delivered via malicious PyPI packages (`sisaws`, `secmeasure`)

What happened: Zscaler documented malicious packages (including typosquatting) that deliver a Python-based remote access trojan (RAT) with command execution, file exfiltration, screen capture, and browser data theft (credentials, cookies, etc.). Source: Zscaler

Integrating pip-audit

Those are definitely scary situations. I’m sure you’ve heard about typo squatting and how annoying that can be. Caution will save you there. Where caution will not save you is when a legitimate package has its supply chain taken over. A lot of times this could look like a package that you use depends on another package whose maintainer was phished. And now everything that uses that library is carrying that vulnerability forward.

Enter pip-audit.

pip-audit is great because you can just run it on the command line. It will check against PyPA’s official list of vulnerabilities and tell you if anything in your virtual environment or requirements files is known to be malicious.

You could even set up a GitHub Action to do so, and I wouldn’t recommend against that at all. But it’s also valuable to make this check happen on developers’ machines. It’s a simple two-step process to do so:

Add pip-audit to your project’s development dependencies or install it globally with uv tool install pip-audit.
Create a unit test that simply shells out to execute pip-audit and fails the test if an issue is found.

Part one’s easy. Part two takes a little bit more work. That’s okay, because I got it for you. Just download the file here and drop it in your pytest test directory:

test_pypi_security_audit.py

Here’s a small segment to give you a sense of what’s involved.

def test_pip_audit_no_vulnerabilities():
	  # setup ...
    # Run pip-audit with JSON output for easier parsing
    try:
        result = subprocess.run(
            [
                sys.executable,
                '-m',
                'pip_audit',
                '--format=json',
                '--progress-spinner=off',
                '--ignore-vuln',
                'CVE-2025-53000', # example of skipping an irrelevant cve
                '--skip-editable', # don't test your own package in dev
            ],
            cwd=project_root,
            capture_output=True,
            text=True,
            timeout=120,  # 2 minute timeout
        )
    except subprocess.TimeoutExpired:
        pytest.fail('pip-audit command timed out after 120 seconds')
    except FileNotFoundError:
        pytest.fail('pip-audit not installed or not accessible')

That’s it! When anything runs your unit test, whether that’s continuous integration, a git hook, or just a developer testing their code, you’ll also run a pip-audit audit of your project.

Let others find out

Now, pip-audit tests if a malicious package has been installed, In which case, for that poor developer or machine, it may be too late. If it’s CI, who cares? But one other feature you can combine with this that is really nice is uv’s ability to put a delay on upgrading your dependencies.

Many developers, myself included, will typically run some kind of command that will pin your versions. Periodically we also run a command that looks for newer libraries and updates pinned versions so we’re using the latest code. So this way you upgrade in a stair-step manner at the time you’re intending to change versions.

This works great. However, what if the malicious version of a package is released five minutes before before you run this command. You’re getting it installed. But pretty soon, the community is going to find out that something is afoot, report it, and it will be yanked from PyPI. Here bad timing got you hacked.

While it’s not a guaranteed solution, certainly Defense In Depth would tell us maybe wait a few days to install a package. But you don’t want to review packages manually one by one, do you? For example, for Talk Python Training, we have over 200 packages for that website. It would be an immense hassle to verify the dates of each one and manually pick the versions.

No need! We can just add a simple delay to our uv command:

uv pip compile requirements.piptools --upgrade --output-file requirements.txt --exclude-newer "1 week"

In particular, notice –exclude-newer “1 week”. The exact duration isn’t the important thing. It’s about putting a little bit of a delay for issues to be reported into your workflow. You can read about the full feature here. This way, we only incorporate packages that have survived in the public on PyPI for at least one week.

Part 2

Be sure to check out the follow up post DevOps Python Supply Chain Security for even more tips.

Hope this helps. Stay safe out there.

This Course Has Its Own Soundtrack

michael@mkennedy.tech (Michael Kennedy) — Sat, 25 Oct 2025 08:00:31 -0700

Here’s a first: My latest course, Agentic AI Programming for Python Devs, comes with a 5-track soundtrack!

Wondering why a soundtrack?

Why in the world would you create a soundtrack for a course? This course has a few odd quiet, silent sections. Most of it is standard Michael talking style. But when Claude is working hard, sometimes I want you all to just see what it’s doing and I want to get out of the way. This isn’t a lot, but it’s enough that’d rather have something interesting while Claude is working.

So I created a soundtrack!

Then, I started using to also indicate that the AI is working more generally. In the course, when you hear some flow-state/chill music, you know the AI is working.

Here’s an example from the course (small excerpt). Hit play and give it a listen/watch:

It’s great for coding music too

While it’s very fun and different for the course (you should consider taking it ;) ), I also made the full 5-track series available for download even if you’re not interested in the course. It’s really chill and turns out to be good focus music for coding. Have a listen to #2:

#2: Dev Flow, Beat Craft

Download the soundtrack

You can download the all tracks at

talkpython.fm/agentic-ai-soundtrack.zip

Enjoy!

AI Usage TUI

michael@mkennedy.tech (Michael Kennedy) — Fri, 24 Oct 2025 08:51:10 -0700

TL;DR: Track your AI coding credits with AI Usage TUI. See if you’re on pace to run out before your renewal day. Install with uv tool install aiusage and run aiusage to start tracking.

I just published a new open source tool: AI Usage TUI. The picture above tells most of the tail. But in this age of agentic AI coding, you’ll hear many complaints along the lines of:

Wouldn’t it be great if you could just predict easily how fast your credits are vanishing and if you’re going to run out before your credits reset (typically some fixed day of the month)?

On the glass is half full side of things, if you are going to end up with 50% of your credits unspent and not rolling over, maybe tackle a big project or use a smarter (but more expensive credits-wise) model!

That’s why I created ai usage:

AI Usage 💳
A smart command-line tool for tracking AI credit consumption across billing cycles. Designed for AI-powered development tools like Cursor, GitHub Copilot, and other subscription-based AI services.

It’s available on GitHub and PyPI. But I recommend you just install it with uv:

uv tool install aiusage

Run it once with just aiusage on the CLI and it’ll remember your settings (like renewal day) and then you can have it predict your current credit burn-rate.

Read more about it on the README.md for the project.

If you find this useful, please give it a shoutout and cc me on social media: BSky, Mastodon, X

Course: Agentic AI for Python Devs

michael@mkennedy.tech (Michael Kennedy) — Thu, 23 Oct 2025 14:48:52 -0700

I just published a brand new course over at Talk Python: Agentic AI Programming for Python Devs.

This course teaches you how to collaborate with agentic AI tools, not just chatbots or autocomplete, but AI that can understand your entire project, execute commands, run tests, format code, and build complete features autonomously. You’ll learn to guide these tools like you would a talented junior developer on your team, setting up the right guardrails and roadmaps so they consistently deliver well-structured, maintainable code that matches your standards. Think of it as pair programming with an AI partner who learns your preferences, follows your conventions, and gets more effective the better you communicate.

I think you’ll find it immensely valuable. Check it out over at talkpython.fm/agentic-ai

Show me your ls

michael@mkennedy.tech (Michael Kennedy) — Tue, 14 Oct 2025 13:24:59 -0700

TL;DR: Replace your default ls with pls for icons, colors, human-readable sizes, and .gitignore-aware output. Just alias ls="pls --details size" and install a NerdFont.

Getting comfortable in the terminal is one of those coming-of-age moments for developers and data scientists. Whenever I open the default terminal on macOS or Linux, I’m shocked at just how bad it is. There are many tools and alternative terminal apps (OhMyZSH, Warp, Windows Terminal [defunct link: https://apps.microsoft.com/detail/9n0dx20hk701?hl=en-US&gl=US] to name a few).

With this essay, I thought it’d be fun to focus on something as minuscule as the basic ls command (that’s dir for my windows friends).

Let me just set the lower bar for how meh this can be. Here is what you get from a $3,000 MacBook Pro running the latest macOS:

It works, but it sure doesn’t inspire.

Here’s my ls today

Size, human-readable (KB vs. MB, etc.)
Icons (via NerdFonts.com)
Hidden files shown/omitted driven by developer-focused conventions and the .gitignore file
Color coding based on .gitignore and more

This is simply aliasing the great pls library to ls (alias ls="pls --details size") and using the details flag. The bare pls is good too.

Now show me your ls

Share a screenshot and back story with your ls on one of the social posts about this essay.

Primed: Should You Hype Your AI Before You Start?

michael@mkennedy.tech (Michael Kennedy) — Mon, 13 Oct 2025 17:44:50 -0700

I’ve been having some amazing successes with agentic AI and coding lately. A run-down post on these would be interesting. You can find one write-up at Goodbye Wordpress, thanks AI. With this as the backdrop, let me ask you a question.

Should you amp up your AI at the start of a project?

We’ve heard the debates about whether you should be polite and thank your AI. I think yes but never as a separate follow up comment. But should we try to get it HYPED and excited to work on the project?

I just published my first solo book. One of the challenges is that on the buy page there is a simple pair of images/buttons: Buy on Gumroad and Buy on Amazon. Things are rarely as simple as they seem. The Kindle version of the book is available in 12 different locales (US, Canada, Germany, etc.). Each one of these is a different URL based on the location of the web visitor! That means the website should adapt to each visitor and point them at their store if possible. To accomplish this, I combined some magic from GeoIpLite, diskcache, and a text file full of links to various Amazon stores’ listings of my book. Rather than grinding through this, I asked Cursor and Claude Sonnet 4.5 to help make that page dynamic.

I am finding huge success if I have a top-tier model work with me to create a detailed, reviewed plan. Then have the AI work step by step through the plan.

I was excited for the book and wanted my coding buddy to share in my excitement!

And it delivered! “I’m absolutely ready to rock! 🎸”

I’m really enjoying this. I think going forward, each time I kick off one of these detailed, plan-based projects, I am going to hype my AI coding buddy. Even if it doesn’t make a difference, it makes it more fun. :)

BTW, I’m working on an Agentic Coding course at Talk Python. Join the mailing list if that sounds interesting. There will be plenty of excitement there too.

Cheers
Michael

Talk Python in Production book is out!

michael@mkennedy.tech (Michael Kennedy) — Sat, 11 Oct 2025 22:12:52 -0700

I’m thrilled to share that my first solo book is published: Talk Python in Production.

Here’s the deal

Much of the advice we get about running our apps and APIs on the internet is overly complex. Many people and organizations are selling you this complexity. The hyperscale clouds see their lock-in of your app to their 100+ services as a golden ticket. And there are plenty of developers out there who see it as a flex and credibility boost to show how they are using the latest mix of these services regardless of whether they are the best fit.

Leonardo da Vinci knew that “Simplicity is the ultimate sophistication”. No, he never wrote a line of code. He never even vibe-coded an app. His advice still applies to software.

At its core, this book is two things:

A story arc, 10 years in the making, of how I run Talk Python and the associated 20 or so services, APIs, and more today. I started as a total noob, apprehensive of Linux. Today, it’s a testament to how much can be accomplished as a very small team spending 100s of dollars, not $10,000s+.
A detailed, step-by-step guide to transform your set of applications into simpler, lock-in-free infrastructure that is easily understandable and repeatable.

I hope you will join me on this journey.

More than your standard book

I’ve worked really hard to provide you with extra resources that most tech books ignore. Here are some extras that’ll help you get more out of Talk Python in Production:

Code gallery: Contains all the code blocks from the book organized by chapter. Each code block is listed with its language and can be easily copied and used. No need to hunt through the book for code blocks. They are all in one place. This is in the book itself and on GitHub.
Figure gallery: Ditto for images. But it’s even more important here. I’ve published the original max quality images that cannot be put into Kindle devices or would just be hard to see on many EPUB readers. This is in the book itself and on GitHub.
Resources and Links Gallery: Contains all external links and resources referenced in the book. Links are organized by chapter for easy reference. Each link shows the text as it appears in the book along with the full URL. This is in the book itself and on GitHub.
Discussion forum: A dedicated discussion forum where you can discuss ideas with other readers of the book.
Audio Readers’ Briefs: The book includes a total of 1 hour and 20 minutes of short 2 to 4 minute conversations that bookend each chapter. Use them to prime your focus before reading or to broaden your takeaways after. Listen to an example.

How much of this book was written by AI?

Zero percent. This book is written entirely by yours truly over a period of 9 months. Yes, some of the artwork is AI-based. The code and prose is all mine. Don’t we live in wild times that this is even a question some people might ask?

What topics are covered?

Early and evolving architectures: Real-world hosting journeys, from small PaaS approaches to robust multi-VM setups.

One big server strategy: Why consolidating resources on a powerful VM can outperform many small nodes in practice.
Docker & Docker Compose: Practical guides to containerizing Python apps, building images efficiently, and automating deployments.
NGINX & Let’s Encrypt: Reverse proxy basics, SSL/TLS certificates, and best practices for production traffic and security.
Self-hosted services: Tools like Umami (analytics) and Uptime Kuma (monitoring) that you can run yourself instead of paying for cloud solutions.
Performance optimization: Setting up caching, using modern Python app servers, integrating a CDN, etc.
Migrations & frameworks: Real-life examples of moving between frameworks (Pyramid to Quart) and cloud providers (PythonAnywhere to DigitalOcean and Hetzner).
Stack-native philosophy: How to keep your infrastructure streamlined yet powerful and avoid the complexity of deeply “cloud-native” approaches.

Early reviews

I’m getting just a few early reviews and they are looking good:

⭐⭐⭐⭐⭐ 3 ratings on Gumroad (5-stars)

And a few folks have shared their feedback.

“I finished reading the book. I really enjoyed it. The massive hyperscale Kubernetes clusters everyone pushes today never made sense to me from a cost and complexity standpoint for the vast majority of cases.” – Paul

“This is a great book. I have used Python for 20 years. The book follows much of what I would do in my own judgment, and taught me some new tricks too.” – Chris

Give it a try

The book comes with a 30-day refund policy if you get it on Gumroad. You can easily give it a try for “no risk.” I hope you enjoy the book. And if you do get it, please send me a review to feature or share how it’s changed how you and your team run software (hopefully for the better!).

Regardless, thanks for the interest and supporting my work. Cheers.

Goodbye Wordpress, thanks AI

michael@mkennedy.tech (Michael Kennedy) — Tue, 30 Sep 2025 16:55:13 -0700

TL;DR: Used Cursor + Claude Sonnet 4 to migrate 164 Wordpress articles to Hugo in 2 hours. AI handled downloading, converting to markdown, relinking images, and building NGINX redirects. Finally deleted my old Wordpress site and stopped paying $48/yr.

To all the naysayers who think AI coding is just a bunch of slop and we’re better off just avoiding it, I want to share a story of massive success with agentic coding. This is just one of five examples of similar scale I had in one month.

I’ve been blogging and writing online for just shy of 20 years, incredible. Yes, it’s been on again / off again with gaps here and there. But over the years, I’ve written 199 separate articles. 164 of them were on my older blog hosted under my personal domain on wordpress.com.

I’m a fan of picking whatever tech gets you writing and in the early days that was Wordpress. I know many of us choose a tech that is in a language / framework we work in. But I get plenty of Python coding over at talkpython.fm.

In 2022, I wanted something simpler than Wordpress and Markdown-based so I switched to Hugo hosted right here at mkennedy.codes. Hugo is amazing and it’s been great. But then came the $48/yr renewal once again from Wordpress.com. It’s not a lot of money but am I seriously going to be held hostage for the rest of my life? Maybe. I don’t want those older articles to vanish. But the thought of migrating to Hugo and markdown, including all the linked files and more, was just too much to justify the time and energy. So I’ve been renewing my custom domain fee again and again.

Then I had the thought, “I bet Cursor can migrate the site.” I was sitting around one of the fleeting summer nights recently and thought why not let Cursor and Claude’s Sonnet-4 have a go at it.

I gave it a very clear plan on getting the content from my old domain, migrating the content to markdown in Hugo, and copying and relinking all the binary files and images.

It took us 2 hours to get everything downloaded, rewritten, and converted. But then I had ALL of my content that I had previously seen has trapped completely convert to my current Hugo site! It didn’t happen all at once, but with a bit of iteration, we got it just right.

I even used a separate URL structure for the archived posts: /posts/r/... rather than just /posts/... so it’s immediately clear which are the older posts (at least to me).

The last step was to make sure all the old URLs in other sites and search engines still exactly and safely found their way to the new ones. After all, one of my goals is to concentrate the SEO / GenAI-O into one place rather than two domains.

Enter AI again, I asked Claude how to redirect and capture the URLs of the form:

blog.michaelckennedy.net/YYYY/MM/DD/slug

The new format would be:

mkenendy.codes/r/slug

I’m pretty good with NGINX but the comprehensive regex to converted these was more than I wanted to write. So I asked AI how to redirect old URLs to new in NGINX. It has the perfect answer:

# Handle blog post redirects
# Pattern: /YYYY/MM/DD/post-slug/ -> /posts/r/post-slug/
location ~ "^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.+?)/?$" {
    return 301 https://mkennedy.codes/posts/r/$4/;
}

For example, give this old Wordpress URL a click:

https://mkennedy.codes/posts/r/a-bunch-of-online-python-courses/

And you’ll land via a SEO-friendly 301 at:

https://mkennedy.codes/posts/r/a-bunch-of-online-python-courses/

Perfect!

Here’s the takeaway: I had this hassle of a split site, most of my articles trapped in the old domain at Wordpress and 3 years of newer ones on Hugo at my current site. I kept getting charged $48/yr just to keep my old links working.

Enter agentic AI: After two fun hours of coding along with Claude Sonnet 4, I had everything unified and brought over to the newer, lighter style and I had my content living again in my new site.

The best part? I just hit delete on my old Wordpress site:

Thanks Claude!

Roosevelt's Man in the Arena, But for Developers

michael@mkennedy.tech (Michael Kennedy) — Mon, 19 May 2025 14:40:56 -0700

If you enjoy quotes and you’re into software development, I think you’ll get a kick out this. I’m a big fan of Theodore Roosevelt’s Man in the Arena speech / quote. What if he was talking about software development and the challenges and persistence required to succeed there?

The OG: Theodore Roosevelt’s Man in the Arena:

Original quote (very slighly modernized):

It is not the critic who counts; not the man who points out how the strong man or woman stumbles, or where the doer of deeds could have done them better. The credit belongs to the those actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends themself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if they fail, at least fails while daring greatly, so that their place shall never be with those cold and timid souls who neither know victory nor defeat.

Now, For Software Developers ;)

Here are three variants. Pick your favorite.

Legacy Code Warriors

It is not the keyboard-warrior of comment threads who elevates the craft, but the engineer whose IDE still glows at midnight, whose mind is seared by stack-trace hieroglyphs, and whose resolve endures failed build after failed build. The honor rests with those who wade into legacy code knee-deep in technical debt, emerging grimy but triumphant with a cleaner architecture. Or, if defeated, bearing the proud scars of having fought for elegance.

The Refactorer

History will not inscribe the names of those who idly mock version bumps from the safety of evergreen branches; it will memorialize the maintainer who shepherds migrating APIs across chasms of breaking changes, committing line by weary line while alarms of regression clang in their ears. Should the migration succeed, they savor a quiet victory; should it falter, they rest in the knowledge that progress is purchased with audacity, not armchair critique.

Open source maintainers

No glory clings to the spectator who counts another’s failed builds; it crowns the open-source contributor whose pull request is battle-scarred by review, whose changelog tells of failures endured, and whose merged code becomes the unseen engine of tomorrow’s discoveries.

Sunsetting Search?

michael@mkennedy.tech (Michael Kennedy) — Wed, 26 Mar 2025 16:52:39 -0700

Have you noticed a change in your search engine use? I definitely have and it’s a strong downward trend.

Last year I saw a stat that said the average person does fewer than 300 searches per month. I thought that was insanely low for my search usage and probably was very low for most developers and other tech people.

I just checked for myself and in March 2025 across all of my devices (computers and mobile), it is 211.

Just 211! Unbelievable. Were did all the searches go? I can only speculate for most people and be concrete for myself. They went into Chat. I don’t think I rely too heavily on AI, neither for coding or information in general. But it really struck me recently how much AI has changed the game. You can also clearly see this in StackOverflow language trends.

This matters for me personally because it’s an interesting pattern change. It matters for my business because discovery via search is an important flow of customers and users.

Three years ago I posed the question “Paying for search, am I crazy?” The answer, for me at least, was definitely not. It was worth it. Today I’m not so sure. I’m trying out a privacy-focused search engine from the Netherlands called Startpage. It’s not Kagi level of good, but my most important searchs don’t seem to go into either anymore.

We do live in interesting times, don’t we?

Share your thoughts? Discuss this article on Mastodon, BlueSky, or LinkedIn.

Michael's Top Trends of 2024 for Python Web Devs

michael@mkennedy.tech (Michael Kennedy) — Sat, 21 Dec 2024 08:54:32 -0800

I wrote an in-depth article covering my top trends for 2024 based on the PSF Developer Survey data. Here are the top trends in a list, but you should definitely check out the full article for the pictures and the analysis.

Top Trends for Python Web Devs

Share your number one trend on the Mastodon and BSky announcements.

Talk Python migrated to Quart web framework

michael@mkennedy.tech (Michael Kennedy) — Tue, 19 Nov 2024 10:04:03 -0800

Over at Talk Python, I just finished converting our existing web app from Pyramid to Quart and from synchronous to asynchronous web code. And I did a big write up in case it helps anyone on similar journeys:

From the Talk Python blog:

The code powering talkpython.fm is highly modern and leverages many new Python concepts. It makes extensive use of Pydantic with its entire data access layer powered the Beanie ODM. It has type hints at all the architectural boundaries (e.g. data access layer public functions). But we haven’t been able to fully take advantage of these benefits because our web framework has become frozen in time…

Give the full article a read.

Blue Skies ahead (follow me there)

michael@mkennedy.tech (Michael Kennedy) — Sat, 16 Nov 2024 09:58:15 -0800

I’ve found some Blue Skies! With a bunch of my favorite tech people moving over to Bluesky, it’s time to set up shop over there. So if you’re on (or want to join) bsky.app, consider giving me and the podcasts a follow:

Michael on bsky.app -> @mkennedy.codes
Talk Python on bsky.app -> @talkpython.fm
Python Bytes on bsky.app -> @pythonbytes.fm

And if you’re looking for some folks in the Python space to connect with, I’ve created a starter pack which let’s you follow a bunch of us all in one click (or pick from the list):

Introducing chameleon-flask package

michael@mkennedy.tech (Michael Kennedy) — Sat, 09 Nov 2024 08:17:10 -0800

TL;DR: I created chameleon-flask, a package that adds Chameleon template support to Flask. Use @chameleon_flask.template('page.pt') as a decorator and return a dict to render templates. Works with both sync and async views.

I’m a big fan of the Chameleon templating language for Python web apps. For a long time it was the default HTML flavor for Pyramid. But I’m kicking offer new project based on Flask. Flask has really seen a resurgence lately so it seems like the perfect choice for what I’m working on.

One drawback, Flask only supports Jinja2. Jinja is fine, like most templating languages, it is full of Python syntax and begin/end blocks. It’s less pure web compared to Chameleon.

So I fixed it

I created a new open source package for making Chameleon feel very native in Flask:

@app.get('/async')
@chameleon_flask.template('async.pt')
async def async_world():
    await asyncio.sleep(.01)
    return {'message': "Let's go async Chameleon!"}

Notice the second decorator: @chameleon_flask.template('async.pt'). That’s the magic. Return a dictionary and it’ll render the Chameleon template at /templates/async.pt.

If you want to use Chameleon in Flask, check out chameleon-flask on GitHub. And if you’re using FastAPI, I created a sister project called fastapi-chameleon.

Two caveats

First, why didn’t I just use a few of the existing Flask + Chameleon libraries? They seem like they’d work. But they were either very minimal or didn’t support both sync and async view methods.

Secondly, many Flask extensions assume they are working with Jinja as their template system. So this may or may not work with certain extensions. I generally don’t use extensions so it’s fine for me. Just figure out if this is fine for you.

Talk Python has moved to Hetzner

michael@mkennedy.tech (Michael Kennedy) — Wed, 06 Nov 2024 20:47:43 -0800

From the Talk Python blog:

After almost 10 years at Digital Ocean, we’ve moved our entire infrastructure to Hetzner’s US-based data center in Virginia.

This is a big change. We have over 20 different web apps, APIs, background daemons, and databases all working loosely together. Plus I have 10 years of experience running infrastructure in Digital Ocean’s cloud.

Give the full article a read. There are some graphs and other comparisons plus why we made the move.

Opposite of Cloud Native is?

michael@mkennedy.tech (Michael Kennedy) — Tue, 05 Nov 2024 13:47:36 -0800

TL;DR: The opposite of cloud-native isn’t “lift-and-shift” or building your own data center. It’s stack-native: building your app with just enough full-stack building blocks to run reliably with minimal complexity. We run 28 apps serving 9M requests/month on one $65/mo Hetzner server. Same setup in AWS? $1,226/mo.

There seems to be a lot of contention lately about whether you should go all-in on the cloud or to keep things as simple as possible. Those on the side of “build for the cloud” often frame this as cloud-native. By that, I believe they mean you should look at every single service offered by your cloud provider when architecting your application and generally the more services you pull together the better. See Microsoft’s and Google’s definitions for cloud native.

“What is the opposite of cloud-native?”

In this essay, I’ll define a new term for the modern opposite of cloud-native. I think you’ll find it appealing.

Those on the cloud side look back at the dark days of running physical servers with monolithic applications directly on hardware at your location with valid skepticism. These apps were often little more than just a single application and a huge local database. Maybe they were even client-server desktop apps (gasp!).

If you’re not up on all the cloud services and managed this or that, you’re not cloud-native. You’d probably do what they call “lifting-and-shifting” your app to cloud. Did you have one huge server in the office? Well, now you get one huge server in AWS EC2 and copy your app to it. You’ll also pay extreme prices for that privilege. You’re really not with the times, are you?

This particular view of a mostly bygone time is not the opposite of cloud-native. The fallacy here is comparing two modes of running applications disjoined across time. Cloud-native is one view of how to build apps in 2024. This lift-and-shift style is a view of how to run your own apps in 2001. It’s not constructive to debate them as peers.

I recently watched a livestream about moving out of AWS. So many people participated in the conversation were contrasting two worlds: Cloud vs. On-prem. Either you run in AWS/Azure or you build a data center, you string ethernet cables, you buy a backup generator, you hire a couple of engineers to keep these running when hard drives fail.

What? No. This is not the alternative.

The livestream conversation was about a company moving into another managed data center. That data center came with generators. It already has ethernet. The tradeoff is not cloud or build your own data center in 2024. Please do not let people drag you into these false dichotomies.

You should be wary of these merchants of complexity. These hyperscale cloud providers want you to buy in fully to all their services. The amount of lock-in this provides is tremendous. Once your bill leaps far beyond what you expected, it’s tough to change course.

The opposite of cloud-native is stack-native

Consider that insane diagram at the top of this essay. You have a little tiny bit in the center labeled Flask. It is surrounded by every cloud-native service you might want. One portion of our app might need to scale a bit so lambda/serverless functions. We broke our single Flask-based API into 100 serverless endpoints, so we now need something to manage their deployment. What about logs and monitoring? Across all these services? We need a few log services for that. And we may need to scale the Flask portion so Kubernetes! And on it goes.

I present to you an alternative philosophy: stack-native.

“Stack-native is building your app with just enough full-stack building blocks to make it run reliably with minimal complexity.”

This is what it looks like when displayed at the same scale as our cloud-native diagram:

It’s a breath of fresh air, isn’t it? But let’s zoom in so you can actually see it!

What do we have in this stack-native diagram?

We have Flask at the center still.
Flask might be managed by Docker and potentially scaled via web workers. It could be run directly on the VM if that makes sense.
Those workers are running in a WSGI Python server, in this case Granian
The web app is exposed to the internet via nginx
The self-hosted database can live here too (Postgres or MongoDB)
We have a server mapped volume for all our database data, container images, and more.

That’s it. And everything in that picture is free and open source other than the cloud VM. It’s running on a single medium-sized server in a modern and affordable cloud host (e.g. Digital Ocean or Hetzner).

Is this lifted-and-shifted? I don’t think so. It’s closer to Kubernetes than to old-timey client-server on-prem actually.

Would you have to buy a generator? Run ethernet? Fix hardware? Of course not, it runs in a state-of-the-art data center with global reach. It’s just not cloud-native. It’s stack-native and that is a good thing.

Is stack-native for toy apps?

No. We have a very similar setup powering Talk Python, the courses, the mobile APIs, and much much more. Across all our apps and services we receive about 9M Python / database backed requests per month (no caching because it’s not needed). And we handle about 10TB of traffic with 1TB straight out of Python.

Here’s the crazy part. All of our infrastructure is running on one medium-sized server in a US-based data center from Hetzner. We have a single 8 CPU / 16 GB RAM server that we partition up across 28 apps and databases using docker. Most of these apps are as simple or simpler than the stack-native diagram above. For this entire setup, including bandwidth, we pay $65/month. That’s $25/mo for the server and another $40 for bandwidth.

I just finished doing some tentative load testing using the amazing Locust.io framework. At its peak, this setup running Nginx + Granian + Python + Pyramid + MongoDB would handle over 100M Python requests / month. For $25.

In contrast, what would this setup cost in AWS? Well, the server is about $205 / month. The bandwidth out of that server is another $100/mo. If we put all our bandwidth through AWS (for example mp3s and videos through S3) the price jumps up by another whopping $921. This brings the total to $1,226/mo.

The contrast is stark. If we chose cloud-native, we’d be tied into cloud-front, EKS, S3, EC2, etc. That’s the way you use the cloud, you noobie. Let’ the company cover the monthly costs.

But stack-native can move. We can run it in Digital Ocean for a few years as we did. When a company like Hetzner opens a data center in the US with 1/6th pricing, we can take our setup and move. The hardest part of this is Let’s Encrypt and DNS. There is nearly zero lock-in.

The final take away

It may sound like I’m telling you to never use Kubernetes. Never use PaaS and so on. That’s not quite it though. You can definitely choose PaaS. Rather than using the cloud provider’s PaaS, maybe host your own version of Coolify? You want to run serverless? Maybe Knative works. Whatever you pick, just be very cognizant of the lock-in and ultimate price in terms of flexibility in the future. Try to fit it into a single box, even if that box is a pretty big VM in the cloud.

Get the whole Python in production series

I plan on writing a whole series on this topic focused on this topic. Please consider subscribing to the RSS feed here or joining the mailing list at Talk Python.

What do you think?

If this article made you think or you just want to share your thoughts, here are a few places with comments you could jump (no comments directly on my blog):

X.com - x.com/mkennedy/status/1853918500349501671
Mastodon - fosstodon.org/@mkennedy/113432568775276850

Search Talk Python from your address bar

michael@mkennedy.tech (Michael Kennedy) — Wed, 16 Oct 2024 08:57:07 -0700

TL;DR: Add Talk Python and Python Bytes as custom search engines in your browser. Use shortcuts like “tp” to search 9 years of episodes and transcripts directly from your address bar. Setup instructions at search.talkpython.fm/api/browser.

I’ve put a ton of effort into Talk Python and Python Bytes to make our content discoverable and open. Our RSS feeds have all 9 years of episodes to download and listen to. However, given that much content, it’s often hard to know what’s out there.

That’s why our search includes not just the show notes and links on the pages, but full text search of all the high-quality transcripts as well. You can search every spoken word from the podcasts. This feature has been out for quite awhile.

I just added an API for Open Search Description to both Talk Python and Python Bytes. That means you can now add the podcasts as search providers in your browser. As you can see, just assign a shortcut (like tp) and you get both direct search and search suggestions:

Add it to your browser

Every browser is a bit different in the steps and capabilities. To add yours, just visit the browser setup page to enter the details (it takes less than a minute to do) and have the podcasts’ immense back catalog of information always at your fingertips.

Browser setup instructions for Talk Python and for Python Bytes.

We Must Replace uWSGI With Something Else

michael@mkennedy.tech (Michael Kennedy) — Thu, 03 Oct 2024 12:12:37 -0700

TL;DR: uWSGI is now in maintenance-only mode. Replace it with Granian (recommended), uvicorn, hypercorn, or gunicorn with uvicorn workers. All support ASGI for async Python web apps.

If you’ve been using uWSGI as your Python web server, you’ll be interested in this prominent message at the top of the uWSGI project:

“Note: The project is in maintenance mode (only bug fixes and updates for new languages apis). Do not expect quick answers on GitHub issues and/or pull requests (sorry for that) A big thanks to all of the users and contributors since 2009.”

I stumbled across this when poking around GitHub in the Granian project. In there was a reference from OpenEdX with an issue entitled “We Must Replace Uwsgi With Something Else”. Having been an avid user of uWSGI, this caught my attention. Hence the note just above.

Replace it, but with what?

I think there are some excellent modern options to replace uWSGI. The good news is that it’s super fast and easy to do. Basically, change the start up command and the server you install (via uv pip install ...) and you’re off to the races. After all, isn’t that the promise of WSGI and ASGI?

In this context, by “modern”, I mean two things: 1) It is actively supported and 2) it supports ASGI for async-based Python web apps (e.g. FastAPI).

To me, reasonable options include:
- Granian (what we’re using across the board at Talk Python)
- uvicorn (now an option as a stand-alone production server)
- hypercorn
- gunicorn (potentially with uvicorn workers for async, pronounced “Gee Unicorn”)

And thanks

Thanks to the whole uWSGI team and contributors for 15 years of a great web server. It was a good run.

Let's go easy on PyPI, OK?

michael@mkennedy.tech (Michael Kennedy) — Sat, 28 Sep 2024 10:04:38 -0700

[Post updated Sept 30, 2024 based on lots of community conversations.]

TL;DR: Stop reinstalling all Python packages on every Docker build. Copy and install requirements.txt before your source code, and pre-install core dependencies in an unchanging layer. Docker’s layer caching will reduce your PyPI calls by 100x.

What do you think of when you visualize the Python Package Index and someone using it? A developer or data scientist building something new and creative? That’s cute (and yes of course it’s amazing and it does happen).

Closer to reality

For every individual periodically installing packages with pip and friends, there are literally 1,000s or hundreds of thousands of automated systems building Docker images (or containers for Kubernetes or other infrastructure).

Maybe it should look more like this in your mind, an absolute hive of traffic and busy-ness and few humans in the loop at all:

This is because containers are supposed to be isolated. So of course they have to download flask-sqlalchemy 100 times day, right?

Or do they?

Containers also support caching and layering. That is, each line of the file that creates a container is a separate instruction that adds on the ones that came before. And if nothing the came before has changed, then why run it again?

We can use this layering to make things much easier and cheaper for Python and PyPI.

Did you know that PyPI had a total of 284+ billion downloads for the half million projects in 2023? That’s $50k - $100k of traffic per month. Yikes.

What if we could get faster Docker builds and dramatically limit the demand on PyPI? I’ll show you a technique that we use at Talk Python (I’m sure there are variations).

Towards a gentler Dockerfile

Consider this Docker image file (don’t worry if you don’t know Docker, I’ll explain and what you need to know is simple). This is the most abusive one, yet it’s the straightforward and common one as well:

FROM ubuntu:latest

# Set up the path for our tooling
ENV PATH=/venv/bin:$PATH
ENV PATH=/root/.cargo/bin:$PATH

# Install uv (because it's caching is awesome)
RUN curl -LsSf https://astral.sh/uv/install.sh | sh

# Create a venv with Pyton 3.12.6, installing Python along the way
RUN uv venv --python 3.12.6 /venv

# Copy the full source code to be run
COPY src/yourapp /app

# Install the requirements via uv & requirements.txt
RUN uv pip install -r requirements.txt

# Run your app in a web server via the entry point
ENTRYPOINT [  \
    "/venv/bin/..." \
    ]

First, for you all uninitiated in Docker, the steps are:

Base a container on Ubuntu
Set up some path to keep the tooling simple later
Use uv over basic pip and install Python and create a venv with it
Copy your source code from a local src folder into /app
Install the requirements (via uv) into your venv
Run the app via some web server or something on the entry point

Note: If you’re wondering what’s up with all this uv stuff, I wrote about it a week or two ago.

Why is this abusive?

If any source file whatsoever changes, that will trigger the lines below

# Copy the full source code to be run

to run and hence invalidating all of Docker’s caching and will reinstall all of the requirements.

Over at Talk Python Training, our web app has 205 packages in use (not top-level, but with the transitive closure of them). 205! That is massive load on pypi.org. Massive. And yet, most of the time, no packages changed. This is especially true if you pin your dependencies as we do with uv pip compile. But we would still reinstall all of them, pulling fresh copies from PyPI through Fastly every time with this docker setup.

That is down right abusive and wasteful.

A simple change for the better

One very minor change (but not final) that we can do is to just copy the requirements.txt file and install them first, then overwrite that with the full app.

See the NEW section:

# ...

# NEW: Copy just the requirements.txt and install them
COPY src/yourapp/requirements.txt /app
RUN uv pip install -r requirements.txt

# Copy the full app to be run
COPY src/yourapp /app

# ...

Seems silly, right? If we are going to copy all the files anyway, why copy just the requirements.txt one first?

Because of Docker’s cached layers.

This change means you only install the requirements if the requirements.txt file itself has changed (or lines before it such as a new ubuntu image).

Way better! Now, most source changes don’t pull a new copy of requirements from PyPI and the container builds faster: win-win.

But…

If any requirement changes, we pull all of them by rerunning uv pip install -r requirements.txt Ugh. It’s better, but not great.

One more layer

Let’s add one more change. Suppose your app is built on Flask and uses Beanie for an ODM against MongoDB. So your core requirements are flask, beanie, and that’s it. And let’s imagine your web server is gunicorn to boot.

We can add this new-new section:

# ...

# NEW-NEW: Install the latest of all main dependencies.
# Do NOT pin these versions, we want the latest here
RUN uv pip install flask beanie gunicorn

# Copy just the requirements.txt and install them
COPY src/yourapp/requirements.txt /app
RUN uv pip install -r requirements.txt

# Copy the full app to be run
COPY src/yourapp /app

# ...

That new line makes all the difference:

uv pip install flask beanie gunicorn

This layer will never change, never. Yet, it’ll pull every dependency if you put your top-level ones in that line. But you may be thinking:

Great, however it’ll get out of sync over time…

Yes, but think 205 dependencies, not 3: At first build time, your container (well uv) will see that you already have all the dependencies when you run

uv pip install -r requirements.txt

It won’t hit PyPI again on subsequent builds and it’ll run lightening fast because of uv caching and Docker’s caching on top of that.

Over time, they will drift. Maybe a new version of pydantic ships and it’ll get changed when the requirements.txt line is run. The older, cached one will get uninstalled when you install the pinned requirements.txt (or pyproject.toml, or whatever).

Fine. But this only pulls the new pydantic from PyPI, not all 205 of the dependencies!

My experience is most packages stay static for months if not years and only a few change frequently. So why are we pulling all 205 from PyPI every time something minor changes. We shouldn’t be, right?

Eventually there will be something to trigger a full rebuild (such as a new ubuntu image ships). Then everything will updated, get resynced and realigned.

And the cycle continues.

And potentially some help from Docker

[This section added after lots of great feedback from readers.]

So far, we have cached our packages in the uv cache inside the container. This layering from Docker is great and will reuse that cache most of the time as mentioned above. However, for full rebuilts, we will pull full copies of everything again. This is the case if we ask for a full rebuild but also if we have the base image or lines prior to ours change.

Docker will optionally use a host-OS folder for a subsection of the docker image file system during build with the mount option. We can leverage this to permanently locate and use the uv cache on the host OS so even full rebuilds mostly use the local cache. Notice the addtion of --mount=type=cache,target=/root/.cache:

# ...

# Copy just the requirements.txt and install them
COPY src/yourapp/requirements.txt /app
RUN --mount=type=cache,target=/root/.cache uv pip install -r requirements.txt

# Copy the full app to be run
COPY src/yourapp /app

# ...

This will create a local cached folder managed by Docker that maps /root/.cache inside the container for build time that redirects uv’s cache (/root/.cache/uv) as well as pip’s cache (/root/.cache/pip) to a local persistant host folder.

In this setup, you can skip the ahead-of-time RUN uv pip install flask beanie gunicorn section because after the first run it’ll be cached to the OS. That’s a big plus.

However, now the host OS will be the source of caching for pip/uv with this setup. The packages will not be cached in the docker image. So if you ship the container to other locations that build upon it, then they’ll be starting from scratch. This would be the case if someone is docker pull-ing your image as their base image. So consider the use-case for --mount.

And for CI on GitHub

One the largest consumers of pypi.org traffic has to be CI. And among them, GitHub is probably the biggest. This is pretty resistant to any of the caching help we’ve discussed so far. Luckily GitHub actions have a cache option just for this. Here’s the pip example from GitHub. Use the directory /root/.cache/uv for uv if you’re using uv instead.

The take-away

Adding just small and simple sections to your Dockerfile could reduce your load on PyPI by over 100x (for real, no hyperbole here).

First, we pre-cache and install all of the core dependencies of our app like this:

# Install all of the main dependencies
# Do NOT pin these versions, we want the latest here
RUN uv pip install flask beanie gunicorn

Second, we only update these if the requirements.txt file (or pyproject.toml, or whatever) changes:

# Copy just the requirements.txt and install them
COPY src/yourapp/requirements.txt /app
RUN uv pip install -r requirements.txt

It’ll make your containers build way way faster once it’s cached and it’ll take a massive load off of PyPI and do the PSF and the whole Python community a favor making PyPI much cheaper to operate for all of us.

You can find a working example in a previous post, Docker images using uv’s python. That one covered some of these ideas but focused on making Docker builds fast for Python apps, rather than the focus of this essay which is all about being kind to the PSF and PyPI.

Passkeys are great, careful of the lock-in

michael@mkennedy.tech (Michael Kennedy) — Tue, 24 Sep 2024 19:43:42 -0700

TL;DR: Passkeys are great for security, but Apple/Google/Microsoft want to lock you in by syncing them only within their ecosystems. Use a third-party password manager like 1Password or Bitwarden to store passkeys instead and keep your freedom.

People suck at passwords, just look at haveibeenpwned. Yet, they have been with us for a very long time and still today serve a very important purpose.

Just look at the truly misguided attempts to replace them with “magic link” logins. You know the ones. Enter your email address, then they email you a code or link every time you want to log in. Please, never do this, it’s incredibly user hostile even if it makes your app “safer” (?). It’ll make you yearn for passwords again.

Passkeys are the answer?

Along came passkeys. A cool idea that quickly turned evil.

How do cryptographic blobs that can’t be faked or brute forced become evil? When tech giants leverage a good idea to further lock you into their platforms. Just do a quick FaceID and you’re in – as long as you’re on your Apple device. Or that handy Windows Hello that keeps your passkeys synced – across your Windows machines.

So I’ve been against them pretty much from the start when I saw them going this way.

Password managers (third-party!) to the rescue

However, the tides are turning back to open and to choice, and that’s awesome. Many of the solid password managers are now supporting passkeys [1, 2]. This means you get your no hassle, cryptographic login (often without 2FA or device login SMSes), but you skip the lock-in.

I’m a 1Password user and I found that 36 of my logins supported Passkeys (check here). Just visit WatchTower and click on Passkeys. After a few hours, I had them all created and registered so no more accounts need attention:

Give it a try

So give it a try. And if you’re not using a password manager, stop right now and go get one (I recommend 1Password and BitWarden). Then add some passkeys to your accounts that support them and save them in your password manager.

Follow up polls

After some back and forth with folks online, I realized it would be worthwhile to run a couple of polls to see what others think and what they are doing for their logins.

Here’s the result of asking a bunch of Python enthusiasts on Twitter and Mastodon:

Cheers, Michael

Docker images using uv's python

michael@mkennedy.tech (Michael Kennedy) — Thu, 05 Sep 2024 15:12:04 -0700

TL;DR: Stop building Python from source in Docker (10+ minutes). Use uv venv --python 3.14 /venv to install Python in seconds. Pre-install common packages in a base image and use uv pip install for near-instant builds.

uv has changed the landscape

A lot has been written [1, 2, 3] about uv’s new features allowing it to not just work within Python but to manage Python itself. Many people have written me over email or social media to tell me that this will have a big impact. As a result, I just had Charlie Marsh (creator and lead over at Astral) on Talk Python to dive into the changes and implications.

And all of these conversations got me thinking:

I should really rework my infrastructure workflow to fully leverage uv.

How we run Talk Python

I haven’t written up how we run our devops over at Talk Python. It’s something I’ve been meaning to do as it’s undergone big changes recently.

The short version is that we’ve consolidated all our 6 smaller servers into one properly big machine (8 CPUs) and run 17 multi-tier apps all running within Docker containers using Docker Compose. You can get a sense of some of these apps by looking at our infrastructure status page, which also runs there.

To keep things simple and consistent, we have two Docker images that all our apps we write are based upon. One provides a custom Ubuntu Linux base and on that, we build a custom Python 3 image that has much of the shared tooling configured the same.

The Python 3 container had previously been managing Python by building it from source. And before you tell me there are official Python images, I know. But they don’t have Ubuntu and I’d rather have more complete control over my images. Plus, if I wanted to use another image that doesn’t base itself off a Python image, I’d have to manage it somehow anyway.

Building Python 3.14 from source is slow! It took up to 10 minutes to build that image. Luckily Docker caches it and we’ve only had to rebuild it 4 times this year.

And now a better way

One of the exciting new features of uv is the ability to create a virtual environment based on a specified Python binary that it manages and installs if needed. This takes just several seconds rather than 10 minutes! Here’s the command:

uv venv --python 3.14 /venv

With that capability, we can create a new hierarchy of images:

linux
   |
   |- python-base # (starting from the uv python command)
        |
        |- your-app-container

A Dockerfile for python-base might look like this:

FROM linuxbase:latest # our customized Ubuntu

ENV PATH=/venv/bin:$PATH
ENV PATH=/root/.cargo/bin:$PATH

# install uv
RUN curl -LsSf https://astral.sh/uv/install.sh | sh

# set up a virtual env to use for whatever app is destined for this container.
RUN uv venv --python 3.14 /venv

Making it really fly

With a few impure practicalities, we can really make this fast.

For example, if most of our apps are based on Flask and use Granian, then we could add this line to the python-base image:

RUN uv pip install --upgrade flask pydantic beanie
RUN uv pip install --upgrade granian[pname]
# No these packages should not have their versions pinned.

Because uv is SO fast, subsequent installs of common libraries will be instant if you happen to have the same version, which is mostly what happens.

Then be sure to run uv rather than pip for your app level dependencies. For example:

RUN uv pip install -r requirements.txt
# These packages do have their versions pinned, but mostly overlap with latest because I'm not a monster.

A working Flask example

Here’s an example you can play with that runs the “Hello World” Flask app with Granian in Docker:

faster-docker.zip

Just unzip it and run docker compose build in the same folder as compose.yaml to build and see how quickly it all comes together. In particular, once the linuxbase is built, just run docker compose build pythonbase --no-cache to see how quickly we get from Ubuntu to Python 3 with uv. Then start the website with docker compose up.

Some screenshots

Python base image installing uv and Python plus some common dependencies in 7 seconds:

Our app’s container with dependencies and set up in 800ms!

It’s already in action

So the next time you listen to a podcast episode or take one of our courses, you can think about this running behind the scenes making our continuous deployment story even better.

Keynote: The State of Python in 2024

michael@mkennedy.tech (Michael Kennedy) — Thu, 04 Apr 2024 17:35:23 -0700

This is a short post. I’m excited to announce that my keynote at PyCon Philippines is now available for everyone on YouTube. Have a watch and let me know what you think in the comment section on the video.

Cheers, Michael.

Use Custom Search Engines Way More

michael@mkennedy.tech (Michael Kennedy) — Sun, 28 Jan 2024 09:04:10 -0800

TL;DR: Add custom search engines to your browser with short prefixes. Type “gh react” to search GitHub, “pypi requests” for PyPI, “u mountains” for Unsplash. Skip the middleman and search sites directly from your address bar.

What’s your favorite search engine? Do you live in the privacy-side of the web and choose DuckDuckGo, Kagi, or Brave Search? Are you chasing search points over at Bing? YOLO and just Google it?

Regardless of how you search, I’ve got a quick tip that’ll make you more productive on the web and preserve some privacy as a nice side benefit.

Here’s how I started this essay.

I was looking for a fun hero image to get my mind rolling and make this essay more fun: u search

What the heck is the u? It’s Unsplash, a lovely free and attribution optional stock image site.

Many of the proper browsers let you enter custom search engines. My mental picture of these had basically been alternatives to Google and Bing such as Kagi. But I realized that almost any website that lets you search it, can be a custom search engine.

Adding sites you often search lets you skip the step of either navigating there or searching your main search engine and then navigating around there for results on that site.

So many niche “search engines”

Here’s what I’m using that might inspire you:

GitHub - search GitHub repositories directly by using the prefix gh
Wikipedia - all of Wikipedia with the prefix w
YouTube - Search for videos directly on YouTube with y
PyPI - Find Python packages with pypi prefix
FontAwesome - Just the right “font as an icon” for my web design with fa
LinkedIn - Find that contact with l
Unsplash - Get a sweet stock photo with u
StackOverflow - Still good for programming help, use so
…

In Vivaldi, we just go to Search > + and enter a name, search URL with %s for the search term (e.g. https://stackoverflow.com/search?q=%s), and a prefix to use when searching from the address bar (e.g. so). Chrome, Firefox, and others have similar features.

If you can find a URL on the site you care about that roughly matches that URL for StackOverflow, you can add it as a search engine.

Now when I’m looking for a new Python package, I start my search with pypi term I hope this has inspired you.

Search Talk Python and Python Bytes Too

I liked this idea so much that I started wondering if maybe it was possible to surface important sources of data of mine to the world. Over at the Talk Python To Me and Python Bytes podcasts we have search that is very comprehensive.

After a bit of work, you can now add two more excellent search locations to this list. They even come with keyword completion.

Talk Python search integration [step by step set up]
Python Bytes search integration [step by step set up]

It turns out this involves the OpenSearch description if you want to create something like this for your site as well.

Unsolicited Advice for Mozilla and Firefox

michael@mkennedy.tech (Michael Kennedy) — Thu, 11 Jan 2024 22:25:39 -0800

TL;DR: Firefox is dying from lack of focus. My 4 paths forward: (1) Build a privacy-focused office/cloud suite to compete with Google, (2) Go all-in on privacy like Vivaldi/Brave, (3) Become a VC for like-minded startups, (4) Spoof Chrome’s user agent to stop “Firefox not supported” warnings.

I recently read an article entitled “What’s next for Mozilla?” over at TechCrunch. Firefox has been off-track for a while now. That makes me sad because I was a longtime user and advocate of Firefox. I’ve since moved on to Vivaldi, but that’s another essay for another time.

From the article:

For the longest time, Mozilla was synonymous with the Firefox browser, but for the last few years, Mozilla has started to look beyond Firefox, especially as its browser’s importance continues to wane.

Yikes. Firefox has been on a downward trend. Its usage is down from a high of around 30% to 3.5% generally, (7.6% on desktop). That’s not great. If that was just a fact of life, so it goes. But as I see it, the decline is due to a serious lack of focus and intention. Maybe Mozilla could use some unsolicited advice. They didn’t ask for it, but here it is from me anyway. I hope they take it as constructive feedback from someone who is a fan.

Missteps

My advice is informed by what I see as some of the missteps of recent times.

First misstep: Even while Firefox has been bleeding market share, they have been boosting the CEO pay ($2,458,350 in compensation from Mozilla, which represents a 400% pay raise since 2008) and laying off 25% of their employees (significantly in the developer tools and platform feature development areas). Platform feature development sure sounds like “Firefox team.”

Second misstep: Firefox has stepped away from web standards. One of the most important features for driving the web forward is PWAs (Progressive Web Apps). But Firefox decided they were too much trouble and actively removed them. The Mozilla Connect request to re-enable PWAs has over 32 pages of comments almost universally asking for them back. Meanwhile, look how much Apple is promoting the idea these days.

Third misstep: Becoming a proxy for the biggest advertising company in the world. Google’s search deal means Mozilla takes in 95% of its revenue directly from yearly agreements with Google. This seriously constrains the moves Firefox and Mozilla can make.

Paths forward for Firefox and Mozilla

According to the TechCrunch article above, Mozilla is moving into AI and launching Mozilla.ai because we need ethical AI. Nope, that’s not going to fix things. There are 1,000s of companies running in every direction on AI, some ethical others not. But Mozilla trying to lead using ethical AI won’t change those who’d rather not be ethical in the industry. VCs are gonna VC after all.

Michael’s Path 1: Privacy-focused docs, drive, and browser

Mozilla should make an office suite in the cloud that is extremely privacy-focused and make sure Firefox is a top-tier client for it. We’re talking no advertising, end-to-end encryption, all the works.

I envision this to be not just docs, but compete with many aspects of how people use the cloud SaaS world:

GMail / Fastmail / Proton Mail
Google Drive / Dropbox / Proton Drive
Google Docs / Sheets / Presentation / Photos
SalesForce CRM / All the other CRMs
Invoicing / Document Signing / etc.

Just flood the market with top-notch, privacy-focused, paid apps in this space.

Can’t be done? No one can compete with Google Docs at this point? If you feel that way, Zoho would like to have a word with you. They have 55 (!) such apps and which are excellent. Zoho also makes over $1B/yr revenue and are entirely self-funded. I’m a big fan. And that revenue is double what Mozilla makes even including the Google deal. Without Google, it’s 40x what Mozilla makes.

For this suite, they’d have free tiers but charge for them earlier than Google. You pay Google with your data, you’d pay Mozilla for a product.

Michael’s Path 2: Go all-in on privacy in Firefox

Firefox is concerned with privacy, sorta. They don’t go nearly as far as Vivaldi or Brave. Why? Well, misstep 3 is likely the reason. They are 100% beholden to a company that is the antithesis of privacy. If they anger Google too much, bankruptcy is quick on the heals.

So they can be private-ish, but not private. Firefox doesn’t let you add 25 additional block lists for ads or malware like nextdns.io. They don’t have super agressive built-in options for ad-blocking like Vivaldi and Brave. And so on. I wonder why…

Vivaldi and Brave are better than Firefox and are inspring. However, mimicking them probably won’t change Firefox’s fate. They should specialize.

I recently learned of a new “Enterprise Browser” called Island. It’s super interesting and coincidentlly cofounded by a friend of mine. Watch the video on the landing page. Island may have the market cornered already, but something special like this could really change the fate of Firefox.

Michael’s Path 3: Become a VC for like-minded startups

This one they sorta doing already. They have $.5B / year and if they took a good chunk of that and invested just like a VC firm into startups that shared their ethos (not necessarily in browsers or open source, just web = open and good, etc.), that could probably be a big winner in the long term.

Michael’s Path 4: Lie to the world

What, what? Yes, lie to the world (of websites).

Should you trust the stat counters that put Chrome so high? No. But they are probably right for Firefox. The difference is that Vivaldi and Brave both lie about their user agent. What’s my Vivalid user agent right now?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Brave’s user agent?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

What’s Chrome’s user agent right now?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

See the difference? None, and that’s a major advantage. Vivaldi claims to be Chrome so websites don’t refuse to run.

But websites often rail against:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0

That’s Firefox right now. Maybe Firefox should just claim to be Chrome and all those warnings will go away. Firefox usually works anyway. One of the main drivers pushing people away from Firefox are all those websites warning “This website won’t work in Firefox!!!!” A white lie like this one would completely elimante that pressure.

There it is

That’s my advice. I hope it gave you some food for thought. And for folks from Mozilla reading this, I wish you well and hope to see Firefox grow. If you want to talk more, hit me up in the email below.

Have Thoughts?

Join the discussion of this post over on Mastodon or ExTwitter.

PS - Looking for tech advice?

If you’re looking for tech advice for your own company, generally or on a Python projects, I have recently started offering tech advising services and would be happy to talk with you. Just shoot me an email.

AI Features a Waste of Time?

michael@mkennedy.tech (Michael Kennedy) — Fri, 05 Jan 2024 17:15:38 -0800

I was letting my mind wander the other day and this thought hit me hard:

How many cumulative programmer-hours have been utterly wasted on adding very mediocre AI features to every app imaginable which rarely actually helps you?

Speaking from a pure product perspective, I’m thinking of putting off that work-a-day feature like “Autocomplete should work for name or email address, not just email” and instead we get months of effort for a garbage AI integration that you try once, just for the novelty.

There was a great conversation on Mastodon about this, feel free to dive into it over there. Here’s a deeper version of that idea.

An Example: Spark Email

Let’s expand on this a bit with an example (and make this idea more permanent than a social feed screaming past) and talk about the Spark Email client.

I’m actually a huge fan of this app. It’s revolutionized how I handle email personally and across many accounts at Talk Python (contact@, sales@, support@, etc.).

But Spark is deep in the mode of adding AI for hype’s sake and who cares if it screws the product or distracts from incredibly low-hanging bug fixes and features.

You see the “Now with +AI” in the image above, right? That’s foreshadowing.

A work-a-day improvement they missed

Spark lets you snooze email and does so, along with many other commands, through their command palette (CMD/CTRL + K). Just hit those keys, type snooze, then type how long.

But what can you enter? It let you pick tomorrow and next week from a list or type a custom time. But the accepted text for a time is very very limited.

You can type jan, 6 at 1:30 and it’ll snooze until then, awesome! But what if you screw up and type January, 6 at 1:30?

Nothing, you can’t snooze until then! What if Jan 6 is actually next Tuesday? Can you say snooze until Next Tuesday at 1:30? Nope, it’s Jan not January and not next Tuesday, nor is it in 3 days.

The app is full of little rough edges like this.

Improving snooze is probably an afternoon for one of the main devs.

But no, it’s “Now with +AI”. Don’t you see how much better it is?

What do we get with this AI?

Because it has AI, it does awesome stuff like using the AI to fix grammar and spelling. Let’s see how this amazing feature works.

I first write a nice email (lovely looking, right?)

See that just was misspelled along with a few other words in that sentence. Here comes the AI to the rescue.

Below, you can see it perfectly corrects the spelling for the email. Thank you!

Yes indeed! The spelling is fixed. AI for the win. But because this is just jammed into the product, it absolutely destroyed all the formatting. The cool quote thing is gone. The image is actually deleted. The bold is gone. Everything is gone except for plaintext.

Can we focus for a bit?

Just how much better would this already nice app be if they just hit all the little rough edges and fixed things like that insane percision that is needed for snooze? Or even make the AI work like you’d expect.

This is what I mean when I asked: How many cumulative programmer-hours have been utterly wasted on adding very mediocre AI features to every app imaginable which rarely actually helps you?

And yes, I did report both of these bugs (lack of variations for snoozing and format breaking under AI spell checking) a few months ago. Maybe in 6 months when the AI features are done, we can tweak the regex for snooze, maybe, …, some day. Meanwhile, keep on proofreading with AI I guess.

Have Thoughts?

Join the discussion of this post over on Mastodon.

Hide Those Terminal Secrets!

michael@mkennedy.tech (Michael Kennedy) — Mon, 04 Dec 2023 11:59:55 -0800

TL;DR: Use Warp terminal’s secret redaction feature to automatically hide IP addresses, emails, API keys, and other sensitive data when screen sharing or recording. Enable it in settings and add custom regexes for your specific secrets.

Do you do presentations and want/need to show your terminal? Maybe it’s a conference talk and it’d be awesome to pull an example from a real log file but you’re terrified that, maybe, a user’s email or IP address were to appear on screen?

It’s a real concern.

Personally, I do a ton of live streaming for the podcasts (1, 2) as well as course recording and I’ve definitely stopped short for this reason.

Warp: A Nicer Terminal

Back at PyBay 2023, I was introduced to Warp. It’s an awesome terminal for many reason which I’ve completely switched to. I suggest you watch the YouTube trailer to see what it’s about.

But it also has a new secret redaction feature. It’s off by default, but easy to turn on:

I even added a few custom regexes to hide a couple of API keys that were appearing in my logs.

Some Examples

Try this: Log into one of your servers and post a screenshot of the welcome screen.

No? I would not do it with all the various settings/versions/ip addresses/etc. visible with the basic terminal. Here’s mine from Warp:

Cool eh?

How about tailing your log which may include API keys, emails, IP addresses (just 127.0.0.1 in this case but you still see the effect), etc:

That’s It

There’s not much to add other than now you know! I hope this helps you work with clients and consultants as well as in those presentation-type situations.

PS - If you do happen to want to check out Warp, use my referral link. All it gets me is a t-shirt, but why not, eh?

Don't Sweat the Ad Blocker Drama

michael@mkennedy.tech (Michael Kennedy) — Tue, 28 Nov 2023 13:05:08 -0800

TL;DR: Skip browser-based ad blockers entirely. Use NextDNS ($1.65/mo) for network-level blocking that works on all devices, everywhere. Chrome’s Manifest V3 can’t touch it.

You may have read with some dread (as I did) about Google’s various initiatives to block ad-blockers in Chrome by effectively breaking the Chrome Extension features via something called Manifest V3. What are we going to call these anyway, ad-blocker-blockers? :)

Ars Technica has a great write-up entitled Google Chrome will limit ad blockers starting June 2024 if you want to learn more.

But here’s a quick tip to help you avoid this limitation and so so much more.

Just use a network-level ad blocker

You may have heard of a PiHole - it’s not an insult but a way to use a RaspberryPi to filter your DNS traffic on your network. It’s fine and all but it’s another thing to maintain and only works on your home network (although that’s excellent), and seems generally limited to me.

Instead, I’ve been using a service that is similar, takes zero set up, and works anywhere I am in the world: NextDNS.

Rather than leaning on your browser to block all the baddies, just let your network deny access entirely. This works in your web browser, but it also works on all your mobile apps, on your smart TVs, everything. It’s way better than an ad blocker.

It starts out free, but if you do a lot on the internet (or have many people and devices at your house like I do), you’ll probably have to pay. It’s only $1.65/mo and so worth it.

How it works

Just create an account at NextDNS (that link gives me a very small credit towards my account BTW), “link your IP address” so that your local network is protected across all your devices (as I mentioned above) and adjust your router to use their DNS IP addresses instead of your ISP’s. Do make sure to update the linked IP if yours changes, mine rarely does.

If your router has support for DNS over HTTPS, you can set that and forget it.

Add it to your browser

That works when you’re at home. But what if you are at a coffee shop or traveling, or even using a VPN that changes the DNS?

You’ll definitely want to enter the DNS over HTTP from your account into your browser as well. Then you have it globally!

Enjoy the cleaner and safer web again

Now you should have all your devices at home running ad/malware/tracking free as well as your browser while out and about. You can see just one day of a couple of us a home here:

Please disable your ad blocker…

Ooops. If you run an ad blocker, you’ll run across some sh*tty company that makes you disable your ad blocker to continue all the while forcing potentially malicuous and definitely privacy invading content on you. That’s why you care about this post at all, right?

But what if you need to disable this whole setup? It would be a mega pain to reconfigure your DNS and your router. But no need.

Just install a second browser and set its DNS to use a non-blocking DNS such as Cloudflare’s 1.1.1.1. Even though this is sold as a privacy-oriented DNS, it’s not blocking anything other than malware.

I use Vivaldi as my main browser. So I set up Firefox as a fallback. When anything fails to work because of all the blocking, I just launch Firefox and everything works (albeit without the privacy).

Here are my DNS settings in Firefox:

Note: Safari won’t work here because it doesn’t allow you to configure the DNS (hence making it a crummy browser choice all together anyway).

Chrome Gonna Chrome

So regardless of whether Chrome and Google go further away from their “Don’t be evil” pledge and turn Chrome even more into an ad surveillance tool by breaking ad blockers, you’ll be way more protected.

You probably should be using Vivaldi or another browser other than Chrome. But that’s another conversation for another post. Even so, this makes privacy-first browsers like Vivaldi and Firefox better as well.

You Can Ignore This Post

michael@mkennedy.tech (Michael Kennedy) — Thu, 25 May 2023 10:43:38 -0700

GitHub has a whole repo full of ignores you can make use of. You might know that uncertainty of creating a new GitHub repository and are confronted with the dropdown “Add .gitignore”.

Do you choose Python? You are writing a Flask app, right? Wait, should you choose VisualStudio if you’re using VS Code? Maybe Node is the right choice if you are using npm for some front-end things.

You do have to think about this up front because it’s not possible in GitHub to change your mind after creating one of these repos.

But don’t despair. GitHub actually has all of these .gitignore files in an open-source repo here:

github.com/github/gitignore

So you can choose which ignore matches your project best. If you add a technology, just visit the repo, find the tech you’re adding, and copy over the relevant .gitignore lines into your existing repo. Boom, upgraded.

Bonus

You can also open PRs and file issues against the standard templete that GitHub uses if you feel the default .gitignore for a tech is out of date. I’m not sure how receiptive GitHub is to these suggestions but it’s an option now that you know where to look.

Rebuilding Mobile Apps at Talk Python

michael@mkennedy.tech (Michael Kennedy) — Mon, 15 May 2023 11:12:00 -0700

TL;DR: Talk Python’s mobile apps have been rebuilt from scratch in Flutter, replacing the end-of-life Xamarin version. Download the new apps for iOS and Android to watch courses offline with a much better UI.

We just completed a wonderful journey over at Talk Python Training.

We offer over 240 hours of Python course videos at Talk Python. Of course, we want our users to have the very best experience taking our courses. Unfortunately, the mobile web experience is less than ideal for watching video - especially video that is broken into small blocks best for reference usage after taking the course. For example, on iOS you can neither auto advance to the next video nor hide the navigation around the web browser leading postage stamp size videos you have to keep clicking. Yuck.

The most important missing feature is the ability to download and use our content offline (for trips, sketchy or restricted networks, and other situations).

Enter the mobile apps

Back in 2018, we knew this was a problem and build a set of mobile apps for phones and tablets on both iOS and Android. At the time, we chose Xamarin (as C# / .NET based mobile framework). It worked fairly well, but never gave the polished, truly professional experience I was hoping for. Still, it solved many of the shortcomings discussed above.

Since then, Xamarin has reached end of the line and will not be supported further. So the last thing we wanted to do is build on top of a dying framework.

Mobile apps, v2 (Flutter)

What framework to choose? After considering 3-4 options, I chose Flutter for our platform. It’s based on Dart, a nice language. The UI is beautiful. It compiles to native code on every platform (iOS, Android, macOS, Windows, and Linux). And, it’s a very popular ecosystem with 3x the number of Github stars as Python (153k vs. 53k) and nearly 2x as many as React Native (110k).

After working many long days with the talented Loren Aguey (Flutter developer on this project), the next generation of Talk Python Training’s mobile apps are available on all the mobile app stores. Just look at this UI, brilliant.

Get the app on your platform of choice. It comes in both a phone and tablet form-factor:

Like the new version? Please review it

If you like this new version of the Talk Python courses app, please consider taking a few minutes to review it at your platform’s app store. It’d make a big difference to us. Many of the existing reviews are either very old or are complaints about issues with the old version. Help us give the app’s public face a clean up.

Thank you to everyone who has supported me and Talk Python by taking one or more of our courses.

Dev on the Road

michael@mkennedy.tech (Michael Kennedy) — Mon, 09 Jan 2023 10:40:00 -0800

TL;DR: Leave your laptop at home. For travel emergencies, use: (1) Prompt app for SSH access, (2) GitHub.dev for editing code in the browser, (3) GitPod for a full dev environment. All work on an iPad.

The Problem

I am going on a non-work trip such as a weekend getaway to the coast or a week of skiing. I won’t be doing much or any work unless there is a critical infrastructure error. If there is a the website is down! sort of situation I have to jump in.

You may identify with this problem.

Luckily for me, this is a very rare occurrence. But the consequences are also high if it does arise.

What if something goes bonkers with the Talk Python Training site and its backing MongoDB server? Possibly something happens at DigitalOcean and I need to SSH into the server to fix it.

I really don’t want to drag my $3,500 MacBook Pro Max on the trip just in case.

But I’m always taking my iPad on trips. It’s my TV, my library, my magazine, photo album, and game station. All perfect for vacations and relaxing in the evenings.

Is there a way to make your iPad a dev machine?

Wow, I don’t know. That’s a stretch. But we can solve the problem above pretty well by approximating this. That is: How do I make my iPad enough of a dev machine to fix minor emergencies.

I’ve been thinking about this problem for a long time (and dragging the laptop along too). I think I have a pretty solid set up.

1. We’ll need SSH access to the server infrastructure

SSH and especially SSH keys make me nervous. But keeping them locked on my iPad behind biometrics seems safe enough. So I chose Prompt from Panic Software.

Prompt

It’s the best SSH client for iOS. Restart your server from a coffee shop. Fix a web page from the back of a car. It’s elegant, powerful, and always ready.

Prompt costs $15, once, but it’s very capable. It adds a special keyboard with modifier keys such as CTRL making it terminal friendly. And the SSH keys and logins are protected with FaceID.

2. Accessing source code

I don’t usually code with VS Code but it’s a very solid option. And, I have continuous deployment set up on a production branch over on GitHub. So if I can just make a change and somehow push code to that prod branch, then CI/CD will take it from there (or I’ll use Prompt above and get in the server to kick things over).

You’re surely familiar with GitHub.com but how about GitHub.dev? That’s VS Code hosted in the browser running on GitHub.

If you open your repo on GitHub, for example:

https://github.com/mikeckennedy/jinja_partials

Then change the .com to .dev, boom! It’ll drop you into that project in hosted VS Code. You’ll need write access to the repo so open one of your repos and give it a try.

3. Dev environment

We have access to the servers with SSH, to the code with GitHub + VS Code in the browser. Yet sometimes you really need to run the code to figure things out.

The final piece (which you hopefully don’t have to use) is GitPod.

GitPod

Spin up pre-configured, standardized dev environments from any git context when you need them and close them when you’re done. You won’t go back to the friction of long-living stateful environments.

The idea is you connect GitPod to your GitHub repo. Configure it once to set up things like your version of Python and project dependencies and it builds the environment (in a Docker container I think).

They also have a hosted in the browser VS Code that then connects you to that environment. From there, you should be able to write what you need and test + debug it on their infrastructure.

The GitPod folks are on the same page as us here:

Code anywhere, on any device

You no longer need an over-powered laptop to code, Gitpod works just as smoothly on a Chromebook or iPad. All you need is a browser.

Finally, pricing is free with 500 credits/mo or up to 50 hours per month.

Apple, this is your fault

And you can fix it.

Of course, this whole iPad vs. laptop discussion is only because Apple is being dogmatic about iPadOS (ironic given the Steve Jobs quote).

If we had access to full macOS on the iPad, then we’d just do everything locally. After all, my iPad has an M1 processor and is just as fast as my desktop (Mac Mini) which I have been using daily for over 2 years. Apple has crippled the iPad with iPadOS.

Please Apple: Let us dual boot iPads into macOS for Apple Silicon.

I’m not suggesting adding touch to macOS or anything invasive like that. If you could just dual boot the iPad into macOS it would all be self-contained and the same tools as we usually use would be available to us.

This could easily require a keyboard and mouse, no touch. Thus, it would not require any changes to macOS. We’d be golden. I’m holding out for that. Until then, the tools above are a pretty good “just in case” travel set up.

Discuss

What do you think? Do you do something like this for traveling or are you dragging your laptop along these days?

fosstodon.org/@mkennedy/109660721346086147

Welcome back RSS

michael@mkennedy.tech (Michael Kennedy) — Tue, 03 Jan 2023 00:00:00 +0000

TL;DR: RSS is making a comeback as people tire of algorithmic feeds and walled gardens. It powers podcasting (Talk Python serves 0.2 TB of RSS XML monthly), and great readers like Reeder make it easy. If you’re a developer, add RSS to your projects.

When was the last time you thought about RSS? You know, that wacky XML format for subscribing to blogs?

There are some interesting tech and cultural trends shining a light on RSS. They are making the case that RSS is key to sustaining and growing the web that we all of us want: A thriving and independent aggregation of 1,000,000s of points of light rather than 3 large tech giants feeding us content through algorithms.

Some interesting articles I ran across today

A couple of articles came my way today to nudge me to write this post.

Back to RSS by @wimt@whereismytribe.net starts with:

“It’s 2023. Or 1999… Whatever. Personal sites are back. Blogs are back. RSS is back. Owning your data is becoming real…”

Indeed. Owning your data, owning your privacy, and owning your legacy is increasingly interesting and relevant. Turns out RSS might be an important part here.

Then there’s Bring back personal blogging: Twitter is creaking. Social media seems less fun than ever. Maybe it’s time to get a little more personal from The Verge.

“In the beginning, there were blogs, and they were the original social web. We built community. We found our people. We wrote personally. We wrote frequently. We self-policed, and we linked to each other so that newbies could discover new and good blogs.

I want to go back there. "

Turns out I “do” a lot of RSS

RSS is the foundation of podcasting. Publishing a podcast really is just sending out an RSS feed that includes <enclosure> tags with MP3 links in them.

It’s probably no accident that podcasting is also one of these bastions of 1,000,000’s of small points of light being largely independent and open. Although, companies such as Spotify and others are trying their best to aggregate them. BTW, if it’s all the same to you, please consider listening on an independent player like Overcast or PocketCasts rather than one of these tracking aggregator platforms.

Here are some fun stats from Talk Python’s and Python Bytes’s RSS feeds in December 2022.

HITS	VISITORS	TX. AMOUNT	URL
1,016,148	285,648	128.17 GB	talkpython.fm/rss
513,993	146,296	51.18 GB	pythonbytes.fm/rss

That’s over 400,000 people pulling down 0.2 TB of XML monthly. I can only guess how insanely much XML that is when seen uncompressed given how dramatically text can be compressed.

So yeah, RSS is pretty important to me.

There are some pretty great RSS readers

When I hear conversations about RSS, they quickly get to “then Google killed Reader” and that was that. We were all done with RSS.

But recently started using Reeder for macOS and iOS. If you’re in the Apple ecosystem, the desktop and mobile apps work together like hand in glove and sync your feeds and history privately through your own iCloud account. It’s a paid app, but not a subscription and the price is fair.

Remember that The Verge article? Know how I found it? RSS + Reeder:

Yes, Reeder is only for Apple people. I’m sure there are similar excellent ones for Windows and for Android. But I don’t have enough experience recommend any beyond a DuckDuckGo search for popular ones. Feel free to chime in below with recommendations.

In fact, I’ve started to embrace reading sites that have an RSS feed even if they don’t ship the full article (like The Verge one above). And I’ve curtailed reading sites that don’t offer some form of RSS. After all, how much effort is an RSS feed if you’re already a news organization.

While you’re here…

If you are trying out a new RSS reader and looking for feeds, I have one for this site:

https://mkennedy.codes/index.xml

Consider adding it to your reader along with the Talk Python and Python Bytes feeds listed above. :)

If you are a developer

Then you have the power to shift the balance towards openness and independence with RSS even if by just a tiny little bit. Add RSS to your things. It’s not particularly hard and you can use template language tools you’re likely familiar with. For example, Jinja2 for Python folks or Razor Pages for .NET.

What can you put an RSS feed over at your org?

If you’re not a developer, just ask. Ask companies and websites that don’t offer some way to subscribe to their content to add an open protocol such as RSS.

One example I was inspired to add

If I’m giving advice, I’d better take it too, right?

As I mentioned above, we are shipping an insane amount of RSS for the podcasts. But what else could I do?

I decided that our courses over at Talk Python Training might be a good candidate for RSSification. So I took an hour or two and put that into place. I present to you:

training.talkpython.fm/courses/rss

Another area at Talk Python Training is our free office hours. We offer these to all our students as part of the benefit of learning with us. So we also now have an RSS feed for when those office hours are put on the calendar:

training.talkpython.fm/office_hours/rss

Now it’s your turn!

Discuss

I’m not a fan of comments on my site. They lead to too many spammers and the platforms to plug them in usually add a bunch of tracking scripts too.

So join the discussion over on my announcement for this article on Mastodon: fosstodon.org/@mkennedy/109624369441214016

Paying for search in 2022, am I crazy?

michael@mkennedy.tech (Michael Kennedy) — Tue, 13 Dec 2022 00:00:00 +0000

TL;DR: After 6+ months using Kagi, I’m still paying $10/month for search. The results match Google, there are no ads or trackers, and you can permanently block SEO-spam sites. Worth it if you can afford it and value privacy.

I have some core beliefs about the technology world as a software developer and netizien.

Open software and tools should be preferred
Surveillance capitalism is net-net bad for society
Tracking and retargeting on the Internet is morally wrong (it’s not just about ads, think about hidden levers like the Facebook–Cambridge Analytica data scandal)
When people support small tech companies, we all win

Search at the intersection

Many of those ideas come to a head when thinking about search and web browsers. Today, we’ll focus on search:

Search engines are often, but not always, ad supported. Some of those more on the neutral-good side of the spectrum like DuckDuckGo. Others, are fully on the dark side [defunct link: https://ads.google.com/intl/en_uk/home/resources/retargeting-ads/].

There are a bunch of smaller, independent, privacy-oriented search engines. Most of those also have ads but do their best to limit tracking exposure. The one I’ve been using lately is called Kagi.

Kagi is a paid search engine that costs around $10/month. Premium indeed.

Live with it series

On the Python Bytes podcast, back in June 2022 I said I’d give Kagi a try and live with it for a month and then give a report. That report is overdue but here we have it.

I’m happy to say that I’m still using Kagi and really appreciate it.

Before Kagi I used DuckDuckGo and am a big fan. But Kagi shares a lot of the same philosphy as I laid out above. And it has some pretty great features:

100% privacy-respecting
No ads (so no perverse incentives like what DuckDuckGo got caught up in, I still 💕 you DuckDuckGo)
Ability to permanently block crappy websites that win with SEO only. How do you feel about w3schools? Yuck:

Just block it right there in the search results with Kagi (there is an option button by each result on the page):

Look before you leap

Kagi also lets you know you’re about to enter a hellscape of surveillance capitalism. CNN is one of those evil companies who thinks there just aren’t enough trackers and retargeting companies they can latch onto you.

The search results have a red warning symbol next to them.

Let’s see why:

Oh, I see. There are 43 trackers on that page. 43 trackers! There is just no excuse for this.

But with Kagi, you at least know what you’re headed into before you click. You also get nice web stats like SSL status, site popularity, and speed in that report.

Is switching to Kagi worth it? Three angles to consider:

First, even with all the highfalutin privacy and customization, a search engine is only as good as its results. I believe Kagi is actually buying search data from Google and Bing. The results seem basically the same as Google so, a solid checkmark here.

Second is the privacy. Yes, this is absolutely worth it and they seem to be true their word. Privacy is very important to me. Maybe it’s worthwhile to you too. Then again, most people would rather be the product and recieve a service for free. I also pay $6/mo for email for the same reason.

Third, is Kagi worth $10/month? Oh this one is right on the border. More than once I’ve had my mouse cursor over the cancel account button. Am I crazy to pay $10/month for search, I ask myself?

But every time I switch back to another search engine, I like it just a little less. I’m lucky. I can spend $10 extra a month on a service. I’m a software developer making a good income. I have my own business that is successful. So yes, it’s worth it. Your situation may be totally different and that’s fine. But if it is, maybe try DuckDuckGo over Google?

This post is definitely not an ad and is in no way sponsored by Kagi. But if the principles I laid out here appeal, consider giving Kagi a try. Worst case, you’ll dodge a few ad trackers and support a small tech company for a month.

Feel free to pick up the discussion on my Mastodon post for this essay:

fosstodon.org/@mkennedy/109507827811863800

Sometimes, You Should Build It Yourself

michael@mkennedy.tech (Michael Kennedy) — Thu, 08 Dec 2022 00:00:00 +0000

TL;DR: Not Invented Here syndrome gets a bad rap, but sometimes building it yourself pays off. It did for Talk Python: better UX, custom integrations, real coding experience, and it’s fun. Just be selective about what you build.

Developers are often itching to try out the latest shiny tech on problems they’ve been asked to solve, even when there are perfectly good existing solutions they could adopt instead.

Need some help desk software? Sure we could use Zendesk. But if we rewrote it in HTXM and FastAPI, we could do MUCH better and it’d be custom-built for our use case. Think of all the integrations.

Adding silently: And I get to use HTMX!

This is often called Not Invented Here syndrome and is strongly cautioned against:

NIH: The belief that in-house developments are inherently better suited, more secure, more controlled, quicker to develop, and incur lower overall cost (including maintenance cost) than using existing implementations.

Just look at PyPI for packages to access PostgreSQL, there are 2,348 results! Yet, there have to be multiple projects connecting Python and Postgres in development right now.

But sometimes, you should build it here

I’m starting to think the advice to avoid NIH syndrome at all costs is not always good advice.

Looking back on the last 7 years at Talk Python, there have been plenty of times we could have slotted into someone else’s ecosystem but benefited from building parts of our tech ourselves. This is true both as a business and for me personally.

Here are just some of the ways embracing a NIH tendency has benefited us.

1. It’s made Talk Python a better service for everyone

Very polished platforms for listeners and advertisers

Controlling our platform means we don’t have to slot into someone else’s poor design and slow web apps.

Consider one of the more popular podcast hosts (think WordPress but for podcasters) and how great of an impression you get from visiting their content.

Does this page below draw you in and entice you to listen? I would think absolutely not.

Contrast that with Talk Python’s episode pages:

You may not totally love the design. But it’s certainly something I can be proud of.

The same goes for taking courses at Talk Python. Here’s the clean and fast view of taking a course:

We could have decided to publish our courses on other platforms like LinkedIn Learning. In fact, we have tried a few syndication deals. They were basically failures from a business perspective. So, I’m happy we built our course platform ourselves.

Integrations abound

Do you have amazing ideas of leverging some aspect of your org for another? Taking someone else’s product/platform might mean that’s not an option.

Here’s an example.

We stream all our podcast events with a live audience on YouTube. That’s lots of fun and a cool experience for our listeners:

But because we control the platform, we can push a single button on our Stream Deck, that:

Announces the live stream on Twitter
Announces the live stream on Mastodon
Puts the website into live stream mode encouraging people to be part of the audience

But it goes further. Once the live stream is done, the platform takes the thumbnail we’ve carefully crafted for our YouTube video and make visible on the episode page.

After that, the website automatically pulls that image and uses it for our social share in Twitter, Mastodon, and others:

That’s Stream Deck > YouTube > talkpython.fm Live Mode > talkpython.fm episode page > social share.

All of that is fully automated. How is this possible? We built it ourselves.

Advertiser dashboards

The other side of the podcast story wins too. Podcast advertisers get a full dashboard with per second reporting of traffic to their sponsored episodes and the number of visitors to their sponsored links.

We can do this with zero tracking forced upon our listeners, unlike most platforms.

2. I gain experience writing real code

As someone who talks a lot about writing code and teaches a lot about writing code, it’s important to remain connected to actually writing code. Creating our platforms means I get daily experience working on high-end Python software in production.

We do around 20 TB and millions of requests of traffic monthly
I evolve the software from older code to newer code (like MongoEngine to Beanie & Pydantic or integrating FastAPI)
I manage this platform on 8 coordinating servers as well as across CDNs and integrating with other platforms (like iTunes catalogs)

This means when I sit down to speak with guests or write a course, I often have very real world experience to draw from. Because I built it myself.

3. It is a lot of fun

Finally, writing this code and growing as a developer is just tons of fun.

4. But also a counterpoint

That doesn’t mean I don’t sometimes choose to NOT build it ourselves.

Our credit card sales are handled by Paddle. This site is creating using the static site generator Hugo. Neither of these was built here and I’m very happy to not work on them.

So when it makes sense consider building it yourself but just not for everything.

Properly Factor Your Jinja HTML Code with Jinja Partials

michael@mkennedy.tech (Michael Kennedy) — Sat, 03 Dec 2022 00:00:00 +0000

TL;DR: Use the jinja-partials package to add function-like reusability to your Jinja templates. It lets you call named template fragments with parameters, avoiding the 600-line template problem.

If you work with Python code, then you’ve surely seen some bad code. Martin Fowler popularized the idea of code smells.

“Code smells are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality.” [wk]

This may have been your bad code. More likely, if you’re taking the time to read about code styles, it was someone else’s.

Either way, one of the biggest offenders is the long method.

You know, that single Python function that is

627

lines

long.

Really? Yes, apparently. We see this and immediately know it’s bad. Usually this has some some foul code duplication mixed in for good measure.

If you were responsible for this code, you’d fix it straight away.

But we do this every day on the web

While outrageous in code, we wouldn’t bat an eye if we had an HTML template (think Jinja2 from Flask/FastAPI, Django template from Django, or Chameleon from Pyramid) that was over 600 lines of HTML.

There usually is no mechanism of a function call within HTML templates for Python languages.

Or is there?

When I started working with HTMX (incredible framework!), this problem came to a head in my Python apps. So I created the Jinja Partials package. There is also a Pyramid/Chameleon version.

Jinja Partials adds the concept of a function call with a named set of template code and a clear variables / parameters passed to that template. The repo has some examples.

I just used this concept to surface more options for subscribing to Talk Python.

See the choices of podcast players in the list of episodes page:

And on the episode details page:

As well as the new subscribe page:

That list of podcast players, style, and basic analytics (click counting) is all handled with just this HTML fragement:

{{ render_partial('episodes/partials/subscribe-in-players.pt', 
                 is_listing=False, 
                 cdn_prefix=view.cdn_prefix)
 }}

If this idea of a function inside HTML appeals to you, then check out jinja-partials or chameleon_partials.

Finally, if you’re one of the few people saying “Jinja already has include!!!” Yes, it does. It’s not the same. See the whole discussion here.

What about Jinja’s include? Jinja’s include is analogous to C++ precompiler macros without passing parameters. Jinja Partials is like functions with parameters and local variable scope. They can both solve the same problem some of the time, but they are definitely not the same.

Hope you find this idea of cleaning up your HTML templates with functions appealing!

Black Friday: A Lesson in Python Performance

michael@mkennedy.tech (Michael Kennedy) — Thu, 24 Nov 2022 00:00:00 +0000

TL;DR: When Black Friday traffic nearly melted our servers, the bottleneck wasn’t Python. It was nginx handling SSL and static files. Adding a CDN (Bunny.net) dropped CPU from 85% to 7.5% for $2.

On Wednesday, we launched our Black Friday Sale over at Talk Python Training.

If you know me, you know that I’d much rather just offer a fair price year-round (which I think we do) and avoid hyping these sales. But many many people asked for it. So we’ve done this the past few years and it seems to have been very appreciated by our users.

Generally, our infrastructure has handled Black Friday fine. Yes, it’s busy on the first day for sure, but not melt-your-servers busy.

Until this year.

After sending out the announcement, I fired up glances on our web server just to see how it was going.

The server was at 85% CPU usage … and going up.

88%, 91%, 92%, … Uh oh.

It wasn’t going to be able to handle much more. But there was a surprise: It wasn’t the 8 uWSGI Python worker processes getting pounded. It was nginx. I wish I took a screenshot but here’s what you might have seen:

Process            |  CPU Usage
----------------------------------------------------------------
nginx worker 1     | *************************************
nginx worker 2     | ****************************************
uWSGI worker 1     | **
uWSGI worker 2     | ****
uWSGI worker 3     | *
uWSGI worker 4     | **
MongoDB            | **** (on dedicated server)

This was so surprising to me. In case you’re unfamiliar with this deployment topology, here’s what each part is doing:

nginx (static content)
- Direct web browser connection
- Terminating SSL
- Sending HTML/CSS/Image content to clients
- gzipping relevant content (HTML, CSS, …)

uWSGI (dynamic Python behaviors)
- The “app” of our Python app
- Running all our Python code
- Talking to MongoDB for DB queries and updates
- Queueing up emails
- Basically everything else

The surprise is that Python handled Black Friday perfectly. It was mostly idling along happy to serve up the requests in the “complicated” data-driven part of our app.

It was nginx just trying to do SSL, gzip, and the rest of static things that was killing the system. And nginx is considered fast! See Why is Nginx so fast?

It is worth pointing out that I have endlessly optimized the Python <–> MongoDB interaction and we have honed the DB indexes to a sharp point. But I still expected that area to be the point of contention.

So next time you get into that debate about why you can’t use Python because it’s not compiled and it has that GIL thing and I think we should use NodeJS or whatever, feel free to refer back to here.

And to wrap things up, thank you to everyone who cared enough to check out our courses even if they almost killed the server! ;)

Why nginx was the real bottleneck

After posting this article and a few conversations on social media, I think I know the cause (but it doesn’t change my surprise and general point of view).

Looking at the most commonly requested Black Friday page, it turns out there are a lot of requests we could offline (with added complexity of course).

On the page training.talkpython.fm/courses/all

1 HTML response (via Python)
12 CSS requests (many bundled, but some need to be separate like Font Awesome)
43 image requests
1 JavaScript request

The total size of the request is around 7MB with the HTML only 7.5kB. At the time of this Black Friday onslaught, we were not using a CDN because the content is served plenty fast and juggling dev vs. CDN URLs in production is a pain.

But this whole experience opened my eyes that we could push 56 / 57 requests to a CDN and drastically reduce the amount of content (hence load) we’re putting on nginx.

I chose Bunny.net CDN. After just 30 minutes, you can see the load that was put upon our nginx process, now shared across the world (and content closer to the users):

So far, Bunny is fantastic software. Only took about 15 minutes to set up the CDN, a custom domain, and SSL. Then there was the hour of changing all the CSS, JS, and IMG links across Talk Python Training :).

At $0.01 / GB, gaining access to this much distributed infrastructure seems like a great tradeoff. As of this writing, we just passed our first GB of content over the CDN. That’s a penny well-spent.

Another update and Cyber Monday

The fun thing about Black Friday sales is they are generally bookended by Cyber Monday.

Before I said I wish I had taken a screenshot when we sent out the announcement for the opening of Black Friday. It turns out there is roughly the same amount of traffic and interest in the closing day of our sale and this time I did take a screenshot.

With our Bunny.net CDN setup fully in place, things were quite different and our infrastructure was busy but happy. I now see why our nginx server was hurting so much.

Here’s the realtime traffic on the CDN:

1.4 Gb/sec of static files. Glad we moved those requests the edge.

And here is our app server at the exact same moment, the one that nearly melted. Note: Cache misses are generally pulled from other CDN nodes, not this server.

7.5% CPU usage total and only 3% across both nginx workers.

Finally, we all know that with enough complexity and money, you can solve almost any scaling problem. But this was not expensive:

I switched most our traffic over the past 2 days. So far we’ve spent $2 in total.

I hope my sharing our experience here has given you something concrete to consider when scaling your Python apps (or any web app really) for relatively small teams and deployments.

Python 3.11 in 100 Seconds

michael@mkennedy.tech (Michael Kennedy) — Sun, 20 Nov 2022 00:00:00 +0000

Python 3.11 is a massive release. The release notes doc is over 175,000 words. That’s more than double the size of a typical novel or nonfiction book!

Most important is its speed. Python 3.11 is between 10% and 60% faster than even 3.10 for typical applications. But there is a lot more to 3.11 than just speed. If you have 100 seconds to spare, watch my latest video, Python 3.11 in 100 Seconds:

Watch on YouTube

Mastodon First: My New Social Attitude

michael@mkennedy.tech (Michael Kennedy) — Sat, 19 Nov 2022 00:00:00 +0000

Without a doubt, my most beloved social media platform has been Twitter. I joined over 14 years ago. And across my personal account and the podcasts’ accounts (1, 2) we have built an audience of over 100,000 members. It’s an incredible honor.

But with more than a little sarcasm, sites like Twitter is Going Great! … and definitely does not develop features primarily to stroke Elon Musk’s delicate ego [defunct link: https://twitterisgoinggreat.com] have been documenting the wild and downward spiral Twitter has been on.

So as you can tell from my other posts’ titles, I’ve moved to Mastodon (Fosstodon.org is my instance - aka home base).

My current attitude is Mastodon First

Let me elaborate. Now that I’ve spent some time over there, I see how closely Mastodon and open source philosophies align. This is not just because Mastodon is open source. Rather, the whole idea of controlled and owned by the community via federated instances resonates much better than big tech powered by surveillance capitalism.

I will be most active over on Mastodon. But I don’t intend to abandon my beloved community on Twitter or other networks (unless Twitter goes so great as to crash into the ground).

I encourage you to follow me over on Mastodon via @mkennedy@fosstodon.org. And if you’re new to Mastodon or just still holding out, I did an excellent panel discussion with many Python people entitled Mastodon for Python Devs over on Talk Python.

Installing Mastodon as a Progressive Web App (PWA)

michael@mkennedy.tech (Michael Kennedy) — Fri, 18 Nov 2022 00:00:00 +0000

TL;DR: Open your Mastodon instance (e.g., fosstodon.org) in a Chrome-based browser, right-click, and select “Install app.” It works as a standalone desktop or mobile app with instant access to new features.

When Mastodon 4.0 came out, the official iOS and Android apps were still 1.5 months old (it has since been updated). Exciting new features were added such as editing of posts. And we had to wait until the new version of that mobile app shipped separately to take advantage of them.

The web app had the new features instantly (and seems like it always will). Moreover, the mobile app isn’t a desktop app, is it?

How to Install Mastodon as a Desktop App

Luckily the Mastodon folks have done the hard work to make the web app (that’s yourinstance.org, e.g. fosstodon.org) a Progressive Web App that can be installed with a single right-click and runs as a perfect app on your machine:

This works for any Chrome-based browser (Chrome, Vivaldi, Brave, and others). Once you install it, you can add Mastodon to your dock/task bar and it is effectively a stand-alone app:

How to Install Mastodon as a Mobile App

This works equally well on both iOS (iPad preferably) and Android tablets. I even made a YouTube video showing how this works.

If you’re searching for a great Mastodon app, it might be hiding in your browser!

20% Faster Python with a Single GC Tweak

michael@mkennedy.tech (Michael Kennedy) — Thu, 17 Nov 2022 00:00:00 +0000

[Update Nov 23, 2022: Added perf graphs at the end of this article]

TL;DR: Increase Python’s GC allocation threshold from 700 to 50,000 at app startup with gc.set_threshold(50_000, ...) and use gc.freeze() to exclude startup objects. We saw 20% faster responses at Talk Python with no increase in memory usage.

Here’s a bold statement given that I know nothing about you or your app:

Your Python GC settings are wrong and they are hurting your performance.

Let me elaborate. Python has two types of memory management:

Primarily reference counting. Objects keep track of the number of variables pointing at them. If that number reaches 0, they are instantly deleted, deterministically. Without stats to back this, I’d guess 99.9%+ of all memory is handled this way.
The 0.1%: The one case that fails hard here is if you have a cycle (think Person object which has a spouse field). Enter garbage collection. This runs occasionally looking for missed ref count clean-ups.

Ref counting is great but the GC, it runs too often.

The trigger is when you allocate 700 or more container objects (classes, dicts, tuples, lists, etc) more than have been cleaned up, a GC cycle runs.

Imaging you’re doing a query:

recent = await PageHits.objects().filter(date >= today).to_list()

If there are anywhere near 700 results in that query, you’re hitting GC cycles before you even get the full list back.

Our sitemap at Talk Python Training was resulting in 77 GC cycles to just load the page, 77!

training.talkpython.fm/sitemap.xml

Yikes.

But you can change it. Try this code at app startup:

# Clean up what might be garbage so far.
gc.collect(2)
# Exclude current items from future GC.
gc.freeze()

allocs, gen1, gen2 = gc.get_threshold()
allocs = 50_000  # Start the GC sequence every 50K not 700 allocations.
gen1 = gen1 * 2
gen2 = gen2 * 2
gc.set_threshold(allocs, gen1, gen2)

Of course, your mileage will vary. But at Talk Python, we saw a 20% overall speed up with no change in the memory usage.

If you want to dive much deeper into this, check out my recent video showing this live where we got 2x perf with just this code for a simpler example:

Dive in with my Full Course

If this all sounds interesting and you want some practical, hands-on experience and a solid look behind the scenes about how Python memory works and what knobs you have to control it, check out my full course over at Talk Python Training: Python Memory Management and Tips Course.

Real-World Performance Results

There has been a bit of debate on how realistically this improvement is for real workloads. I can’t test yours, but here are two production end-to-end requests from Talk Python Training.

I used locust to run some performance tests against two URLs on our site:

Sitemap (the most expensive page on our site)
Search for a super common term

These both showed clear > 20% improvements:

Search:

Sitemap:

Discussion

This post got a decent amount of discussion. You can see it over on the Mastodon thread.

Hassling Spammers

michael@mkennedy.tech (Michael Kennedy) — Wed, 16 Nov 2022 00:00:00 +0000

Running a set of popular websites (e.g. talkpython.fm) means I get a lot of unsolicited emails. Some are genuine and very welcome. But others, clearly spam. One day, I decided rather than just deleting them, let’s just make them spin their wheels a bit and return a little frustration.

I get daily requests to “guest post” on our corporate blog. Note that we do not have a company blog at all.

Here’s a real back and forth I had last week. It was beautiful.

Spammer: I have just gone through your website and read some of the blogs; they are outstanding. I can get working on the article to send it over…
Me: Oh, you read our blog? What is the URL of it?
Spammer: Excellent. The URL is https://training.talkpython.fm/courses/up-an…
Me: Are you insane? That’s a course, not a blog. If you cannot tell the difference, I don’t think we should be working on technical items together.
Spammer: I have some good topics on python

I bet they do. I bet they do have some great topics. Probably stolen from legit authors with links back to whatever scam they are pushing.

It was a fun conversation. ;)

Python's Entire Codebase Leaked

michael@mkennedy.tech (Michael Kennedy) — Sun, 13 Nov 2022 00:00:00 +0000

If you work in Python, heads up: The entire source code base for Python has been leaked.

As many as 24,000 copies have been found on GitHub. 24,000… let that number sink in for a minute.

If you’re familiar with GitHub, they call these rogue copies “forks”.

While this news has just broke publicly, after inspecting the records and historical Usenet postings, we believe this code has actually been accessible since 1991.

See the original citation for further discussion and details.