Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 424, recorded March 17th, 2025. I'm Michael Kennedy.
And
I'm Brian Okken.
And this episode is brought to you by us. Check out all of our things, courses at pythontest.com,
talkpython
.fm, all the places. If you want to get in touch with us, social media is probably the best place. I have a couple of things sent to me on social media. I don't know about you, Brian, but a couple that I'll be covering today.
Yeah.
So that's always fun.
Find us on blue sky, find us on Mastodon.
It doesn't matter.
Doesn't matter what server you're on.
Everyone talks to everyone on Mastodon.
So you can find the links for all those at the top of the show and we're refining and improving our newsletter format.
It's getting better and better and more valuable.
I think it's got a nice little TLDR, grab the links, grab the joke and then dive into it if you want.
And yeah, so.
Buy them by SET-FM, smash that newsletter button and get signed up.
I
think people are getting a lot of value out of it.
It's really nice, Brian.
Yeah, I think, I think it's great.
Um, also, yeah, we've mentioned this before, but I really love the, the, what you should know if we cover a topic that you're, you're not quite understand.
Don't not quite, don't quite understand what that topic's all about.
You can check some of the background links in those.
So, so that's cool.
Absolutely.
I totally agree.
And thank you to our Patreon supporters as well.
Now,
let us begin.
Let us begin, Brian, with your first item.
What you got for us?
I, I have, a weird quirk around rounding in Python.
And actually this is just apparently normal.
This is a feature, but I didn't know about it or I had forgotten about it.
So, we're linking to the weird quirk around rounding in Python.
And the weird quirk is really just if your number ends in 0.5, like 1.5, 2.5, things like that.
If you round it, it'll become even.
It always goes even.
So I didn't know this, but apparently it works better that way.
And that's part of the IEEE standard 754.
So 0.5 rounds to 0, 1.5 rounds to 2, and so forth and so on.
Negative numbers also.
So negative 1.5 will round to negative 2.
So did you know this?
I did not know this. I do not accept this. I don't accept this as a mathematician, formerly, but by lots of training and education, I do not accept.
So what do you do?
You always round to even numbers.
So normally, like when I, it's been a long time since I've been in primary school, but isn't the, isn't the like hand math thing that you round up if it's like 1.5?
It goes to the closest whole number.
Wait, but That's it.
At.5 there isn't a closest, it's right in the middle.
Ah, I see. So if it was.1,.5, 0,
0, 0, 0, 0, 0, 1 It goes up, yeah.
It goes up, I see. So it's basically deciding at the...
Where does the tie go?
The decimal representation of the cutoff. So 4 point, in my world, 4.999999, non-repeating but as many nines as you care to put, goes down. And.5 and above goes up.
If it's 1.4, you round down in regular math, right?
- Yeah.
- If it's 1.4999,
you round
out.
If it's 1
.4999999, as many as you want.
- All the extra decimals don't matter.
It's only with the actual, just one, if it's.5, zero.
All zeros.
So this is like 0.5, 1.5.
That's a tie, then there is no closest integer.
So where does it go?
And I thought in math that we always just like, half goes up. Yeah,
that's what I thought too.
But so it doesn't it makes it make and there's reasons around it because if you if you average you want the average to be like if you averaged a bunch of these you want it to be five like you have a bunch of random numbers like
zero
through ten or one through yeah I don't know it's gonna you want it to be five, but it's not. It's a little bit off. So this standard makes the average work. However, if you really want the normal way that we've been taught in grade school, there's a decimal feature that you can have it be round half up. So you can make it work normal, but apparently it's doing the right thing. You just didn't know that was the right thing. So
anyway.
It's a feature.
It's also known as banker's rounding or Dutch rounding, apparently.
That's learned something new there.
And being that Guido is Dutch, maybe that has something.
I don't know.
So just if you're rounding numbers, you should be aware of this.
That's it, really.
So, yeah.
You want an easy
way to put it back to like grade school rounding?
All you have to do is just say int of your number plus.5.
Int plus.5.
>> Okay.
>> So if it's 1.5 plus 0.5, it's two as a decimal, but then you turn it to an int, it's two.
>> Right.
>> So it's basically just a truncation.
Yeah, it truncates it.
The 0.5 is like, okay, bump it up.
If it's 0.5 or above, bump it to the next number, then chop it off.
>>
Weird. I wonder why we do it different.
Anyway.
>> I don't know.
Interesting.
Thanks, Tom, for the article.
Lots of stuff.
>> Okay. What do you got for us?
>> Well, I've got some pretty interesting things here in terms of Python performance improvements.
So Brian, are you a fan of recursion?
>> Not really.
>> I'm not either, but I was against my will forced to take two programming courses in college.
One was Fortran and one was Lisp.
In Lisp or Scheme, it's all about recursion, right?
>> Yeah.
>> Like there's no, the way you do loops is to do recursion and so on.
And in certain, not in Scheme, but in other languages, you can pretty quickly run out of stack space by doing recursion.
And you might have gotten a stack overflow exception, you know, and--
- That's the name. - We know about stack,
that's the name, like, what does this even mean?
So there's ways to rewrite that at the runtime level to say the reason you run out of stack space is every function call gets its own new stack frame allocated and all of its locals and all that kind of stuff.
What if we could just say, reuse the existing stack space, grabbing some of the local variables that are being passed and just kind of reusing them long as you find a way to save the data to kind of go up the stack when you hit return or something like that, right?
- Yeah.
- And to my limited experience, that's what tail calls do.
So if you've heard about adding, like doing tail recursion to make your recursion much faster, that's because not every single, basically every single step in the loop, you don't have to recreate the function frame.
So
that's
really good.
And so the idea here, the news is that the faster CPython project has added tail calls to Python.
This is not exactly the same thing because it doesn't exactly have to do with recursion.
It has to do with stepping through the bytecode instructions.
Okay.
So traditionally there've been different ways in which Python does that.
The article from LWN.net says, "Python's Many Interpreters." So when you run a Python program, it converts it to bytecode.
Yes, we know this.
It says, however, there's actually a couple of ways in which this could be executed.
There's the switch-based interpreter version, and then there's a go-to, what do they call it, the computed go-to statements version, which they say is a micro-op interpreter.
This is relatively new.
Like you maybe have seen the giant switch statement and by giant, I mean, 3,500 lines of C switch statement, single switch statement within a for loop that says for each, you know, go to the next byte instruction, switch on what it is, do that, right?
That has still stuck around because certain compilers don't support what's called a computed go-to statement or dynamic go-to statements, which sounds terrible, but it's a compiler level thing, not a human
code
level thing.
My go-to statements are bad for people, but they're not necessarily bad for compilers.
So the reason the old one is around is some of the compilers can't take it, but the new one's a little bit better.
So the idea here is that, I'm going to give credit to it, so Ken Jin, member of the Faster Steep Python project has merged a new set of changes that have up to 10% actually up to 40% performance improvements on an average geometric mean of 10% improvements, which is pretty awesome.
So the idea is that we can change the way that that go-to that computed go-to based interpreter works using tail calls. So kind of like I described for recursion, it's reusing the stack frame as an optimization. So modern compilers like Clang and GCC can do tail call optimizations optimistically, but until recently they weren't 100% guaranteed. You know, like some compilers have that level like -01, -02, like you put it up too high and stuff starts to break, you're like, "Huh, that's weird." You think that would just work, but right. And I think that's kind of the case is here. And apparently it's more stable so they can rely on it. So basically there's this new interpreter.
And as the article points out, like it might seem crazy to add a third interpreter to Python, and it seems like a lot of work, right? But if you go down to the bottom, it says somewhere that Jin's change is only about 200 lines of Python code, which generates the interpreter and generates the code for the tail calling version. So it's actually not very much effort at all. So what it does is it'll say like, does your compiler support this faster version of behaviors? If it does, we'll give you a faster Python.
I think that's pretty awesome.
>>
Yeah. I think.
>> Yeah, I think so.
>> If it works.
>> Yeah, as long as it works. So this is already merged into Python 3.14, which is pretty excellent.
It does say, look, if you're on an older build of Python, or you're building Python yourself with an old compiler, you're going to get the slow version.
Like, okay, if you care about faster Python, compile it with modern compilers or download one with a binary.
I bet you UV is already on top of this, you know what I mean?
So
3.14 already has this in it?
That's what it says.
Okay, cool.
It says merged.
Jin's work has been merged and should be available to end users in Python 3.14.
Expected Halloween 2025.
But what's really interesting here is Jin measured the performance impact of the change as a 10% on average, but up to 40% on some benchmark speed improvement, and then framed it this way, which I thought was really interesting.
the speedup is roughly equal to two CPython releases worth of improvements.
So like 3.11 to 3.13 in this just 200 lines of Python code, which is amazing.
>> That's pretty cool.
>> For example, CPython 3.12 roughly sped up by 5%.
So, year over year sort of thing.
So just this one change in 3.14 is going to be pretty mega.
It's awesome.
>>
Yeah.
Yeah, no, this is really cool.
When I first heard about this, I was excited that maybe we get tail recursion optimization in Python, but we don't.
I'm okay
without it. It would be good to have.
But let's not encourage them. Now, I use recursion sometimes.
Look, if you've got hierarchical data structures, recursion is magical, right?
It's like it exactly matches what you do with that hierarchy as you kind of traverse it.
But in life, though, I think I've only used recursion and tail optimization in college.
But
I
don't do sort of, because I don't do recursive sort of things very much.
But that's all right.
>> Yeah, yeah.
Andrew out there points out, "I was overly excited to see this when I first saw these headlines thinking Python itself was getting tail call optimization.
Very nice nonetheless going to motivate me to get Clang builds working with the required options." Yeah, absolutely cool.
Like I said, I hope the UV folks are on this because uv venv and we just get 10% faster.
Like let's go.
>> Well, yeah, and actually I think that because of UV, we're getting more people trying new versions of Python faster because all you have to do is create a virtual environment and pick it.
>> Yeah.
>> And you get it.
>>
--Python 3.14B or whatever, however you specify it.
>> Yeah.
>> Absolutely.
All
right, back to you.
>> Okay. Well, let's see.
We've got something from Rodrigo.
Rodrigo and I'm, anyway, Rodrigo from MathsPP.
Math, that's okay.
I'm gonna have to work on this one.
But he puts out a lot of great stuff.
He's writing about Python and very active on Blue Sky.
And I think I don't, maybe somehow I missed this.
This is, he's using translate and make trans together.
He said, "Don't use the method replace "to remove punctuation from a Python string.
"Use translate instead.
"It's much more efficient and more general." and his example, which I had to like parse a little bit to figure this out.
So basically like his example of hello world with a comma and an exclamation point.
We want to strip that all the punctuation out.
How do you do that?
Well, you can use make trans, which is translates from one string, like some things in a string to another set of characters in a string.
It's kind of a weird function, but he's giving it nothing.
So the translate from and to are empty.
But he's also giving the third parameter is stuff to just strip out.
The way make trans does that is it translates a takes all of the characters in the third argument and replaces them with none, and those just end up getting removed.
For the third character, he's using string.punctuation.
He's creating a translation table that all it does is remove punctuation, and that's what we want, passing it to trans, and you get a string.
And it still seems like maybe there should be an easier way in Python to do this, but that's pretty cool.
I like it.
So he also has an article that talks about not exactly this thing, but he's got an article about string translate and make trans methods if you want to dive deeper into those.
Or you can just use this little trick.
So-- Very interesting.
News to me.
It's a little bit like when
I learned that strip, if I have like str, if I want to take str off of the word string and just leave ing, right?
If you say L strip and you put the string str in there, I always thought it would find that string and take it out, but no, that just takes the S's and the T's and the R's, so R2S would also be right.
So there's remove prefix and remove suffix and stuff like that.
And this one's a little bit like that, like, huh, it didn't quite do what I thought, but I, apparently there's another way.
>> Yeah. One of the interesting things about MakeTrans that always throws me is, it's an ordering thing, so you go from and to, and it utilizes the fact that strings are iterable.
That's not something I normally think about unless I'm, I guess when I'm parsing stuff, when I'm parsing a file or parsing a line, I utilize the fact that they're iterable.
But normally I don't iterate over characters of a string.
That's seems like maybe that's too easy to get wrong.
But anyway.
>> Yeah, perhaps.
>> All right. What you got for us next? Oh, we're done.
>> Well, I got extra, extra, extra, extra.
>> Extra, lots of extras.
Yeah, because we had some short topics.
So let's get some
extras.
>> So first of all, this was sent in by several people including Owen Lamont.
Thank you for that.
And this is a nine minute video of animation versus coding.
And it's the weirdest-- I don't even know what to make of it.
It's an insane amount of work that these people put into it.
I'll just play a little bit of it as we're talking, Brian.
And so the idea here is it's like an animation of somebody writing code and seeing how it interacts.
And then the computer comes alive, and there's a battle with the computer.
The computer will fire up Turtle and all sorts of stuff.
And it ends up in the end, like creating AIs to run around and doing all sorts of stuff.
And I think spoiler, I think the person character wins by like controlling the computer with AI.
I'm not entirely sure the outcome.
I totally forget, but it features pie game, pandas, pie torch.
I mean, it's, it's nuts.
So anyway, if you're looking for some entertainment, that's pretty cool.
I got to watch that.
It's a 10 minute video though.
Yeah.
If you're eating lunch or something, you're like, I need a little break from programming.
Let me watch a video about programming.
I can do that.
Yeah.
All right.
Next up in the news, I brought this up more as a parallel, as a other thing, other places are doing this too.
Right?
So one of the concerns and benefits of a lot of these new tools is they are written in Rust for Python, right?
So why is UV fast?
Mostly algorithms, but also Rust.
Why is rough fast?
Mostly Rust, probably also algorithms.
You know what I mean?
Like things like that.
Right.
Um, why are we running our website on Granian, Rust, Hyper, all those sorts of things.
So the folks over at TypeScript, Anders Halsberg, the creator of it and the Microsoft team just made TypeScript, which is a typed JavaScript thing.
And I believe the runtime behind it as well.
I think there's some kind of runtime.
I haven't done
much
with TypeScript that way, but certainly like it's compiler and it's language LSP for editors and stuff like that.
10 times faster by rewriting it in Go.
>> Oh, geez.
>> That's interesting. They said, "Look, we tried a bunch of different languages.
We tried Rust, we tried C, we tried Go, we tried, I think, Zig." They mentioned a lot of languages.
They said, "Look, Go allows us to align the memory stuff as you do in native languages." Like align the memory structures exactly write for the compiler and stuff like that or something.
So anyway, I know a lot of people listening also do JavaScript and TypeScript stuff.
And I think it's, you know, here's another 10 minute video to watch.
That's kind of interesting.
I think 13 minutes technically.
But so that's like the drop loss.
Everything that uses TypeScript would be faster then or.
So that's what I'm not.
There is some kind of runtime that they're doing something with that they rewrote.
Like TypeScript used to compile itself with TypeScript.
But there's also something that runs that does the language server.
I feel like it's a little like node, but like I said, this is far, I'm far out over my skis at this point.
I think when you talk about stuff that runs it, mostly that's in the browser.
And then that's going to be just the JavaScript engine.
Cause the now Go-based transpiler compiler will compile the JavaScript and then it's run natively, natively, you know, anyway, pretty interesting.
I thought it was worth throwing out there.
Cause it's like, Oh, Python's getting overrun by Rust.
What's what in the world's going on?
I'm like, this is a trend of more places, not just Python.
That's what I kind of want to point out here.
They made different choices for different reasons, but it's still pretty interesting.
Okay.
Thanks for showing me that YouTube.
All right.
I, this next section I entitled Firefox lies.
So Brian, it's very exciting.
This weekend was the first formula one race of the year, and they've going to have something like 23 more.
Very good.
And it was amazing.
If you haven't watched it, I won't spoil it, but it's, it was one of the best formula one races I've watched in a very long time.
It was full of drama, full of interesting things.
It was good.
And this, so what does this have to do with Firefox?
So I tried to watch it.
I subscribed to F1 TV so that I can watch all the, all the races, all the replays, all the qualifying, all that kind of stuff, instead of getting cable, which is a complete rip off, you know, pay 200 bucks a month, I paid like 80 bucks once and I watch all those with replays and whatever, right.
I tried to watch that with Firefox.
Do you know what it said?
Your browser is out of date and unsupported.
You cannot watch this website.
You must go away because you don't have Chrome basically.
And I said, huh, I seriously doubt it.
I seriously doubt that Firefox won't work.
FUF1 I said,
and
I said, no, we're doing it.
We're watching it in Firefox because I have all this blocking turned on in my other favorite browser, Vivaldi.
Right.
And I don't want to turn off the blocking and stuff.
So I have like kind of my bare Firefox is the, the one that allows all the badness through so I can watch stuff that, you know, Peacock and F1 and so on.
So when they say you can't watch them, like, no, I can watch it.
So what I did is I, I put the link, I'll link to how you do this, but I just went up and just told Firefox it's user agent is the latest version of Chrome.
Hence Firefox lies.
Went back.
I went back to, F1 TV.
Welcome.
Which, which replay would you like to watch?
Boom.
Perfect.
Played perfectly.
There's nothing wrong with Firefox.
The people are just too lazy to test against it.
And so they're like, well, you got to have Chrome.
Like, all right, fine.
I have Chrome.
Oh, look, it works.
This is the same reason that Vivaldi works.
Vivaldi, you cannot know like the market share of Vivaldi per user agent.
Like, some of those sites that track user agent frequency and stuff.
Yeah.
They just, because they just say the same thing.
They just say my user agent is the latest version of Chrome.
So that it works because if everybody had to also say, we also support Vivaldi, It would say crap like that all the time.
- Yeah.
- And so if you love Firefox or any other browser really, but I have instructions for Firefox and you run into those problems, just make it lie.
I'm really, really loving Zen.
We talked about that a few times and I'm considering making my Zen claim to be the latest Chrome as well.
- Yeah, that's one of the reasons why I like Vivaldi as well, because especially in corporations, a lot of internal tools, they don't wanna, I mean, that's a lot of work for internal tools to test everything.
So they just usually test against Chrome.
And so with Vivaldi, I can just use internal tools just fine.
- Yeah, it's indistinguishable.
It doesn't know.
Why wouldn't it be?
It's literally the same embedded engine in the terms of Vivaldi.
It literally is Chrome.
It just doesn't have all this scumbaggery to it.
- Yeah.
- Yeah, all right.
This is extra, it's getting long, real quick.
All right, Startup Row.
Startup Row applications are open.
Does your startup qualify for Startup Row?
Here's some criteria.
Use Python.
Your startup is less than 2.5 years old.
You have less than 25, fewer than 25 employees, et cetera, et cetera.
You will come to the conference and so on.
This is a really cool program.
And if you have a startup and you want to get some awareness, consider applying to this.
So this is,
this is at PyCon on Sundays.
There's there's a, they, they take away all of the booths and everything like that.
And then we have, we have a couple of rows of startups that you
can.
Yes.
I think it even might be Thursday through Saturday.
I think it might be during the expo.
Oh, during the expo.
It was in a corner, it was in a corner, but it was, I think it was during the expo.
Oh, right.
Yeah.
You basically get a booth as like a $10,000 equivalent booth as if you were another advertiser there, but it's to promote your Python based startup.
So people should check that out.
I actually did an interview two years ago, coming up on two years ago, called a stroll down startup lane, where I went and interviewed all the people, all the different startups, like 10 minutes per startup or something like that.
Nice.
Yeah.
Ooh, last, last of the extras.
I am publishing a book, Brian.
Wow.
Neat.
Yeah.
Thanks.
Talk Python in production.
So the subtitle is a cloud agnostic guide to building, scaling, and managing your own Python infrastructure.
So I've talked a lot about different ways we're doing different things with infrastructure, but here's a book, it's about 250 pages.
That goes into all the details of like how you can run efficient, high performance, but not complex, not expensive Python infrastructure.
And you can buy, you can read about the first third of it online.
And it says buy the book, but you can't quite buy the book just today.
I'm still trying to get it all ready to go.
So right now you can subscribe to get notified when you can buy the book.
And in a week or two, you will be able to buy the book at Amazon and probably Gumroad is what I'm thinking.
Okay.
I like Gumroad.
Yeah.
Anyway.
So the link to that is in the show notes
and
hopefully people will check that out.
Cool.
Yeah.
All right.
That's it for my extras.
You got any extra extras?
No, I wanted to announce the changes to the course, but I, but I'm still working on it, life getting in
the way.
So yeah, I hear you.
Well, until then people don't necessarily have to test, right.
They don't need work on your testing.
Yes, they do.
Yeah.
No, they can just test in production.
So the joke is a Star Trek one.
This comes to us by Greg Matiola.
Thank you.
It says, as Goron says, we will test in production and die with glorious honor.
And it's got like a cool little meme over a Star Trek Klingon character.
Yeah.
But it's usually your customers that will die in glorious honor.
They
die first and then you wither.
Yeah.
Okay.
Yeah.
So you, what I'm hearing is you're saying you don't actually support this advice.
I don't.
But I, but there is a certain car company that seems to have pieces of their cars flying off.
I think, does it look a little like a spaceship?
Yeah, it does.
And apparently they just glued some of the stuff onto the side is some of this.
Anyway,
you
know, I, I was, in
Nashville with my kids the last summer and we were driving along and our rental car, which was not one of these spaceship.
things. The, the, there was apparently a, the thing that goes on the column has like a fancy cover, like a bodywork. Yeah. The, the columns that hold up the roof and along the windshield. And it just peeled back, ripped off and started whacking against the car on the highway. And this was on our way to the airport. So one of my kids had to reach out and hold, hold the body work in place for about 15 minutes. And she was, she was kind of done holding the bodywork in place. So we got to to the airport.
- That's crazy.
- So bad, so bad.
- Did you get charged for the damage to the car?
- No, I kinda like mushed it back.
I said, "How's the car?" It was fine, that piece is a little bit loose.
You might wanna check it, bye.
- Bye.
(laughing)
Yeah.
- No, it was okay.
- Anyway.
- Anyway, yeah, test in production.
- Test in production.
No, don't put test in production.
Test before production.
- Absolutely.
But do, do listen to the show every week.
We'll be back next Monday at 10, probably, most likely.
- Tell your friends.
- Until then, thank you everyone, bye.
- Bye.