Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 457, and it's being recorded on November 11th, 2025. And I'm Brian Okken.
And I'm Michael Kennedy.
Wow, nowhere. Oh, it's 11-11. It's corduroy day. I totally forgot to wear corduroy today.
I love it. Is that because the vertical stripes? Yeah, yeah. Vertical grooves. Yeah, yeah. I love it. I have no corduroy on either. We missed the opportunity.
some stripes on your, it's not corduroy, but your sweater.
Yeah, almost a sweater, almost pulled it off.
Anyway, we'd like to thank everybody that supports us through going to doing Talk Python training or the pytest course, Patreon supporters or people that have bought our books. We really, really appreciate all of the support and it keeps us going. Also love to hear from people on Bluesky, on Mastodon and through email. So you can go to the contact us on pythonbytes.fm. And there's the links to all the Bluesky Mastermind, all those things to get all of us.
We actually have a couple items today from listeners. So feel free to send us things. If you'd like to join the show live, and even if it's on a weird time like this week, you can find out when it's going to happen next by going to pythonbytes.fm/live. And, you know, jump on and talk with us while we're recording. It's fun. Also, you don't need to take notes because we're going to send you all the links.
Well, they're in the show notes, but we'll also send them directly to your inbox if you sign up to be a friend of the show and go to pythonbytes.fm and sign up for the newsletter. I think that's all of the stuff. So let's jump into the first item, Michael.
Let's talk about it now. I want to talk about something called HTTP tap at HTTP tap.dev. Now this one, it's a little bit like HTTP pi, HTTP pi, I don't know how you really pronounce that correctly, which is my go to anytime I need to test something on the terminal or that sort of thing. HTTP pi is because, you know, it's like curl or whatever, but it gives you lots more stats, gives you more information. And this, This is a little bit like that.
If you wanted to go into, say, your Chrome DevTools or something and say, "Hey, I'm requesting this page or this URL or this API endpoint. It's a little bit slow. It's a little bit funky. What's going on? Where's the problem?" - Yeah. - If it's getting hung up, is it connecting to the server or is it the backend app server, like Grinny and whoever is not responding? So that's what this is all about. And it's built, I believe it's built with rich or textual.
I can't remember how far down the Will McGugan train it goes, but it definitely is built on some of those. Built with Python, although that's not necessarily that important, right? It's just I guess it's easier to make improvements to, but it's more just a tool that anyone doing web stuff with Python might be interested in. And I pulled up a little example of just asking Talk Python, acptptap, then talkpython.fm, and it says, here's the analysis.
And apparently there's only one step, maybe if there were redirects or something, It would show multi-stage flows, but there's no redirects, so there's not. It shows you the IP address, the TLS version, the cipher, when the certificate expires, the status, the size, the server. It gets all of that stuff right, which is pretty cool. Then it has this waterfall-tiered sort of diagram. It says the request timeline. It took 29 milliseconds for DNS to figure out where the heck that was.
I've been on vacation. I haven't been going to the website. So I had to go get it from the internet. And then it took 80 milliseconds to connect to the server. By the way, it's about 80 milliseconds ping time. So you got to keep that in mind when all these numbers, right? Like that's East Coast, West Coast, US, 2,500 miles. So connect 80 milliseconds. TLS took 130 milliseconds. So if you ever see your browser doing like keep alive type of stuff, that's a big savings right there.
That's almost 200 milliseconds savings if it doesn't have to keep doing that over and over, right? So that's pretty nice. And then you can see it's actually sending the request and waiting for the response. So it goes out, comes back, takes 170 milliseconds. Again, ping time in there as well. And then the transfer is a whopping 4.3 milliseconds. So this is pretty cool. A really quick view of just seeing what's going on, right, Brian?
Yeah, actually, I love that. Very useful, especially if you've got some lag issues or some part of your website that's a little slow. you can look at what's going on. Is it DNS? Is it the transfer? Where's this delay coming from? I mean, it's not super fine-grained, but this is pretty good.
Yeah, well, there's just, yeah, for sure. And there's a lot of stuff involved, right? There's, like you said, the DNS might be taking forever, which could be part of the problem, or who knows, right? There's just a lot of things. So really neat to see this little UI built in Python.
Yeah, and I guess we have to say it. It's always DNS. It's always DNS. I mean, that's... It's not always DNS, but yeah. Anyway.
Yeah, but often.
Often. No, I think this is great. This is cool. I've got actually some side projects that I've got some weird speed issues, and I don't know why. And even just looking at some of this stuff, help out to figure out where to start debugging.
Yeah, you can get some of these types of things in the dev tools and browsers, but this is really nice. It's visual, it's colorful, it's graphical.
I love it. I like it. And it's command line. Yay, we love command line. Yay. Okay. I'm not usually, I have to admit, I click on listicles all the time. But we don't cover very many listicles on the show, but I'm going to cover one today. I actually, oh, my aspect ratio is off. There we go. Here we go. This is from PyCharm. It's actually from Evgenia Verbena. That's a cool name. 10 smart performance hacks for faster Python code.
And there's some that, well, actually, I think stuff like this is really good to talk to people about because we don't really think about performance too much. I mean, when you're starting Python, you don't think about it too much. It's hopefully, you know, hopefully you don't. There's, we don't want people to prematurely optimize. But there's just some habits that maybe are decent to get into that avoid problems later on. And so that's one of the reasons why I like going through this.
Oh, nice menu on the right side, also with all the hacks on the right. Anyway, the first one, not too surprising if you've done through any leak code stuff or whatever, is leverage set for membership testing. So if you've got a big list, you can throw the list into a set, and then you can find out easily if something's in the list by putting it in a set. And oddly, that speeds things up quite a bit, like drastically. List lookup versus set lookup is super fast.
Same predictionaries, too. If you're looking up by some kind of key, either one, it's ridiculous.
Yeah. Like I said, some not too surprising. Slots are great if you're going to use classes or data classes even. If it's not going to grow over time, you can define slots and stuff. And then the lookup for each element within a data class is a lot faster with slots. I want to jump around because there were some that I didn't really realize or I just didn't think about before. And one of them is use math functions instead of operators.
and I guess I wouldn't some of these are weird so math.square sqrt for square root is faster and more accurate than raising a number to the power of 0.5 using exponentation operator I wouldn't do that anyway because that's weird it just looks weird I don't know, bad code style but there's a whole bunch of others similarly the sine function exponent log, those are really fast operators in math so go ahead and utilize math and uh so that's a good pointer pre-allocate memory
with known sizes now this is some like an old trick that i think that i didn't really think that it was a huge difference and it looks like one of the things that's it's cool in this article it does the pre-allocated time versus or the uh before and after times so there's a bit of you know uh 0.01 second speed up um but so the trick is just to uh i guess have an array with If you're going to fill an array anyway, may as well just fill it with some zeros or something initially.
And then it seems like a waste of time to fill it with zeros because you're going to fill everything up. But it isn't because it's the allocation that takes a little bit longer than the filling it with zeros.
Yeah, and Brian, it's worth thinking through how that goes a little bit because if you just go append, append, append, and this is something I don't do and it's inspiring me to consider, well, maybe I should. But the array doesn't know if you're going to put a million items in there. Every time you do like a array.append or list.append, it doesn't go, guess what? We're going to add a million, right? It's like, well, what about 16? What about 32 of them? Oh, now we need more.
Okay, what about 64 of them? You know, it just, it has to keep reallocating and copying as you build this up. So, yeah.
And I don't remember how, I mean, it's a little smarter than that. So I think it like does, like doubles it in size or takes a chunk. I can't remember what it does.
Yeah, it's not allocating every one, right? It's got an awkward. Right. Or heuristic.
But if you already know how big it's going to be, you can just tell it to do it once, which is cool. But I don't really think about that too much. A couple of the ones down below I really wanted to cover. This was avoid exception handling and hot loops. And I am guilty of this too, because I try to have my exception handling as close to the place where it can go wrong as possible. Just as it's a visual thing and a code readability thing to have this tight. have the try right around it.
Like the example has a zero division error, has the try and accept right there. However, that might slow down a little bit. And it did, in this case, was the try and accept on this one. It's just not there.
I think the top one versus the bottom one. Yeah, but there's no try and accept at the top. That's the baseline. Oh, okay. The conditional check versus. It's like checking for the condition that would cause the exception to avoid the exception.
Oh, OK. I guess I would just put the try and accept at the top or around the larger one as a better comparison. Anyway. Yeah, I agree. But this is a big one. But that's a big one. Then we get into some really, except there's exception handling, using iter tools for combinatorial operations. And this is huge. If you're working with chunks of lists or chunks of stuff, using iter tools and knowing what's in there, it speeds up a huge amount.
So using iter tools versus loops for, I forget what the example is here, but the speed up is using product and the speed up is massive from, you know, like what, 440 times bigger or something? Or 4 divided by, oh, 5 divided by 20. That's 4. So it's 4 times speed up. Math is hard. BISect is also a great thing to look at. And yeah, anyway, just some cool, wow, that's a massive speedup, 100 times speedup for using BISect in the right places.
So finding out places where you can use BISect or iter tools and just knowing that those are there to look them up, those are good speedups. Anyway, occasionally it's good to think about how fast is my code going?
You know, I think we could summarize up that article by basically saying, know the standard know your data structures, mostly. Yeah. Use DICT, use Zitter Tools, et cetera.
And the standard library is still pretty big. I would probably limit that to the standard library that manipulates data structures.
Yeah, it kind of intersects with data structures.
Yeah, I guess that's kind of what I was getting at.
And by the way, this was written by Dito Grigorov and posted by Uvigena. Oh, okay. Just want to make sure Dito gets a little credit for writing it.
Thanks for that clarification.
Yeah, no worries. - It's tricky, I think it's 'cause the way the JetBrains CMS works. Yeah, so cool, cool. Well, maybe we should, Brian, maybe we should talk to him about it. Put him up on a little video call, you know what I mean? What do you think? Do a little WebRTC? - I've kind of forgot about RTC. - I know, but you and I are sitting here, people don't necessarily know how we're doing this.
It's magic, we basically, you and I, we speak through magic, but some of that magic is WebRTC because all of this is recording, streaming, et cetera, video and voice, multiple channels, multiple screens, and so on over WebRTC in the browser, which is ridiculous. It's just ridiculous that this works.
So I want to talk about a library from Freddie Bolton, who is behind the Gradio project, Gradio, Gradio, Gradio project, and I had him on Talk Python a couple of years ago, and this is called FastRTC. So kind of like, hey, I'm a fan of integrating with FastAPI, and I want to do WebRTC. It's kind of ridiculous how simple some of these things are. So it's pretty popular. It's got 4,000 GitHub stars, 400 forks. It's been around for a while.
Freddie pointed this out to me a decent while ago, and I finally ain't getting around to talking about it. But it's quite neat. There's a little video you can watch about how to do it, but it's got some examples for you. Like if you want to do an Echo Audio, which is kind of a sadistic example, you know what I mean? Because that's usually the worst thing about a video meeting, is the echo.
But if you want to listen to yourself echo back just to prove that it's going round and round, then how many lines is that? I mean, there's a huge comma in there, but if you take out the comma and you format it a little bit wider, it's probably five lines of code to set up a server, connect to it, and echo back. Like, that's insane. Insane. And there's also ways to set up LLM voice chat if you care about that. You know, that's obviously the thing du jour is I want to talk to my LLM.
But, you know, you could do that pretty easily, pretty quickly here. But also just stream your webcam back or object detection. It's just like a handful of lines of code. It's insane. But this stuff seems so complicated, doesn't it, Brian? It's cool. It's cool.
You're wrapping stuff up in a library.
Yeah. So it comes with automatic voice detection, turn-taking built-in, which is interesting. It's got a UI to launch it in built-in Gradio UI, if you want to do that. I believe that's probably JavaScript. Automatic Web RTC support. So mount it onto a FastAPI app and get a Web RTC endpoint for your own front end. So you can kind of go Gradio or you can go this way. It's got WebSocket support. Listen to this. Automatic telephone support.
use FastPhone on the string and get your own temporary phone number.
Actually, that's pretty cool.
Yeah. So, yeah, there's a lot of stuff going on here. It says you can easily be mounted on your own FastAPI app and customize it entirely, extend it to fit within your production app, I guess, assuming that's a FastAPI app. Although you could certainly squeeze it in using, like, Nginx routes to make it look like one app, but it's not exactly the same back end and so on. So there's examples for that. Wow. Yeah, so I thought it was pretty cool.
That's pretty neat. I interviewed somebody in like three years ago, 2012, about WebRTC. They wrote a book on it. Nice. I thought, like, I don't think I'd ever use that. But of course I use tools that use WebRTC all the time. So like you said, we're using it for. We're using it right now. We're using it right now.
And yeah, it's one of those things where it's like, I don't think I'll ever build one of those. And then you're like, oh, but what if I could do it for this project or something comes up or, you know, just knowing about it as a... I think it's...
Yeah, and right now, like you said, with things like hooking up LLMs to, you know, some vibe coding. Yeah, exactly. I mean, no comment. No comment. Okay, so this is a listener suggestion, actually. Comes to us as a request from Nicholas Kersner. He said, hey, I'm using PipDepTree a lot lately. And it's pretty cool if you covered that. And I'm like, yeah, we covered it. But I looked it up. It was, I should have had the episode up. But we covered it in episode 17. That was what?
2017. So yeah, it was a minute ago that we've covered it. So it's totally fine to cover it again because there's been changes. So I did want to talk about both pip Deptree, but also I have been, I used pip Deptree for a long time, But now usually I use uv pip tree. And so I just decided to write an article on it just to, because I wanted to show some code examples. One of the cool things I did not know that pip dep tree did.
One of the things that I would always do is I'd have a project install pip dep tree. And what it does is when you run it, it looks at all the stuff you have installed and then shows, shows them.
It's kind of like pip list, but it shows all the, it's like a tree structure and it shows them we're like in a tree structure with versions that are installed and it kind of it's extra information like the uh like if i'm using it from pyproject.toml i have an example of the cards project why it chose the particular version that's installed um so it's pretty handy but the i would always install it in the project and it
would also tell me that pip dep tree is installed but the uh the trick is to install it somewhere globally like either uh using uh uvx pip dep tree or uv tool install pip dep tree and then you've got it just available to you always and and then you can use python auto and it the python auto flag will tell you um it will look in the current environment that you're in so um so then you can have it in global uh and then yeah and just look at whatever project you're in which is cool i didn't
know it could do the auto thing too so i'm glad i looked that up the um but what i'm using usually is uv pip tree because it's already installed with uv and i have uv everywhere now by default i wanted to go through a couple flags that i um actually i just learned about this i i when i was i was comparing this beauty if you do uv pip tree it'll show you a tree structure but it only shows you the versions that are installed and it does do like for instance i'm showing cards and rich is showing
up and it looks like it's in a couple places. Package tree already displayed. Oh yeah, because the cards project depends on rich, but it also depends on typer, which also depends on rich. So rich is duplicated and there's a little note that says that. There's a flag where you can turn it off, but I kind of like seeing the duplication. It's just to see who all is using something.
Now, to get a similar look as pip dep tree, you can add show version specifiers and then it shows that it used to figure out what to install. But the new flag that I just learned about, which I'm super excited about, is --outdated. And this tells you, it tells you, it throws the latest up. It looks at all the things you got installed and tells you if there's newer ones. So you can go into your project and you can run UVPIP tree outdated and it'll tell you which ones you should maybe update.
So it's pretty fun, both of those.
So I like both tools. That's nice. I do as well. I've used pip dep tree for a long time. It's nice to just go, why is this here? Why is click installed? I don't remember installing click. It's fine, but I just don't remember installing it. But oh, it's Icy because I installed Typer, and I forgot that Typer is a wrapper on click.
Yeah, and one of the things, for instance, I'm thinking about update like a hypothetical scenario. I've got Rich, or I've got on my cards application, I'm using rich, but maybe I'll try to tighten the dependencies by not using rich. But if I'm using typer, it's going to come in anyway. So I like to see the duplication because I'm not going to save anything if I don't depend on rich directly. It's already there because of typer.
Yes, exactly. You're like, can I just get rid of this thing? You're like, nope. No.
Not easily.
Not directly anyway.
Yeah. But if I got rid of typer also somehow and then I could get rid of rich. And maybe I'll redo the TinyDB too. Yeah. Anyway, tighten it up. All right. Those are, that's my items to talk about. Oh, I do have links to both PipTrapTree and uv treeRich. UV PipTreeRich also. Those are all different words.
Nice. All right. Well, just keep going. You're the only one with extras today.
Okay. I got a couple extras. I've got one of the benefits of working at the office, like the back to office thing is I was walking by one of my colleagues and he's got a bunch of colors up on his screen. And I'm like, what are those colors? And, and I use, use VS Code at work and the, and I've often got different projects up the same thing he's using.
And I started using this just like last week, a thing called peacock. and what it does is it shows different colors around the outside of your, terminal and it only it's, or outside of your VS Code window, but the colors are picked and stored in the project or like the workspace. Yeah, the workspace. So that if you've got different projects open, they all have different colors. So when you're like, I want to go back to that window, you just have to remember which color goes to which project.
And that's kind of up to you. But Brian, I'm often still this. I in even if you one of the cool things is I'm like, well, I chose green and it's a little too bright for me. I kind of wanted a darker green. It has built-in buttons to just go a little darker, a little darker, a little darker, or a little lighter. You can do custom, like pick your own color, but you can also say, this is close, but I'd like it a little darker.
And I'm loving that. Yeah, and it's not incredibly popular, but it looks like it's from John Papa, who's been around in the tech space for a long time. So it seems trustworthy.
Where do you see the popularity? Is it in here? It's the downloads. Oh, I take it back.
I thought it was, it may have more than I initially, said it has three point basically four million downloads okay so actually there's a few downloads people like this idea oh i was looking at the um the open vsx marketplace which is like a similar
but not the same uh the other update so one of the things i mentioned last week is that i'm writing a book again and um i just updated uh this last night i think last night there's um a chapter another chapter written so i gotta clean this up both versions are here but i did essential for successful software projects. I got that one up and I completely rewrote the introduction and I should stop doing that.
An editor a long time ago told me, do a quick introduction and then leave it alone until you finish the book and then you can update it to be what the book actually is. And so I got to do that.
A hundred percent. I think that's a great idea about the introduction. I do it with my courses. Sometimes I'll record the whole course and then I'll record the introduction because I'm like, I want to be able to say, and we're going to cover this in this section and then actually have that match.
Yeah, but my brain won't let me go on if I don't write an introduction to start with. It's like, but I haven't done an introduction, man. And the essential components chapter, this was tough, man, because there's like, I needed it to be tight or I wanted it to be a tight chapter, but I rewrote it like five times because I had so many stories and stuff I wanted to throw in and I decided to take the stories out and leave those stories as blog posts later.
But, oh, I guess the third extra, I don't have anything to show for this, but when I'm writing and I've got all this great stuff that I want to save, but I know it shouldn't be in this chapter or it shouldn't be in this blog post. I've decided for my editor, I've got a file called cut bucket, like CUT bucket. And I just put a divider line, put another title and paste the stuff I want to save there. And then I don't. And then my brain, it's a brain trick is I haven't thrown it away. It's there.
You don't have to remember it and move on with writing.
Yeah. Yeah, awesome. What's your editor that you're writing in?
Like, do you have a markdown?
What is the story?
Oh, yeah, it's markdown in VS Code. And so the pytest book had tons of code snippets and everything. I think this is going to be a code snippet-free book. So that I can, the goal is to do an audio version later. And, you know, I might have some code snippets, but probably not. Actually, it's one of the things of reading the Tester of Development book from the old, the OG one from Kent Beck. It's all in Java, I think. And it's like too much. You're lucky it's not Smalltalk. Well, right.
Maybe it is Smalltalk. I don't know. I think it's, I don't remember. But I just sort of scammed by the code snippets because I'm like, I don't care. I'm just like here for the concepts. So I'm trying to keep this book, the concepts and not the code because the code is different for everybody, man.
Absolutely. Anyway. Love it. That's all I got. All right. Well, let's tell a joke then and close it out. Okay. I've done a few AI ones. It's not an AI joke, folks. So if you're tired of the AI jokes, well, then don't worry. This isn't a AI. This one is a joke about the future of Python and people being stuck in their ways or having assumptions about Python not being as fast as it could be or having limitations that it doesn't have anymore, theoretically, or semi-theoretically, whatever.
And it's a woman in a walker, probably 70 or so, with the granddaughter helping her back to sit down or something. So I think I named, what did I name the project, the joke here? I think I called it, okay, Grandma, it's the joke. So, honey, do you know that the gil prevents multiple Python threads from executing parallel? Sure, Grandma, let's get you back to bed. a bit of a testament to python 314 and python t and free thread python and all that that'd be
that's funny i can just like fast forward i can imagine like me 10 years from now telling the kids you know was that when i was a kid we had a GIL we had a one thread at a time
your little whippersnappers don't know how good you got it my python used to just run interpreted and it was so slow we would debate whether it was fast enough uh yeah anyway that's what i got for a joke for us i like it
yeah all right it worked for me i liked it so nice all right well uh thanks everybody for joining and listening and we love you all and um we'll talk to you next week yeah thanks brian thanks