Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 445, can't believe that, recorded August 18th, 2025. I am Brian
Aukin. And I'm Michael Kennedy. This episode is sponsored by Sentry, Python error and performance
monitoring. Thank you, Sentry. And if you'd like to get a hold of us, maybe give us some topic ideas that you'd like us to cover on the show, that would be awesome. Or just comment on something or just say hi, you can reach us on both BlueSky and Mastodon, and the links are in the show notes.
And if you'd like to join us live for the live performance, performance, pythonbytes.fm/live, or you can also use that link to find out when we're going to record next or just find out where the YouTube page is so that you can subscribe and watch them later.
That'd be great.
And finally, we'd like to get a hold of you later just to sell you stuff.
No, just to give you links.
So we cover a lot of stuff in the show.
You don't have to keep track of the links.
They're in the show notes, but they're also the links plus extra information and things you might need to know if you are new to Python or new to a topic.
Those are all in the email.
So you can go to pythonbytes.fm and sign up for the newsletter and we'll send that to you.
And that's all the intro stuff.
So, Michael, we got some exciting news for number one.
We have very exciting news.
And as part of this performance, Brian, I would like to recite The Raven by Edgar Allan Poe.
Oh, no, wait, this is not a performance.
And I don't want to do that.
I want to talk about Astral, actually, because this is a really interesting announcement from them.
Charlie and team are knocking stuff out of the park.
They're delivering big time on the tooling for Python packaging, managing Python, right?
all the layer that you build upon when you're writing applications, right?
So first they came out with Ruff for formatting and fixing issues.
Then they came out with uv, and then they upgraded uv to have its project management and Python management, not just alternate pip installs and so on.
And along all of that time, people have been saying, well, this is so amazing.
It's so fast and it does all of the things instead of piecing together tools.
But what if they rug pull us and we slip and we hit our head?
What if they go and do something else?
What if they start saying it's a half a cent per pip install or whatever, you know?
What are we going to do?
And Charlie has said that he's not planning on monetizing those types of things.
Instead, he wants to build on top of it.
So with this announcement, we get our first look at what that might be.
So it's interesting in and of itself, but I think it's also interesting in like,
this could be the thing that supports the stuff that people are really starting to depend upon.
And it's something called pyx, pyx.
I'm going to be interviewing Charlie on Talk Python in a couple of days.
By a couple of days, I think it's next week.
But pretty soon, I put a link to the event on the show notes.
People can check that out.
So we'll get the pronunciation.
I'm going to say pyx for now, like ty and uv and so on.
Unlike Ruff, not R-U-F-F.
So pyx, a Python native Python registry now in beta.
So here's the deal with pyx.
Think of this as an alternate PyPI, but not as a source of packages, not where, like when I publish something, I also have to publish the pyx, but more of a front end that adds a bunch of features or an intermediate layer, a middleware to PyPI itself.
Okay.
And at the moment, the plan is for this to be a full-on paid service for people that really need things like i really need my project to 100 be able to build some thing that's only available as a source distribution right how often have you pip installed something and most things just come down as a wheel and they come flying in but every now and then it'll stop and say
building something for 10 seconds the very first time before it gets cached then it goes yeah or longer yeah definitely potentially longer like i don't use it anymore we've talked about why
is micro whiskey because they said please stop using our project we're not going to support it go find something else and we talked about that but that thing took forever to build but also if you're doing a gpu aware types of things you're doing a lot of stuff with pytorch or machine learning more broadly a lot of those things are huge and having the right platform built version is really really tricky okay so the idea is that uv and pyx are going to go together hand in glove So uv can work even better by having complete control over the back end as well.
They say there's some limitations that uv was able to solve, but not all of them because they don't control PyPI.org and its API and how things get built.
So the idea is making it easier to install PyTorch or CUDA-based libraries, that kind of thing.
It also solves the problem.
Why is everyone rebuilding the same packages over and over on their machine?
And what if those build tools are no longer the same?
Why did setup tools break our recent release?
How do we authenticate against our internal registry?
The other thing this is going to do is it's going to be a first class private registry.
So if you have a team, you're like, let's publish our data access layer, not to the world, but to our other people who are working on the projects, to our other applications, and so on.
So pretty exciting.
I think there's a lot of stuff going on here.
They're in beta.
You can join the waitlist.
You can get in touch with them.
It says, beyond the product itself, pyx is also an instantiation of our strategy.
And this is what I opened with.
Our tools, uv, Ruff, ty, et cetera, remain free, open source, and permissively licensed forever.
And this project is pretty interesting because it's a glimpse into how they're planning to make that possible.
Yeah, I'd be really curious to watch this.
I'm excited for a lot of reasons.
So let's say this is only a commercial offering.
It's a corporate sort of thing.
You have to pay to get it.
I'd be still okay with that because the alternatives, there's alternatives out there like JFrog Artifactory is around.
And there's other ways where you can, there's other products available to set up to mirror PyPI and do other things like as things come in, do like a security scan, your own security scans and things like that.
And so a mirror in front end, but also something that you can publish to internal, publish internal things to.
Those are really cool.
They're a little hard to set up though.
And I think I trust Astral to make this fairly easy for people.
It also would be cool if you want to test things out locally.
There's smaller businesses and smaller teams that aren't large corporations or even individuals that might have a need to try out what a repository might look like when you're doing those sorts of things or you're developing on an airplane or something, a local repo.
So I don't know if they're going to get down to the point where it's a, like a local person, like a free thing that you can just run on your own.
So it'll be interesting to watch.
I guess I'm okay with either if they want to keep it like paid only or something that, you know, small fry can use as well,
but I'm excited to watch.
I am as well.
Yeah.
There's, I think somewhere Charlie said maybe possibly there's a free version, but right now the plan is to be a paid project.
Yeah.
Yep.
All right.
That's all I got to say about that for now until I talk to Charlie and
more about i want to talk about lightstar a little bit there is an article called um uh where did i i missed it oh here it is sorry james bennett um has an article called lightstar is worth a look and i was looking through our past history a little bit and it looks like um we've talked about lightstar but it's been a while so you brought up um this was earlier this year i think talking about rewriting court um or rewriting talk python in court and lightstar is one of the things you looked at right so that was episode that was back oh that was last year november of 2024 so he asked client hello that was a good one um so we haven't talked about it a bit um so i was taking a look at it uh looking at Litestar i had never played with this and there is some interesting history around that it used to be uh star light like or something like that yeah it was not star
let star light.
And there was confusion, whatever.
Anyway, so this is an interesting James Bennett brought up Litestar is worth a look.
And he brought up like a lot of people do, if I'm going to do an API, why not FastAPI?
I mean, that seems like the obvious choice now for setting up an API or something.
And or a lightweight web framework. So why not?
There are a few reasons that he brought up. So one things was in scaling and not scaling in traffic, but scaling in, I want more than one file. I want a bunch of, I want my application in a bunch of files. And there was some frustration that he talked about with trying to figure out how to do that within FastAPI because there's the app dot.
And how do you have multiple routings in different files if you have one app? I don't know if this is easy or not. But he had some frustrations that it took him 40 pages into the documentation to the user guide to find that. However, it's kind of built in with Litestar is that you don't, it's not a top level app. You can, you can set it up, I guess, into multi-file, multiple files easier is one, one thing. The other thing was that FastAPI is tied to Pydantic. And I don't know if you can break that or not but um lightstar is not tied directly to pydantic and you can use it can use yeah it can use pydantic but it also has other options yeah uh um he he brings up um maybe attrs you could use attrs for validation which um some people forget that that's one of the cool things about attrs is it can validate things um or SQLAlchemy even can do um some of that so um Or a little combination of both, I guess.
Anyway, so that's interesting.
If you'd rather use SQLAlchemy for that or attrs, why not?
The third option, what is the third thing he brought up?
Is, I guess, just the architecture.
I had another note.
Anyway, it's interesting that there's another option out there.
So do you know more about Litestar?
I interviewed the guys from Litestar over on Talk Python,
so I know a little bit more.
not a ton more i would say one thing kind of a mental model i have about Litestar and i'm not sure how accurate this is but you know it's mine so i gotta have it is fast api is kind of flask esque in that it gives you enough to be have a bunch of cool building blocks but then you pick you build the other pieces and so on whereas Litestar seems to me a little bit more of the django philosophy where it comes with a bunch of batteries included like see all those little boxes down there look at all like the different pieces right it's got middleware it's got data stores it's got multiple it's got ORM integration caching like a lot of those things don't come off in that sort of stuff don't come with fast api which is both a good and a bad thing right like if it comes with
it but it's not what you want then it's just a hassle to battle against all the time yeah but
that's how i sort of perceive Litestars it's it's like fast api with more options and like more stuff included.
- I know.
- It is interesting.
Yeah, it's definitely interesting.
- Yeah.
- All right, also, also interesting is our sponsor.
Sentry is back and I want to tell you about them.
So this episode is brought to you by Sentry, of course.
It's been incredibly valuable for tracking down errors in our web apps, other code that we run, that's web apps, APIs, even the Talk Python mobile apps use it and send in errors when something goes wrong for somebody in some far flung place in the world.
Ian, I've told you the story more than once about how at Talk Python, I learned one user was encountering a bug through Sentry.
I fixed the bug and I let them know before they contacted me.
It was pretty wild, right?
Yeah.
So how does this work?
I'll walk you through a few simple steps on how you might add error monitoring and distributed tracing through some kind of e-commerce app that's got a JavaScript front end, Flask back end.
So if it's Flask on the front, React, sorry, Flask on the back end, React on the front end.
You wanna make sure there's no errors during some checkout process for an e-commerce page.
For me, anytime money and payments are involved, I always get a little extra nervous writing that code.
So here's what you do.
You enable distributed tracing and error monitoring in both your Flask backend and your React frontend.
Then you want to add enough context
to that frontend and backend action so they can be correlated.
And to do that, you enrich the spans, a Sentry concept with business context.
So in your React checkout, You wrap the submit handler in a start span and add information to that.
Then you want to see the requests.
You build a real-time Sentry dashboard.
You spin up one using span metrics to track key attributes, part size, checkout duration, and so on, giving you a single place to see both performance and error data.
That's it.
When an error happens, you open up the entry on the error on Sentry and you get end-to-end requests and error tracebacks and so on.
They also have a new product called Seer, which is C-E-E-R.
is a thing that looks at your app and uses LLMs to understand what's going wrong and possibly even suggesting, you know, here's actually what's causing that bug and it could even potentially do a PR and help you fix it, things like that. Really cool. So it's not just looking at the error, but even, you know, going further than that. So if your apps and your customers matter to you, you'll definitely want to set up Sentry like I have over at Talk Python and Python Bytes and so So visit pythonbytes.fm/sentry and use the code pythonbytes, all caps, just in a word.
That's pythonbytes.fm/sentry.
Use the code pythonbytes.
The link is in your podcast player show notes.
Thank you to Sentry for supporting the show.
Awesome.
Over to you, Ryan.
Yeah.
Sleeping on the job.
Sorry.
So for the next topic, I want to follow up from last week.
So just last week, I think it was last week.
Yeah.
444, Be Gone Python of Yore.
Two thirds of a beast.
That took me too long to figure that out.
So one of the things we talked about was an article called Stop Using Django's Squash Migrations.
And we had some feedback.
So from Bruno Alla said, hey, just a follow up and a plug for one of my own projects.
There is a project called Django Remake Migrations.
So that's really kind of what I want to talk about.
This looks pretty cool.
So it sort of does a lot of the stuff.
But one of the things that I like isn't just there's a tool that you can use to do a lot of this work for you.
You don't have to follow the step by step.
However, it's cool that it talked about the problem.
So it says a Django admin command.
There's a Django admin command to recreate all migrations in a project.
This new one is like squash migrations, but it's on steroids.
So it says the built in squash migrations command is great, but it only works on a single app at a time, which means that you need to run it for each app in your project and on a project with enough cross app dependencies that can be tricky.
Yeah, that sounds tricky.
So this command aims to solve this problem by recreating all the migration files in the whole project from scratch and mark them as applied by using the replaces attribute.
I don't know what that does, but there's some caveats like all migrations are marked as one as replaced once.
So I'm glad I'm using Git when I'm using any of this stuff so I could try it.
And if it doesn't work, roll it back.
But this looks pretty cool.
So I wanted to just shout out to people to maybe try this as well, if you want to try to remake your migrations easier.
While I was looking at this, I was like scrolling down, and it says the package was created with the copier template, and that rung a bell and it looked down and this was a while ago so michael brought up on this show talked about copier but that was back in 2021 so i'm going to go ahead and do a shout out to copier again because it looks pretty cool um copier is a is something like cookie cutter uh but it it's a cli app for rendering project templates but it looks kind of fun um uh so i'm going to check this out. I've got, I have some sort of project template needs coming up. And so I might take a look at this. They have a comparison too. So they're like, this is kind of like cookie cutter.
Yeah. They know it's kind of like cookie cutter. There's some differences here. They've got a table in the documentation. One of the things I kind of like is that the configuration files in YAML format instead of Jason for cookie cutter. I don't, I'm not really a fan of either, but if I got to handwrite stuff, I'd probably rather handwrite YAML files. So anyway, interesting to take a look
at. Nice. I think the biggest difference, other than I think being a little more maintained these days, is that it has, like with cookie cutter, you run a template, it generates a thing, and then you make changes to it, and that's it. With copier, you can apply, if there's a new version of the template, you can theoretically, at least, it has the option to try to apply a migration from the old version the new version.
Oh, that's cool.
Yeah, I think that's its biggest selling point.
Template updates, yeah.
That's actually awesome.
Yeah.
And it looks like it's composable too.
So you can like, if you might have different, like say for instance in a Django, you might have several applications that you would add.
You could use multiple copiers to pull an app, different apps into one application.
Right, add a CRM action or something, yeah.
Yeah, so interesting.
Very interesting indeed.
Cool.
All right.
On to the next one.
This is kind of like the Django show.
And one more Django shout out on top of this, by the way.
I'm going to be doing a happy birthday, happy 20th birthday Django panel with a bunch of the creators in an hour and a half, two hours from now.
Neat.
Now, if you're listening to the audio version, there's a good chance that's already over.
However, you can still either check out the live stream or in a few weeks, check out the Talk Python episode on it.
So keeping with that theme, Django Kronos.
This one's a quick little topic, but it's really cool.
So I want to know how fast my page is loading.
And I know there's the Django toolbar and all that, but here's a nice way to add more information about performance right into your browser.
So it's Django Middleware that shows you how fast your pages load right in your browser.
You simply add it as the first and last thing.
You know, the quick start says add it as your last installed app.
And it has a start and an end that has to be the first and last middleware.
So it gets the full picture of all the middleware actions and all that kind of thing.
I also would recommend saying probably show in production false, unless you really, really want to show in production, something like that.
But the idea is it just shows you how long did your middleware take to run?
How long did your view take to run?
How long did your SQL queries and commands take as part of the middleware, as part of the view?
And then how long did it take total?
And how many queries?
If you see the little screenshots of 7Q, 5Q, 12Q total, I'm guessing those are the number of queries.
One of the really big problems when you're working with ORMs, like Django has, but many, is they have lazy evaluation for relationships.
That can be tremendously slow because the programming model doesn't change if you do an eager query and join two things or you just use it.
It's really just about how the query was structured, not how you program against it.
So you might have, hey, I got a hundred things back from the list as one query, and then I loop over it and I interact with a field where each one of those is doing another query, a hundred more.
So 101 queries, hence they typically called the N plus one.
So you would see something like that.
You'd be like, whoa, the view is doing 107 queries.
I think I got two things, what's happening?
Well, N plus one, some version there probably.
Anyway, if this is interesting to you, It's not super big in terms of popularity, but it's also pretty straightforward and simple.
And yeah, people might like it.
- Remind me, where does the information pop up?
Is it in the browser when you're developing or something?
- I think it's at the bottom of the page.
I haven't installed it and tried it, but it's somewhere in the page as part of it.
- Okay.
- Yeah.
So basically, I believe what it does, it actually gives your template, your Django template, these pieces of information and you show them how you want.
So it gives you middleware CPU time, SQL time, view, count total time.
Basically the stuff that was on the screen.
So you can put it in.
It provides it as data values, and then you would put it into your view as you see fit.
Right.
I believe that's how it works.
Okay.
Cool.
That's neat.
Indeed.
Well, those are our topics.
I have a little bit of an extra.
Go for it.
All right.
I'm going to go back in time a little bit.
And so Test and Code is a podcast I started in August of 2015.
So it's August.
So it's now, it's August 20.
It's almost two days.
In two days, it'll be like 10 years.
I think that's enough.
I'm looking at like episode two.
Episode one was terrible.
So I deleted it a long time ago.
So episode two is a pytest versus UnitTest versus Nose.
And I didn't even capitalize pytest correctly.
That's bad.
And Nose is just, if I were to redo this, it would just say, don't, just pick by test.
There's one option, really.
Anyway, unit test is fine also, but let's get real.
Don't use Nose.
So what is this?
Why am I bringing this up?
Well, I just released on Friday, episode 238, So Long and Thanks for All the Fish, where I announced that I am no longer doing testing code.
So closing the book on that chapter.
I listened to that episode and yeah, I think what I'll say is congratulations.
10 years and 238 episodes is quite a run and those things will be around.
People can listen to them and enjoy them.
Yeah.
So that's another thing is I'm seeing.
I'm not sure how long I'll leave it live because podcast hosting is something you have to pay for.
So I am.
You know what?
I say you take it, write a little web scraper and just generate a static site and just leave it there.
that's not something I might be able to give you work how about that actually so that yeah but the
point was to remove work from my plate but you know we'll see all right can't leave that up in the air um all right what you got for us do you have any extras yes I have some extras let me get it ready
so we have python 3 13 6 big question will this be the final 3 13 before 3 14 probably not but It's plausible, right?
We're talking October, which is sadly not that far away.
Not ready for rain.
Not ready for it.
Anyway, 3.13.6 is out.
And there's actually a lot of changes.
If you flip through the library, I don't know how many pages that is, but we're talking a lot of pages.
So there's actually a ton of changes here that you might want to check out, you know, like little security fixes and other stuff.
Does it have that zip?
There was some kind of zip issue where you could trick it into do.
And I don't think that was in Python.
I think that was in pip.
And uv also had it.
So update your uv, by the way, folks, as well, which is uv self-update.
Easy enough.
Anyway, this is out.
Because of our sweet Docker setup, I just did a rebuild on Python Bytes.m.
And it said uv install Python.
And we have 3.13.6 powering everything all of a sudden.
Very nice.
Anyway, quick and easy.
Yeah.
on top of that the final 13 the final countdown i was just listening to that song uh i have this
really cool script and i think this is kind of it's kind of interesting and please don't write me and tell me other things are out there that do this because i know there are some that sort of do this but it's interesting in and of itself but it's also interesting as we get better and better llm and agentic coding tools i just say instead of just like depending on something that has 100 features and I'm going to take one or two of them and then deal with that. I just want this one thing. Could I just ask to have that one thing created? The answer is probably yes. So I wanted something that would auto activate Python virtual environments built with uv, named like I like, exactly as I navigate around my shell. So I asked Claude, I think, something like that. And it said, sure, here's a cool little bash script that as you enter a folder that either itself has a virtual environment or somewhere up in the higher hierarchy of it as a virtual environment it'll just activate it and if you leave that portion of the directory tree it'll go back and unactivate it and i know that dur env does some things along these lines but like i said i just like i think it's really cool you can just say really all that needs to be is like 35 lines of bash and then it never changes so i put up i decided someone was like oh that's really cool is that happening i'm like i'll just
put that up as a gist and people can check it out i like it also something small that you can change if it's not quite what you want, change it.
Exactly.
I'm not looking for something that solves every problem for every programming language
in the most.
I just want this one little feature.
And I don't really, to be honest, I don't know enough Bash to do this really well.
But guess what?
Either chat or cloud sure knows it.
And it took care of it.
So I'm really enjoying that.
Yeah, I'm totally going to use this, although I'm going to change venv to.venv because Brett - The Canon convinced me that the dot is good.
- I got tons of respect for Brett, but not my thing.
I want to be able to look either via LS or in the macOS Finder and see that it has a virtual environment.
And you can if it's a dot, right?
So anyway, fair enough.
I want to be able to look at it and go, yep, it absolutely has a virtual environment, right?
'Cause that tells me what my next action needs to be.
All right, I just, I spent a long time this summer writing up this huge long post.
I don't know if it'll actually tell us how many minutes of reading time it is, if I ask.
24 to 34 minutes of reading time for this article that I wrote.
Okay.
And it's called The State of Python 2025.
I wrote this in partnership with JetBrains.
And it takes the PSF JetBrains survey results and does like a ton of analysis on it and predictions and concrete actions people could take based on the trends that we're seeing and so on.
So I'll put that here now.
I think I might make this one of next week's items and we can dive into some of the trends and recommendations and you can tell me how I'm wrong or right.
But it just came out this morning, so I thought I'd go ahead and just throw it out there as an extra for now.
Cool.
Yeah.
Next, if you run local LLMs, as I do, and there's a really interesting option, you can now run OpenAI's.
Well, first of all, hey, guess what?
OpenAI has a public open weights model you can use and you can run it locally.
So I'm running here in LM studio in developer mode and programming against the GPT OSS 20 billion parameter model.
How cool is that?
That's pretty cool.
Yeah.
So I have some,
maybe, I don't know.
It's super cool.
I have some other things that I created, like little utilities.
I'm like, Hey, I want this utility to work and it needs an LM.
And I knocked it out real quick in combo with some agentic coding.
And it was using when, which was pretty good.
But then when this came out, I'm like, let me try this and see if it'll give me better answers.
Sure enough.
So now I'm just running this locally on my Mac mini and talking to it.
And it's pretty good.
So that's a cool option.
You run it in Olama or other places as well.
And finally, just remind people that we just released the Just Enough Python for Data Scientists course for $29 over at Talk Python.
So you're getting started in your data science journey or you feel like you've been doing it for a long time, but you just don't quite have the software engineering techniques and tools and so on.
Check this out.
Just talkpython.fm.
Click on courses.
Be right there.
That's it from extras.
Awesome.
That's all over extras.
Do we have, do you have something funny for us?
I have a quick follow-up before we do from Pat Decker says,
I saw your post on Bluesky.
Listen to 238.
I agree with Michael.
Congratulations on 10 years, Brian.
Thank you.
Thanks, Pat.
Indeed.
Okay.
Yes, we have a joke.
Let's check it out.
This one, you know, people don't like if I, they don't like generally when, when one language bashes on another.
Well, some of them do, but not, not generally.
So keep folks, before I show you this joke, it's supposed to be lighthearted.
Please don't, Don't email us, tell me.
So the joke is, Python is better than Java, says someone.
Another person says, prove it.
So the original person fires up Python, creates two strings, one named Python, one named Java, and then asks, as writing in the interpreter, Python greater than Java as strings?
True.
True, says Python.
It's greater.
Yeah, sure.
Truth.
It's true.
There you have it.
Anyway, I just thought that was funny.
Yeah.
It's too bad that Python doesn't have a better operator.
Not necessarily greater, but just better.
Exactly.
Well, there it is.
Yeah, that's the joke.
All right.
Cool.
Well, thanks again.
Thanks, everybody, for listening.
And see you next time.
Yep.
See you later.
Bye, all.