Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 446, recorded August 25th, 2025. I am Michael Kennedy.
And I'm Brian Okken.
And this episode is brought to you by many cool services and products.
Can you imagine a course that teaches you how to use pytest? An entire library of 270 hours of
courses about all Python things, pytest book, and Patreon supporters. Thank you all. Yes,
check out Brian's courses, Michael's courses, Patreon supporters,
so check out Patreon and all that.
Thank you.
And I actually have another thing that kind of falls into that category
that's pretty awesome I want to talk about later.
If you want to connect with us on the socials,
MastodonBlueSky is probably where we spend most of our time.
Brian, me, the show, we've all got accounts.
You can watch us live on YouTube at pythonbytes.fm.
slash live. If the live show is going on, it should say a big banner across the top. Hey,
we're live. Click here to go to it. And if not, you'll just see all the past live streams. So
much appreciated. Typically Monday at 10 a.m. Pacific time. And you should definitely subscribe
to the newsletter because you'll get a custom email from Brian talking about all the different
things we covered and not just a list of what we've covered, but diving into extra details,
extra links more background info very cool also very cool our statistics yeah tell us about these
things well we have um there's a there's a website called pypi stats.org and and it's it's nice it's
you pop into it and it just says analytics for pypi packages so let's uh let's pick one
by test check uh it's my favorite um little thing that i support and then it you what you get is you
you get these, I'm pretty sure we covered this before, but you get the download statistics.
So that's not really the news. It is a cool website. You should check it out if you haven't
checked it out before. And you can also check out the top packages, which ones are the most
downloaded by day, by week, by month. And that's all fun, but there's some details in the individual
package that you might want to know if you're supporting stuff. So like, for example, what
system for pytest check. It looks like it's pretty much all Linux, 97.5% Linux, which makes sense.
It's a test tool. So a lot of the tests are running in the server and not other places,
but the package supports Windows anyway. But if I wanted to like, you know, bail on Windows,
I probably wouldn't be a terror. I mean, I don't think very many people would be mad because
1% of the people would be pretty upset. Yeah. Well, you know, so maybe I'll leave it. It,
It isn't OS specific anyway, but some things are, you know?
So, okay.
So why am I bringing this up?
If this is old news, you should know about it anyway.
But one of the things is a few weeks ago, it went down.
This is a volunteer supported site.
And it was by C.R. Flynn.
I'm sorry.
I don't know his name.
But anyway, posted that, hey, PyStats.org is down.
Somebody reported that like three weeks ago.
And so I noticed that.
And Hugo mentioned it.
And I saw what was going on.
But just a couple days ago, Hugo announced, hey, PyPI stats is back online.
And it's more supported now.
So thanks to Janice and the PSF.
Thanks to Janice for suggesting that the PSF takes stewardship and connecting the right people.
like eDurbin for migrating and of course Christopher Flynn oh Christopher Flynn was created it but um
but a lot of people were involved or at least a handful of people were involved to get it back
online and get it going and I didn't realize um so that's cool it's back online works great and I
really appreciate it because I don't use it all the time but occasionally and I won't I'd like to
use it I didn't know that there was a CLI for it so uh Hugo um put together a project called PyPI
stats same name but without the dot org but you can pip install it and you can run it on the command
line and it's super neat um you can actually you can run it on the command line and you get you get
some you can pass it like python i'm showing on the screen python minor so it shows uh which python
versions are being being downloaded um but you can do other stuff you you can what i have a list
look it up. You can do Python major, Python minor, the system, overall downloads, recent downloads.
So it's pretty interesting information. Some new things that just got released are the ability to,
you were always able to pass in like a name. So just on the command line, type in a package name
and get the stats. But now you can also point it at a directory or not point it at anything. And if
you're in the current directory for a project and it'll just look up by project.tom or set up CFG
and look it up. So really cool that Hugo extended that command line thing to be able to look up
that information. That's cool. And it tells you what is the popularity of the packages
you're using basically? Yeah, well, the popularity, but also just different stuff.
So like for Pillow, for example, it shows an example of, and this is in black and white on the
readme, but if you do it on the command line, it's color. So the color output is really kind of nice.
Nice.
But you can figure out like start and end date. So if you want a particular date,
you know, for you want to zoom in on dates, how many downloads last month and whatnot.
And the different things like the what Python version is good. It's kind of cool because you,
that's one of those things of like, is it, you think it'll be okay if I completely remove support
for 3.8 if i want to bump up to 3.10 or something but looking at pillow for example it's um it's
still uh you know five percent of the people are using uh 3.8 um and some people are still using
3.6 so maybe they should still support it i'm not sure so maybe they support it or maybe they could
be the pebble thrown in the water to create the wave that causes those people to upgrade
Yeah. There's some cool flags for the command line thing, like last month or picking a date, easy to read stuff. And there's an API for it or like a package, importable package that you can do it programmatically.
So anyway, cool tool.
Very cool.
All right.
Let's jump over and talk about the state of Python 2025, according to the PSF JetBrains
survey.
Ooh, neat.
This article is written by a little known guy named Michael Kennedy.
I actually worked with, yeah, I worked with JetBrains and they're like, Hey, you want
to write this?
I'm like, yeah, sure.
That'd be great.
So basically what I did is I went through all of the survey results and pulled out the headlines and like the trends and like what jumped out at me.
Right. You know, you and I have done this together before, Brian, where we just pull up the survey results and do it on the show.
I did this with like way more time and effort in written form and then we'll do it on the show.
How's that? So I think this is maybe like 4000 words.
It's like quite a quite a write up. Right.
So I want to just, I don't want to go through all of it.
You guys can read it, but I do want to pull up some interesting trends.
So the first trend I think that's pretty wild is that Python people use Python.
And you're like, oh, Michael, obviously.
But if you had a JavaScript survey, you would ask, do you use JavaScript?
And a lot of people that do Python would say, yeah, I use JavaScript.
A lot of people who do, I don't know,.NET use JavaScript, right?
Either as little utilities for Node or as because they need a website that has interactivity.
So I think it's noteworthy that of the people that are in the Python space, they're not there
as a secondary purpose.
They're there because of Python, not because like they've got some library that they need
to work on, right?
So 86% of people who are Python people use Python, like as their, that's their main thing,
right?
As their main.
And then 14 is secondary, so.
Yeah, yeah.
So like maybe they have to support tools in Python,
but that's not really what they do.
The other one that I think is wild is that,
I think we maybe have mentioned this.
I know I've mentioned this on Talk Python before,
but people out there are mostly brand new.
I've seen this once before,
but it continues to be true even more so,
and it blows my mind.
How many years of professional coding experience do you have?
Less than two.
One to two years, like zero to two years of programming.
That's 50% of the people.
Wow. 50% of the people in the Python space just started. And if you're one of those 50% listening,
thanks for listening. I know a lot of people listen to our podcasts so that they can jump
into the community and get up to speed. So that's pretty awesome. But this has tons of consequences,
right? Like if you're creating tutorials and you're just like, Hey, yeah, install that,
make a VNV and then install the package for local editing. Now we get started the tutorials,
like hold on, you, you got to realize you're talking to people that are just getting started,
like half of them.
And I think that has a lot of implications
for tooling, for tutorials,
for presentations, et cetera.
Yeah, but this is also,
this question is how many years
of professional coding,
not necessarily how many years of coding.
Yeah, there's more results in there
that are like how much experience
you have with Python at all,
and it's like really quite low.
Okay.
So this, but this is also noteworthy
in the sense that like,
not just how much time do they have with Python,
but how much they have time
professionally coding at all.
Yeah.
Right?
Yeah, and I'm noticing that a lot with people I teach as well,
I get a lot of, on the Python test community,
get a lot of questions that say,
I don't know if I can ask this here,
but basically I don't have any CS background.
And so I don't know what a lock is or something like that.
So I'm like, yeah, sure.
Let's talk about that.
Yeah, exactly.
Yeah, and it's fine.
Another one, I don't know.
I've always thought of the Python community being broken into thirds,
like one-thirds or web API, one-third data science,
and one-third catch all others, automation, little tools, whatever.
Well, that is no longer valid.
Data science is now half of Python.
51%.
And it's probably 51% AI, too, because with AI, you can go over 100%.
That's right.
Absolutely.
You don't need it to add up.
Now, this does include data engineers who I got a message from so many.
I don't want to be grouped in with data science.
Like, okay.
But you also don't belong in web.
And you don't belong in other, I don't think.
I don't know.
But, you know, that does include some data engineering.
But nonetheless, this is a significant portion.
Another thing to keep in mind.
Okay, so does this survey include the LLM people?
Yeah, yeah, oh, absolutely.
Yeah, yeah, definitely.
I think a lot of this is people getting into machine learning and so on.
Okay, this is, I think, the last main thing I wanted to, I know, two more things real quick.
The other one is, and this one I think I want to put out there as a, if you were in this group, reconsider.
Most people, 83% use a major version older of Python or older.
I mean, we're at the end of 3.13, and it's like 83% are like 3.12 or below.
And not just like-
We're not at the end of 3.13.
Well, no, not in the end of like support.
I mean, we're about to have 314 is what I mean.
Yeah, right.
That's what I mean.
Like it's 313 is not,
it's about to no longer be the latest is what I'm saying.
So this is pretty wild.
And I did some quick math,
just like, you know, some people are like,
well, it works fine for me.
I don't really need it to be any better.
Like I don't need the new tools.
So 311, let's say 311 is fine.
Or let's say 310, 310 is fine.
Even 39, it's supported for another couple of years, right?
Probably, maybe one.
But there's, I did, like, let me do some quick math here.
Just see if I can put this in perspective
Like in addition to just, you might need to be on the later version to have some of the newer tooling, right?
Some of the new libraries and so on that decide to drop the old one so they can adopt some feature, right?
Yeah.
But I said, well, what if you're on 3.11?
48% of the people currently using 3.11, if they upgraded to 3.13, their code would run 11% faster and use 10 to 15% less memory.
Yeah.
If you're on 310, you get a 42% speed increase and 20 to 30% less memory just by changing the Python you're running on.
Chances are it's extremely minimal or zero upgrade cost.
You just got to try it out.
And then I also did some of that.
Yeah, this is like no code changes.
Just change the interpreter.
Exactly.
Just change the start command or what's installed.
So what if you're a medium business?
I did a little research like vendor.com and stuff.
I said the average AWS bill for a medium-sized business is $2.3 million a year.
And EC2 represents 50% to 70% of that.
And if you're paying for a bunch of cloud machines or cloud compute in whatever form,
and you get those boosts I talked about, well, your small business just saved $420,000 by just changing from 310 to 313.
Wow.
If you're a large scale business, like a large enterprise, you save $5.6 million by just switching to run on the newer version of Python.
So anyway, I think these are like really, really interesting.
And then the last one is there's a big resurgence in Python web development, I think.
Over the years, this has been trending down 45, 43, 42%.
But it's back, baby.
And not just are people using, saying that they're doing a little more web development.
But if you look at things like CSS or HTML in terms of how much they're used, they jumped, I think it's like 15% up year over year.
Not a like 30 to 45%, but the increase from what it was to the new one is like a 15% growth from what it was previously.
So like all in databases just across the board.
So I think that's really interesting because there had been like a long, slow trend of kind of like Python's less for web, Python's less for web, probably more JavaScript.
And it's like, it's back.
So I think that's pretty interesting.
And then there's a bunch of like guidance that I gave for people at the end.
Like, okay, now that you know all this stuff, here are some actions, some actionable things you can do to take advantage of these trends and whatnot.
So I've said enough about this.
People can check it out.
It's a super long and interesting article, I think.
Yeah.
Okay, cool.
I can't wait to check this out.
Yeah, indeed.
All right, over to you.
Well, I'd like to swap out and take a look at wrapt.
Actually, I couldn't resist,
so I'm going to talk about a package called wrapt,
and I went ahead and looked at the PyPI stats,
and it's used a lot.
So it's the, I don't know, numbers percent-wise
or where it is at the top packages or something.
But it's downloaded almost 5 million, 4.8 million daily downloads.
That's pretty good, pretty big.
So a pretty popular package.
So what is wrapt?
wrapt is, I can't believe we actually haven't talked about this yet,
but wrapt is a Python module for decorators, wrappers, and monkey patching.
And to be honest, the first time I ran across wrapt, I thought,
well, wait, don't we have functools wraps?
That's what I've been using before.
However, so let's talk about wrapt a little bit.
The aim of the module is to provide a transparent object proxy for Python.
Yep, wrappers, which can be used as a basis for construction of function wrappers and decorator functions.
Right, got it.
Funktools wraps, right?
No, apparently.
So the wrapt module focuses very much on correctness.
It's therefore goes way beyond the existing mechanisms such as func tools wraps to ensure
decorators preserve introspect ability signatures type checking abilities.
Okay.
Yeah.
Cause sometimes you'll, you, you, like, let's say if you, one of the examples of, I can't
remember where it is in the, in the docs, but if you, if something that is in a package
is implemented as a property, not a method or then, then the return value is different
than if it was just a function.
But, and functools wraps gets that wrong,
but wrapt, I think functools wraps gets that wrong,
but wrapt gets it correct.
It has it behave and signature wise look the same,
which is pretty cool.
Wish I knew about this.
I just thought I was battling.
This decorator doesn't have the right,
you know, it transforms the type of signature
of this function.
So then you get some warning.
I'm like, I don't care.
It's a web function.
No one's going to call it directly,
but it's just an IDE warning.
I'm like, ah, make it go away.
And to be fair, the main reason why I usually am reaching for, if I reach for functools wraps is because it makes the name of the function be correct.
And it isn't the silly little function.
It changes the name and it changes the doc string.
So if anybody's looking at the name or the doc string, it gets corrected.
And if that's enough for you, yeah, that's fine.
But it's kind of interesting looking at some of the history.
So I was looking back.
There's a blog that the creator of this wrote, Graham Dumpleton.
And this is back from apparently originally, if we go to the blog, it's originally from 2014.
He started writing these and he's kept them updated.
So last update was five years ago, but original 2014.
Anyway, how you implement your Python decorators is wrong.
I was interested. One of the reasons why I was interested in this is the idea that it was around monkey patching and monkey patching is the original thought process as to why he wrote this is he was monkey patching things and it was incorrect.
And interesting discussion over there on the blog about monkey patching and why why it's not just for testing.
I use it a lot for testing, but it could be there's a lot of other use cases to interesting block series of blog posts about it.
So pretty fun to take a look.
One of the amazing examples in the docs,
which I thought was really pretty awesome,
there's some really easy examples that you'll get right away.
And then it goes like pretty deep.
So let's say you've got asynchronous code or multi-threaded code,
and you want to synchronize those with locks.
He's got this write-up, which is, you know,
it's a kind of a lengthy write-up, but it's not too bad.
And the end result, if you scroll to the answer at the bottom,
is you can just have synchronized.
You set up these locks and you decorate each function that you want
synchronized with a synchronized decorator, and it just works.
So it's kind of fun to be able to do things like put extra abilities
around something like lock, grabbing a lock or something like that.
Yeah, that's really cool.
We're going to need more of that as free-threaded Python becomes the thing.
People have to get used to those concerns.
Yeah, and also one of my concerns with jumping from functools-wrapt to WRAPT,
was I was worried about speed because it's doing a lot, so is it kind of slow?
And apparently not.
To ensure the overhead is minimal as possible, a C extension module is used.
If it's available, an automatic fallback to a Python implementation is provided
if the target system isn't extended for that target system.
But for my use cases, as we've seen,
most of my users are on Linux,
so we're probably fine there.
Yeah, that's really neat.
Very neat, very neat.
Let's see, what is next?
Owen Lamont is back with a good recommendation for us.
Okay.
Yeah, he says,
you should check out PySentry.
So I did check out PySentry,
and it's quite neat.
So what is PySentry?
It scans your Python dependencies for known vulnerabilities.
And it's Rust-based, so it's fast and it might get VC funny.
So what it does is you go into a folder, a project.
I'm not sure if it needs an active virtual environment or just the files,
but it will scan uvlock, poetrylock, piplock, pyproject.toml, pipfile, and requirements.txt.
Look for specific versions of dependencies that you are specifying there.
and it'll cross-check them with a bunch of vulnerability databases.
Not just typo squatting type stuff,
but just, hey, there was this vulnerability reported in the Django admin.
You should update because you don't want to participate in that kind of fun.
You're not about that life.
So pretty cool.
Yeah, it has multiple data sources,
the PyPA advisory database, PyPI JSON API,
OSV dev open source vulnerabilities, and so on.
Yeah, and it's pretty neat.
So you can specify different levels.
Dependency scopes are supported like dev versus main,
direct versus transitive dependencies,
and that kind of thing.
I ran it on our setup on pythonbytes.fm,
which apparently, now one thing really quick here
is it actually has more than,
it says PySentry security audit.
Summary, 89 packages scanned,
one vulnerable, one vulnerability found.
Ah, Brian, what's going on?
There's actually more than 89 packages.
for our website, but I don't know why.
Maybe there's just no information
about some unpopular ones,
and so that's why they didn't show up.
They weren't scanned.
I don't know.
I don't know why it's less,
but that's my conjecture.
It says there's one unfixed low severity CVE found,
and it's unfixable.
Great, that's why it's still there.
What is it?
It is an aiohttp.
If an invalid IPv6 URL is passed to it,
it will go bonkers.
I don't care.
This is the dependency of a dependency of a dependency that internally calls an API to its own service.
And it uses aiohttp to do that.
No one's going to pass a invalid IPv6 URL to that thing because it's not even part of our code.
It just happens to be we ask the service to do something.
It goes, OK, I got to call my API in the cloud and do that.
Right. But here it is.
So you can decide is that an issue or not.
But still, that's pretty cool.
Right. You could just run this in your project out periodically.
or you could maybe run as part of CICD and get like warnings.
Hey, maybe I shouldn't put this in production.
It says there's a CVE severity level 10 out of 10 remote code execution,
no auth required.
Let's not do that.
Yeah.
Interesting.
Yeah.
One thing to be aware of, you don't uv tool install PyCentury.
You install PyCentury-RS.
So just be careful on the install.
I don't know what's at PyCentury, but I presume it's not this.
Oh, okay.
So you have to be careful what you're installing.
Yeah.
Just look at the website and there's the same,
the name of the command and the package are different.
Yeah.
And I know that that happens,
but it always like,
I don't like it.
Just pick a different package name,
people.
Come on.
One quick extra for me is that we,
I talked about this last week that our testing code is being offline to
archived or whatever.
It's not going offline.
I don't think.
So last week, Michael convinced me to think about archiving it away.
So you'll be able to go to testandcode.com and find it.
For the foreseeable future, I think, looking into ways to offload it to somewhere else.
But there's some pretty cool things that make it seamless.
So I think that as I get time in the next couple of months, it'll transition over and nobody will know the difference,
except for maybe the website will look different other than that.
Also, I've gotten a whole bunch of great comments.
So a lot of people have gone over to the contact page.
And so in the episodes, I've said, hey, you can go over to pythontest.com,
and there's a contact page, and you can reach me if you want.
I'm not really fishing for compliments, but a lot of people have said,
hey, I've enjoyed this podcast, and thanks.
And just some nice emails have come in.
So that's cool.
So thank you, everybody.
Very nice.
And I'm glad to see you're keeping it online.
That's cool.
Actually, somebody contacted me and said that I was worried,
so I downloaded all the episodes.
So you don't have to do that.
Very proactive.
Okay, Michael, how about extras for you?
I have some extras.
I have some rumdoll follow-up.
This is the Markdown Lentor that we talked about previously.
Let me do it in reverse order.
So I'm actually almost ready to release my Talk Python in Production book, which I've been working on.
It's about 300 pages now.
I'm going to release it as an e-book initially.
If it's worthwhile, I'll eventually do a print.
But certainly an e-book that you can get.
So you can read about the first third of it online, which is fun.
So if people are interested, they can go through and read the first seven chapters, I think,
which is exactly what's in the book.
and then you'll be able to actually buy the rest of the book pretty soon.
So why am I starting out with this?
One, I encourage you right now, it's not quite released yet,
go click on buy the book.
Please put your name in and email address.
Say, I'm interested when this comes out and I'll email you very, very soon.
But the reason I'm talking about this is I've been grinding on that thing
with like 45,000 words worth of markdown with a rumble.
And I have some reports.
It's been going really well, actually.
The thing works great.
It's found some issues, some of them I didn't like.
I didn't like the fixes it was proposing.
We talked about it word wrapping at line 80 or whatever you set it at.
And I'm like, no.
My Markdown editors, it shows that kind of formatting.
I want it to just wrap around and not be weird, no wrapping, wrapping.
So you can turn those kinds of things off.
Yeah, exactly.
The other thing is I pointed out that there was a bug
and not sort of looking up the directory tree
to find the config file if you're down in the guts.
And so Ruben very kindly said,
you know what, that's a good idea.
I'll fix it and just released a fix
that made it a little bit better.
There's a lot of traction going on here.
Yeah, so-
That would have bugged me too, yeah.
Yeah, I'm like, well, the reason it bugged me
is I was, there's like the book
and then there's a source folder full of all the markdown
and then there's other folders that are like output
and assets and so on.
And I was down in the lower one and I ran it on accident
and it completely formatted and changed everything
based on the defaults of the tool,
not all the specs I set.
And I'm like, no, no, no, no.
You know how much work is this going to?
Luckily, I just rolled it back in Git,
but I'm like, it was easier to apply the few changes
that I wanted to keep than to redo all those things.
Anyway, that's fixed now.
So it's awesome.
And then finally, I thought maybe people
would be interested in the config that I was using,
that I am using,
And I turned off a bunch of things and added comments to what I turned off, like line wrapping, for example.
And also, I don't know where I got the config file.
I got it from somewhere, but some of the settings were not right.
Like, I can't remember exactly what it was, but maybe they were not under a global tag or some weird thing.
And the TML.
So I put mine up, and it seems to work if people want to borrow it.
So anyway.
Cool.
So that's in the show notes, right?
That is all in the, yeah, that's all in the show notes.
I've made it a gist, and you can get it from the gist.
It's just that easy.
That is right.
Okay.
And then I think, oh yeah, one more thing.
Remember last time I speculated, could Python 3.13.6 be the final 3.13 before 3.14?
No.
The answer is no.
No.
The answer is a hard no.
The answer is actually no.
3.17 was released before you talked about 3.16.
Because 3.16 came out, I wrote it in the show notes, and then I didn't look for a few days.
We did the show and 3.17 had already come out.
So that's a hard no.
3.13.7.
Yeah, sorry, 3.13.7.
But here's the thing interesting.
Why?
Why is that the case?
It is a emergency bug fix for an issue or a problem introduced in 3.13.6.
So in 3.13.6, there was something that went wrong.
And they're like, ah, what was it?
a regression in the SSL module between 3.13.5, 3.13.6,
reading from a TLS encrypted connection block.
That actually sounds like you really want that to work.
Yeah.
Well, so don't predict it again,
because the next one will just be,
the reason will be to make Michael wrong.
Exactly.
Yeah.
How about that for a release note, huh?
Okay.
That's it for all my extras.
Okay.
Are you ready for a joke,
or you got something else for us first?
It's like 98 degrees here.
Yes, I'm ready for a joke.
so i know neither of us have air conditioning in our current setup right now i'm above the garage
in this separate building that has literally no ac i have to close the windows because the road noise
is my little spa time my sauna time and i am in a house that used to have lovely air conditioning
and it picked the hottest weekend of the year to break so because when else would it break
all right well it's gonna be fine brian don't you worry about it you know why why because the
this planet is marked for death.
Okay.
So says the Silver Surfer.
Now, I don't even know what show the Silver Surfer is from.
No, it's one of those like Marvel or Avenger type shows.
But the Silver Surfer appears and says,
your planet is marked for death.
And people say, can we ask why?
Well, the Silver Surfer says,
because your planet's beings chose JavaScript
as the primary language of web development.
Clearly a fatal flaw.
What is wrong with him?
We're going to have to just finish you off.
You're clearly not worthy.
That's good.
Yeah.
I can come up with some other reasons that it might pick as well right now.
You know what?
The Silver Surfer is not a fan of front-end frameworks.
I'll tell you what, though.
At least my frustration with all this kind of stuff is not that JavaScript is a language for front-end development.
It's that it's the only language ever.
after 25, 30 years of code running in browsers,
that it's the only language that's...
And we've had WebAssembly for 10 years.
It's fairly ridiculous.
Anyway, thank you, Silver Surfer,
for putting us out of our misery.
Yeah.
Maybe not.
No, no.
Pat says you should come visit Iowa, by the way.
Lovely weather and not melting there.
All right.
Thank you, Pat.
I like Iowa.
Indeed.
And with that, Ryan, thanks for a lovely show as always.
Bye, everyone.
Bye.