Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 470. I know what we're doing.
And it is Monday, February 23rd, 2026. I'm Michael Kennedy.
And I'm Brian Okken.
This episode is brought to you by us.
We have many interesting things available or in the works that we're going to be announcing.
I know, Brian, you're working on your Lean TDD book.
I just released Command Book, which ironically is not actually a book.
But other things, obviously our courses and so on.
So seriously, we put this stuff out here because we think it's a perfect complement to the podcast.
And we'd really love if you'd consider it as part of your learning, reading and so on.
Also consider signing up to the newsletter.
We've got a bunch of people enjoying the newsletter.
We put a lot of effort into it to generate extra info, background info, more links, not just, hey, we're emailing our show notes out.
Isn't that inventive?
No, we're doing extra.
And Brian is spearheading that.
So thank you for doing that, Brian.
And yeah, connect with us on the social.
Subscribe here on YouTube if you're interested in catching the live show.
Just go Python by Statofilm slash live.
Click the link.
Crush the bell.
You know, so that way you actually get a pop-up when we're streaming live like we are right now.
And with that, I think I want to talk about inline snapshots.
What do you think, Brian?
Yeah, sure.
Let's zoom in.
Or in.
I don't know.
Sure.
Somehow.
Wow.
So I'm going to cover, and this is a fun article, actually, from the Pydantic blog from Alex Hall.
And the article is Better Python Tests with Inline Snapshot.
And actually, it's that.
But it's also kind of a peek at how Pydantic is doing some of their testing.
And, you know, it would be, it's not a bad idea to try to emulate Pydantic because they've been doing great.
So anyway, let's dive into what they're talking about here.
The problem is the maintaining test data for complex data structures and how you compare.
So their example is like create a user with an ID of 23 or 120.
Anyway, test a name and an ID, and then checking to make sure that it really is, you know, getting the data, the object, and validating that it's correct, that some action happened.
This is all cool and all, but it's not really, it's hard to fill that in.
And if you have tests like that all over the place, it's hard to make sure that they're up to date and everything.
So there's a lot of ways that people have done, attacked this problem before.
Like they give a shout out to Syrupy, which is a cool project also.
One of the, and so one of the issues, okay, so one of the issues is, let's say you've got a bunch of stuff.
You want to, you know, these systems working right now.
This is kind of how the workflow is.
You know, it's working because of other testing or manual testing or whatever.
And you want to like just save a bunch of, have some tests and save what the output is and then test against that.
Like a known, known input and the, you know, it's working.
So grab the output and compare the two.
And that's the sort of the model.
And with Syrupy, it saves that in an, in an external file, but with inline snapshot, it saves it right in your test.
So I'm going to take a look.
Like you, you start out with like an empty snapshot with an empty bracket, and then you run the test with inline snapshot equals fix.
So it's like fixing the snapshot or fixing them in place.
And then it, it actually goes out and changes your test and fills in that little template bracket with data that you can compare with, with whatever you want.
And that's actually pretty awesome.
It just like turns the, turns the user, like some data structure into a dictionary or whatever, take a data structure, snapshot that, and then you can run with it.
There's a few reasons why I kind of really love this.
One of the things is just maintenance.
If you're like before and after a big change refactoring, you can like set some of these up and, and then like refactor and then go back and make sure everything's, you didn't intend to change anything.
You want to make sure things change.
And then sometimes you do want to change like lots of the data structure.
And, and then you can like having the, this right in line with your tests, you can have that, like go through a code review and manually inspect the test and say, yes, this is actually what I want it to look like.
The danger is if you don't manually inspect, then you're not going to, you're just believing whatever's there.
It's then it's, then your tests just become a change detector test and nothing else.
And there's, you know, sometimes there's a place for that.
So anyway, a great article about snapshot testing.
But I also do want to shout out to a lot of the other tools that they bring up in this article.
So I'm going to go through some of them.
There's, there's the pytest Examples, which is the plugin that they're talking about with this inline examples.
There is inline, wait, no, this is another tool.
So pytest Examples is another tool that they've got.
And that's pretty cool.
So the inline snapshot is, is this, this tool that we're talking about.
And then there's Syrupy, which isn't a bad tool.
And if that's better for your workflow, take a look at that as well.
And that's very popular.
And then there's a dirty equals, which is a fun, I should probably cover this at some other point if I haven't already.
A fun, almost equal sort of a thing.
So you can do things like, is the number positive?
And, and there's a whole bunch of other extra things around comparisons that are not exact comparisons that are kind of fun.
And then, and then a shout out to a thing called executing, which is being able to, it says a mini package that lets you get information about what frame is, what the frame is currently doing.
So about their current execution frame in Python, which is, I've never had a need for that, but it's kind of interesting.
So anyway, shout out to that great article.
Lots of tools.
That might be interesting for like low effort logging and stuff, you know, enhancing test output or just logging in general.
It's like, I got an error.
I want to just say, well, what parameters were supplied to this function and who called it?
Maybe something like that, just an automatically add that to the test output or something like that.
Yeah.
There might be some cool, fun things for logging the execution frame.
Yeah.
Nice.
That's a bunch of, a bunch of cool tools.
I love the idea too.
I like this.
Now let's jump over here.
I want to talk, I want to shock you, Brian, with this, but I want to talk about Jolt.
Okay.
So Jolt is a TUI, a pretty sweet TUI actually, which is battery intelligence for your laptop.
Okay.
So this is not really a Python tool, but it's certainly a tool that Python people could love.
Right.
It's kind of a developer oriented thing.
Right.
So it says battery intelligence for your laptop, real time power monitoring process, energy tracking, battery health insights, all in your terminal.
And it works on macOS and Linux.
Okay.
Sorry, windows folks.
You may be able to do this in a windows subsystem for Linux though.
I have wouldn't, I wouldn't bet on it.
I'm not sure.
So it's easy.
You just brew install it or whatever, however you like.
And it's, they've got kind of a picture here, but honestly the picture is not as inspiring as maybe the reality.
So before I tell you more, let me switch over to my laptop, which actually has it running here.
And notice it's got a huge green bar, which is how much battery I got left.
But it also tells you I'm on battery.
It's been on battery for three hours and 27 minutes and it has three hours and 40 minutes left.
Yes, it's a MacBook Air.
It should last longer, but it's doing a lot of stuff.
As you'll see.
It gives you stuff about the health.
Like how many times has it been charged?
176.
What is the temperature?
What is its current energy draw or how much energy actually contained in it and its health?
It shows you power of your machine.
So right now my laptop is using 8.8 watts of power.
The CPU is 1.5.
The GPU is like basically nothing.
I bet you it's mostly screen if I had to guess.
And then it gives you all your processes.
So you can see the Vivaldi is the most significant impact here at like 57% CPU because I have it screen sharing back.
That's why we can look at it, right?
It's got Claude, it's got Firefox, PortKiller, which I talked about.
I had PortKiller open last night to do a CloudFlare tunnel for a project and just didn't shut it down.
And it's like parsing the state of the system a lot to get its things, which is cool.
And it's got this like moving graph at the bottom of your energy consumption temperature.
You can like toggle through these things.
How do I like toggle to like battery percentage over time, watt over time.
There's like all these things you can do.
What do you think?
I think this is great.
I'm going to go install this on my laptop, right?
Right away.
Yeah, it's just brew install jolt-ish.
Let me actually read it so it doesn't give you something terrible if you were to actually do that.
You know what I mean?
Yeah.
It is.
You got to do, you got to tap.
Whatever it is you tap, you got to do brew install Jordan D slash tap slash jolt.
Not just straight jolt.
Anyway, I think it's pretty neat.
So yeah, there it is.
Yeah.
And apparently it can work in Windows.
We've got somebody said just installed.
Oh, Pat.
Yeah.
Pat Decker just installed it under WSL in Windows and it doesn't work.
Pat, thank you for the real time follow up.
That's fantastic.
And to get it installed, use curl install.
Sure.
Yeah, I probably would have done that on Linux as well.
Yeah.
So this looks great.
It's really neat.
Just as like a what is my system doing, even though it's kind of centered around battery,
it's pretty cool actually.
Yeah.
And with laptops, that's mostly what you care about.
It's like, how is this impacting my battery?
Yeah, exactly.
Exactly.
Anyway, people can check that out.
I thought it's a little bit of just a tool rather than a library, but I thought it was fun.
Yeah, nice.
It's not rough.
It wasn't that rough anyway.
It's not that rough.
Yeah.
So let's talk about rough.
Nice, nice transition there.
So we, of course, have talked about rough several times and lots of other things around
it.
But we're going to talk about it a little bit more because Matthias, and sorry, Matthias,
I'm not going to try to pronounce your last name.
So a listener sent us in, said, hey, you should check this out because now you can format because
if you do rough check for it's linting, but it does a lot of formatting as well, or it can, but you can also do Ruff format.
And so both of those things you can now point those at, I think it's for both of them, can point it at markdown files.
So yes, yes.
And so for, I mean, it's not just documentation because I'm like, we're writing books and stuff like that with markdown.
So I'm definitely going to point this at some book type code and blogs, of course, lots of blog, shortened in markdown.
Anyway, so some of the cool features of this is that you can also turn it off for parts of it.
So if there's like, if you want to show an example of bad code, you probably don't want rough to reformat that for you.
So there's ways to turn it off.
That's interesting.
Don't do this.
And it gets fixed.
You're like, no.
Yeah.
So there's some tricks around it, though.
So for turning it off, there's a format off and on.
And apparently there's like some other, there's something else that you could turn it off and on.
But like, if you're in the habit of just doing code blocks with just three ticks, it's not going to cut it because it's looking for what it's looking for those.
What are those identifiers?
I don't know what you call that.
The little thing after the three ticks to tell you what language.
Yeah.
Whatever the language designation is.
Yes.
But there's a few.
They do PY, Python, Python 3, PY3.
Interesting.
People are still using that.
It probably does that because it needs to know what language it is to decide how to format it.
Yeah.
I mean, it shouldn't try to format like, you know, Rust as if it's Python, I guess.
Yeah, exactly.
Also, these semicolons are unnecessary.
We took them away.
And the way rough works is through pulling it into the abstract syntax tree and outputting it again.
So it has to actually be valid Python.
If you have invalid Python that won't parse, it's not going to figure that out.
So it won't, I don't think it errors.
It just doesn't do those.
So if you're going to get it.
Anyway.
And there's a preview mode.
That's kind of neat that you can say, hey, what would you do for this?
But, you know, frankly, I would just have it in Git and let it go.
And then you can do the diffs to see what it did.
So cool, cool thing there.
And I'm pretty excited about that.
One of the interesting bits is that it also does PYI files.
So it will format.
What are those?
Type files?
Type files, yeah.
Yeah.
So just a fun little tool.
The caveat is this feature is only available in preview mode.
And I didn't know what that meant.
So I had to look it up.
So preview mode means it doesn't mean you have to install anything different,
but you have to enable preview mode by setting in one of your settings files.
You have to say preview equals true.
Oh, interesting.
Like your ruff.toml or pyproject.toml.
Yeah.
Or you can pass --preview in the command line, apparently.
So you get that.
Or you could download the source and recompile rough and then make that the default.
Sure.
Just kidding.
Yeah.
There's a thousand ways to skin the cat as it goes.
Please don't skin my cat.
As morbid as that statement may be, there are many ways to do it.
It's terrible.
All right.
So let's go to the cloud.
To the cloud.
So I want to talk about GitHub actions.
So here's the deal.
I have some GitHub actions.
Maybe they format my markdown.
Maybe they run my tests.
Maybe they check against other things.
Maybe they integrate with who knows what, right?
There's a ton of GitHub actions.
So how do you do that?
Well, maybe you create a feature branch and you commit and then you wait for your project
to not be busy and then GitHub runner to pick it up and run it.
And then you pay your fee for the GitHub runner to run your thing while you're waiting.
Your computer's idle.
You could use jolt to see like that.
It's not doing anything.
So there's this thing I found called act.
Neck, neck, toes, slash act.
So neck, toes is the person create.
It's a little bit popular.
69,000 GitHub stores, 2,000 forks.
Wow.
Have I heard of it?
Have you heard of this?
I think.
Maybe.
Rings a bell.
Okay.
Maybe we even covered it like 10 years ago.
Anyway.
So the idea is you can run your GitHub actions locally on your computer using nearly the same
infrastructure.
So you don't have to pay for them.
You don't have to wait on them.
You don't have to.
One of the problems is you've got to make a commit.
Like maybe you're not ready to commit.
You're like, I actually want to see what the GitHub action result would be before I do commit
it.
You know what I mean?
Yeah.
So what you do is it, this thing reads your GitHub workflow and your environment variables
and all that based on what you have set there.
And then it uses a local hash runner.
So basically sets up a Docker thing to run.
Right?
So if I scroll down here a little bit, it says reads those, then it uses the Docker API
to pull the necessary image to find any workflow files.
You can see the little thing running right down below.
And then sets up the execution paths.
Then it runs each container based on all the stuff that you have set in your action.
Right?
So it just basically runs here and off it goes.
You can see like it gives you little like reports on how that went and so on.
Did they pass and so on.
So I think this is pretty cool.
Yeah.
I think it's cool too.
I wonder if there's something like this for GitLab.
Hmm.
GitLab Act.
I wonder how similar the actions are.
Like I've not set up GitHub Actions very much on GitHub and not at all on GitLab.
And so maybe if they're basically file compatible, it's good enough.
Because this doesn't actually use anything about GitHub either.
It just says what are the Docker images and commands and stuff like that.
Yeah.
So it may work.
Yeah.
So this is definitely cool.
It is kind of a pain to try to debug GitHub Actions, figure out what's going on.
So yeah.
Yeah.
Definitely check this out.
Awesome.
So what is the story on the extras?
Do we have extras?
I just have one.
And I didn't before we started the show.
I know.
I thought you had no extras.
But now I'm hearing you have extras.
What's the deal?
There were none in the notes.
So I'll just do a quick one.
So you brought up the book Lean TDD at the beginning of one of the books.
Yeah.
One that's actually a book.
So I had started.
Yeah.
So Lean TDD, I just want to give a status update.
Not much has happened.
There's a lot happening, but it's all up here.
So one of the reasons why I released it.
So the first draft is done and it's out.
And it's actually not really a first draft.
It's probably second or third that's released.
But I'm reading it now.
And I definitely want to change the first couple chapters.
And I know it's a dry subject.
But if I'm having trouble reading it because it's a little dry,
now I should be selling it more.
I'm like, no, it's super exciting.
No, it needs to be more exciting than it is.
Because I am excited about the topic.
But the initial start of it is a little rough to get started in the book.
So I do want to make it a little more exciting.
And so there's been a lot of notes, but it's all been on paper.
So I am still working on it.
It doesn't look like that.
If you've grabbed a copy, thank you.
It's helped motivate me.
I've had quite a few people grab copies.
And things are moving.
It just doesn't look like it from the outside.
So anyway.
And Mike, the man, says, you're going to write lean BDD?
Well, behavior-driven development and acceptance test-driven development
are covered in the book.
I kind of lump those together as well.
And Mike, if you're a BDD kind of person,
I'd love to talk with you more about it.
That's my extra is not much news.
OK.
Yeah, very, very cool.
Neat.
I know how this goes.
You're like, ah, it's good.
They're like, no, no, no.
I've got to do this again.
I have this project.
I rewrote it three times already.
It's driving me crazy.
But I think it's good now.
It's finally the third time.
All right.
Savannah Ostrowski says, stoked to share that the steering council has accepted PEP 814.
What is PEP 814, you might ask?
Well, that means winter is coming.
Winter is coming.
Why?
Well, because PEP 814 is frozen dicked.
Frozen dicked.
That was a bad joke.
No, it was so bad it was good, I think.
No, anyway.
The idea is that we've got frozen set.
We've got other types of frozen containers and data structures.
But we didn't have frozen dictionary.
So the idea is it's a read-only, right?
So you create a thing.
You want to be able to return it from a function or share it and have an absolute guarantee that people are not changing it, right?
Adding or moving items, keys, and so on.
I don't think that really applies to stuff referenced in there.
So if you put a list as a value and then you go and, like, get the point of the list, you probably can still change it.
But, you know, like, I guess it depends.
If you fill it with only other frozen stuff, it's frozen all the way down.
But it's really cool because it allows better concurrency.
This is something we're going to be paying more attention to in the future as Python T starts, you know, free-threaded Python starts to become a thing.
You're like, well, I hate all this locking we have to do in these race conditions.
Like, well, if you can't change it, you don't need to lock on it.
You know what I mean?
So that's very cool.
I don't want to add any more than that, but it will be in Python 3.15.
Now in the audience, Kiva Birb says, oh, that is excellent.
We'll definitely be using this all the time for default prams.
Oh, you know what?
That is a really interesting idea for default prams.
Yes.
I hadn't really considered it there.
Yes.
Yeah.
Okay.
And then a little bit of Django.
Also, please wear pants.
I guess.
It's just, I don't know what that reference is, but.
I don't either.
Okay.
So Jeff Triplett posted on Mastodon in response to Paolo Melichori saying, I just published
the first article in a new series of my blog, Django ORM standalone.
And Jeff and Mario and I were just talking about this that same week.
And like, would it be cool if you could use the Django ORM without Django?
Right.
So maybe I've got a Django project, but I also have a little library I just want to run
and also talk to the database.
And I don't want to have a separate data access layer.
I just want to have my models and a script and I don't care about the web side of things.
So basically that's Django standalone, right?
Because any large project is going to have to start to have like different flavors and
utilities and aspects, maybe daemons.
Like they don't all have to run the web app, you know, they all shouldn't run the web app.
So anyway, give it a little shout out to this article here.
Yeah.
Or even like if you want to do a FastAPI plus using the Django ORM.
Yeah, exactly.
If you want to use the ORM on another web, like maybe you really love the Django ORM,
but you also love Flask.
Well, here you go.
Let's do it.
Hmm.
That's exciting.
Okay.
I talked about command book, this sort of long running, this, this home for long running
terminal commands, like commands.
I want to run for three hours, like start up the web server and the daemon and the tail
and just leave it.
And if I accidentally close my terminal, I don't want them to go away.
I don't want to clutter up my terminal.
Right.
Fun little app.
There's a free version, free aspect and paid aspect, personal license and beyond.
But I finally got around to writing up the motivation of like, why does this exist?
Here's, here's how it works.
Here's why I created it.
And so on.
So I linked to the blog posts.
It says a five minute read according to my own website.
So you should do that.
Plus like a little how to guide and everything and make a book out of it.
It could be a command book book.
A command book book or command book squared.
I mean, let's go.
Which was, how do we want to do this?
Yeah.
How do we want to do this?
All right.
I think we're ready for our joke.
And this joke is called plug and paste.
Is it a plug and play?
Do people still talk about plug and play anymore?
I don't know.
It was like windows 95 was such a thing.
Yeah.
That was like the big thing.
Like now with plug and play, you can just plug in the USB thing.
Anyway, sort of like that.
So here's the joke.
And let me set the stage.
Like, you know how people say, oh, we only use 20% of our brain or 30% of our brain.
And think how incredible humans could be if we could harness all of the power of the brain.
And I'm not really sure I really buy into that.
Like, do you really need to be using the running part of your brain and the part that controls thinking and the part that controls language?
Like that doesn't necessarily add capability.
Anyway, so that's what it's based on.
So there's this person sort of looking up like, whoa, what if we could use 100% of our brain?
And I think it's Morgan Freeman says, at work, a customer just tried to copy a document, unplug the mouse, and plug it back into another computer and paste it.
Maybe we got a little more foundational stuff to work on if we could use 100% of our brain.
Yeah.
What about 10%?
Can we use 10%?
Yeah.
You know that whole 100% of your brain thing is not real.
I can totally see that.
People were saying, on the average, people only use a small percentage of your brain.
That's not true.
We use all of it.
Yeah.
It's too costly to feed our brain if we weren't using all of it.
I mean, not everybody uses all of it.
I would say there's a range of engagement throughout society.
I think they're using it all.
They're just like, most of it's just doing reruns of The Simpsons, I think.
Well, yeah, yeah.
That's probably true.
I find that when somebody, if the photons from TikTok hit a person's face, it's like a beam that shuts down about half of the brain.
Like as the photons just strike the skin.
I was listening to, we're tangenting, yeah.
But I was listening to a podcast and there was an ad for TikTok on the podcast advertising how safe it is for kids because of all the safety features they've got.
And I'm like, that's insane.
It is insane.
So anyway.
Yeah.
That's a whole rant we can go on.
But I think that, I think like TikTok and this short form stuff, it's like really hurting people's attention span and ability to engage for extended periods of time.
Just watching my own kids.
Yeah.
I'll have to find the article.
I just found out that, that my wife found an article about how Gen Z is the first generation that's got a lower IQ than their parents.
I don't know.
But, you know, on average.
I would say maybe the tests are just given wrong.
Could they be given, the IQ test, could it be given as a TikTok series instead of, and then it would be, it might actually, they might crush it.
Seriously, I think it's like, it might not be an intelligence.
It might be a concentration thing.
It could be.
Yeah.
I don't know, but it's not, it's not a great sign.
Anyway.
I don't know.
How do we get into this?
I don't know.
How do we say your brain?
All right.
We're going to go use 100% of the brain to get this podcast ready and shipped to the world.
Everyone, thanks for being here.
Thanks.
Bye.