Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 439, recorded July 6, 2025, and I am Brian Atkin.
And I am Michael Kennedy.
And this episode is sponsored by Sentry. Listen to their spot later in the show. Thanks, Sentry.
Also connect with us if you'd like to send us items or just say hey.
We are on Blue Sky and Mastodon, and Michael's even on X still.
So the links to all of us are in the show notes and at pythonbytes.fm.
And also speaking of pythonbytes.fm, why don't you head on over there and sign up for the mailing list because we will send an email to you soon after, hopefully soon after, we release the episode and we send out all the links for everything we cover plus extra information and some background information.
It's really good.
We're pretty proud of the email.
So please sign up for that.
And if you'd like to watch us live or just watch the video post live, after live, whatever that is, the afterlife, no, later on, you can go to pythonbytes.fm/live and there's a link to our YouTube stuff.
So that'd be awesome.
So thanks.
Let's kick it off, Michael.
Let's do it.
All right, so I want to start by saying thank you.
TY, I don't know if it means thank you or not.
TY, the type checker, and also prefix this, Brian.
This is kind of going to be the astral show, just so people are aware.
Yeah.
There's
a couple of topics that we're going to cover, and this first and second one comes to us from Skylar Casco.
So thank you, Skylar, for sending this in.
We always appreciate when people are like, hey, have you seen this?
Probably no.
Sometimes yes, but probably no.
All right, so I want to talk about ty from the Astral folks.
TY is very similar in what it brings to the table is what Ruff did.
So, you know, Astral, they make uv, Ruff, and now ty.
And Ruff didn't fundamentally change how we check our code, right?
We had black, which honestly kind of did, and a bunch of tools that that brought together.
But the real difference here was that rough makes linting almost instant.
And it's like, when you run rough, you got to double check and make sure it's actually on the directory.
You're like, did that, you know, I just hit enter and it's done.
But there were 20,000 lines of code.
Like, how did this, did it actually do anything?
I'm not sure it did anything.
But in fact, it did.
And it's very similar with ty, but for type checking.
So we've had type checking, type checkers like mypy and so on.
But they've really struggled on super large code bases.
And being faster in general is also really nice, right?
So we've talked about ty before.
I've actually had Charlie and Carl Meyer on Talk Python To Me, and we dove into it.
So if you all want a super detailed dive, you can go check that out.
But what is the news?
The news is the documentation for ty is up.
So if people want to check out the docs and learn more about ty, They can go over to docs.astral.sh slash ty.
And there's even an online playground.
And of course, there's a bit of a crossover here in the sense that you can say uvtoolinstallty to have astral installty, just like I do.
Or if you just want to simply run it and say uvx, and that'll install it in like a ephemeral virtual environment sort of thing.
But there's also an online playground.
And this is pretty interesting because the online playground here is written in WebAssembly.
So it's ty running against your Python code in the browser in WebAssembly.
So that's quite neat as well, but that's not exactly the news.
The news is the documentation is up.
And along with that, they also have unrelated to ty exactly, but in the documentation from Astral side, migrating from a pip to a uv project.
And it's a walkthrough on how you might go about using uv in its idiomatic way, I guess you would say, right?
For example, like if you use pip, you probably use pip and pip compile to generate a requirement stock txt and so on, right?
How do you do this kind of stuff using UV?
So people can check that out as well.
Yeah, I really like the migrating thing.
I actually read through it and if you're not migrating, if you're just gonna use uv, I would not recommend reading this because I actually got confused a little bit.
I've already moved on, but yeah, uv all the way.
So
what am I going to talk about?
Let's see.
I am going to talk.
Let's just, we have a little bit of news from uv, from Astral.
It's the Astral show.
Yeah.
So I actually picked this up from, oh, Tim, Tim, Tim.
I'm blanking right now.
Tim Hopper.
Sorry, Tim.
Tim Hopper and his Python developer tooling handbook, he posted the uv build backend is now stable.
And actually, I'm pretty sure I heard about the uv build backend, but I don't remember playing with it.
So I played with it.
So the announcement is that for about a year, uv has had a uv build command, and it's kind of like an alternative of, What do we have?
Hatchling or Flit or something like that.
But now it's one of those build backends for PyProject.TOML based projects.
And it's pretty exciting that uv build is here.
So that's the announcement.
And it's also that it's stable and also fast.
So Charlie Marsh posted that, he posted that it's 10 to 35 times faster than alternatives.
So what is he looking at?
He's looking at comparing uv to hatchling, to set up tools and to flit the thing that we don't have an answer on is what is he timing because this is just sort of uh posting the times for what he calls the back end sync that is not a command that you can send to hatchling or flit and you actually hatchling isn't a command line thing so i mean i'm not sure what's going on but i believe him that it's faster uh so it would be Kind of cool to find out what he's measuring anyway.
But uv build is now available and that's cool.
I'm pretty excited about that.
Along those lines, if you're switching kind of along the lines of with that, that Michael brought up, if you're switching to uv and you'd kind of like to know what's so great about all of this, I recommend checking out Hinnick's video series.
So he just released the second part in a uv series.
And this one is making Python local workflows fast and boring in 2025.
And he's talking about uv workflows.
So it's a great video.
I mean, I assume it's a great video.
It's 40 minutes long.
I haven't actually watched it yet, but I watched the first one.
Yeah, his videos are great.
So yeah, check them out.
Indeed.
And Brian, our sponsor, also very great.
Let me tell you about them.
How about that?
That'd be great.
Yeah.
So this episode is brought to you by Sentry.
And I'm a huge fan of Sentry.
use them with all of our software.
And they've been incredibly valuable for tracking down errors in our web apps and other code that we've run.
I think everything's fine.
You get a notification.
There is an error.
You're like, hmm, I guess that is a problem.
You know, and it doesn't have to be in your code.
It could be something like you've upgraded a dependency and now there's some kind of problem that's occurred.
I've certainly got that notification as well.
And I've learned about users encountering bugs over at Talk Python and for the courses and stuff.
And then I'll reach out to them and say, sorry, I saw you ran into this bug that we fixed.
And they haven't even contacted me yet.
They're like, okay, awesome, kind of creepy, but amazing.
No, it's good to know, right?
Right away and be able to be on top of things.
So how might you set this up?
Well, they've been adding more and more capabilities and features.
So I want to walk everyone really quickly through the idea of setting up monitoring and distributed tracing for a Python web app, which means like across API calls or across the JavaScript front end and the Python backend, you can correlate errors.
So you can see like the whole operation, right?
So let's imagine we have a Flask app with a React front end and we wanna make sure there's no errors during the checkout process.
I don't know about you, but anytime money and payments are involved, I get a little extra nervous writing that code.
So knowing what's going on, very good.
So you start by enabling distributed tracing and error monitoring on your Flask backend and your React front end, Super easy, just a few lines of code.
Next, you wanna add enough context to the front end and back end actions that you can correlate them into a single request.
So add a little bit of information to like know what's happening.
You enrich the spans, this is the sentry construct across these calls with business contacts like a session ID or a user or whatever.
And then you can see the requests live in a dashboard.
So you build a real-time sentry dashboard.
You spin up one using span metrics to track key, attributes like cart size, checkout duration, and you have just one pane for performance and error data.
And that's it.
If an error happens, you open the error at Sentry and you get end to end request data and error tracebacks to easily spot what's going on both on the JavaScript and the Python side.
So if your app and your customers matter to you, you'll definitely want to set up Sentry like we have.
Visit pythonbytes.fm/sentry and use the code PYTHONBYTES, all caps, just one word.
That's pythonbytes.fm/century, code pythonbytes.
The link is in your podcast player show notes.
And thank you to Century for supporting the show.
Awesome.
I want to move on to something that is sort of, I guess, maybe nerdy, Boolean expressions.
As if the show wasn't already nerdy, right?
So we've got Trey Hunter's article.
And I kind of love what Trey Hunter's been doing lately.
He's been writing some good stuff.
So refactoring long Boolean expressions.
And there's lots of reasons why I love this article, but we'll just walk through a little bit of it.
First of all, he's introducing people to Morgan's Law, which I love.
So here's the idea.
You've got a Boolean expression, and his example, it's a pretty good example, is if you've got events and users, you've got sort of a web app sort of a thing going on, And you want to check to see if a user is verified.
And the event they're looking at, the date of the event is in the future.
So it's greater than now.
And maybe it's not full.
So maybe you're doing like people signing up for something.
And this is a reasonable Boolean expression.
But how do I, it's not that readable.
So let's try to make it more readable.
And that's what he's looking at.
Here's how to break this up.
And one of the things that I love about this is this seems, It's just sort of basic math.
If by basic math, your math includes Boolean algebra and things like that.
But a lot of people come from Python, not from a CS background, which is totally valid, of course.
But how to manipulate and and or.
When I say Boolean expression, it's just truthy things, true and false things with and and or and things like that.
So he walks through some of the things you could do.
You could just split up the lines.
So you could just use parentheses around your expression, and then you can split the different expressions up on multiple lines.
And then he's also saying you could either do it like this, where the and at the beginning, or you could say user verified and, and then go to the next line.
The event date is less than, or is greater than now.
And you go into the next line, not full.
Okay, so you can put the and in the beginning or the end.
It's really up to you.
However, I didn't realize that PEP 8 had made a call on this.
PEP 8 recommends putting things like and and or at the beginning of the line.
And just so it's consistent.
I don't know if it really matters, but I guess I kind of agree that it's a little more readable this way.
So I like that.
The other thing that's kind of neat about this that we will lose a little bit is that Boolean operations and expressions are short-circuited in Python.
So with the ands, that means that all of these expressions have to be true for this to be the entire thing to be true.
So if I get to user verified and that's false, if the user is not verified, I don't evaluate the rest of it.
I just know that this is going to be false that Python does.
And so Python won't run it.
Hold that thought.
It's going to make sense later.
One of the things we can do to make this simpler is to just go ahead and evaluate all of the expressions and assign those to variables like user is verified and then combine those with ands.
That's easier to read. But if if any of these evaluations are lengthy things, we don't want to do this because because the we lose the short circuiting.
We've evaluated all the expressions and then we short circuit just in the ands expression and doesn't we don't get that.
However, Trey says, you still can get this if you throw everything in functions.
So he's got these little is verified, is in future, things like that, naming the expressions into different little functions.
And this is usable.
I don't think this is that readable, though.
But that's just me, I think.
He makes it kind of all on one line, so the entire function on one line.
I think that a lot of people style guides would kind of hate that
but you know what I think it looks really neat the way he's got it written like this where it's just one line you kind of call the function as
the test but
here's the thing if you run rough against it keeping it the astral show or you yeah or black
command alt l
it in pycharm it's going to wrap it and put spaces like it's just going to keep wrecking it so then you've got to write wrap that in a no format command like directive and then you're like uh okay maybe it's too much to bridge too far but yeah i get it
okay yeah
so
the these these are cool methods um and then let's jump through the math part the math part is kind of kind of nice uh that um is the there's you can distribute knots and and stuff. And so if you're thinking that either a few things are like A or B is true, and I want to make sure that that's not the case, whatever that means, that's the same as not A and not B. So there's these distributive properties of and and or M. And he shows both whether you want neither one to be true or what? Never both. You want one of them to be true or neither, but not both so those sorts of things to distribute why does this matter it matters because like this he shows an example as a multi-line expression and that is confusing to have a not and then a parentheses of a bunch of stuff but uh if you do uh not one thing and not another thing and not the third thing that's a that's actually pretty easy to read um i think so this is a cool cool intro to to Morgan's law from for some people breaking things up so
anyway yeah very nice this is the kind of stuff I like to geek out on as well like how many how many like variations or how can you restructure stuff to be so much more readable and yeah it's good yeah
and I encourage people to look all the way to the end because you have to you gotta give it to him that some of this stuff is really hard to understand to glance at but because like the first one the knots just sort of hidden up at the top but anyway yeah
all right yeah I would add that you know even though you might evaluate two or three things performance usually is way less important than readability
maintainability and so
on yeah i have
to say maybe
but there's like one sorry maybe there's like one or two functions but the rest of them performance doesn't matter go ahead bro yeah
exactly don't pre prematurely optimize because i have to admit that the uh the example that i sort of poo-pooed on because it's um doesn't allow you to short circuit of just naming the expressions. I do this all the time for, for quick things because it's very readable to do this. So, yeah. Yeah. And we have profilers that can tell us if
it's a problem, right?
Yeah. Usually it's not. All right. What you got for us?
I have just an extra. I have some extras to throw out here. Oh wait, no, I have one more item, don't I? And then, then I have an extra.
So my last main item is this thing called FastAPI Machine Learning or ML Skeleton.
So this is speaking to all the data science folks out there that have some kind of data science model or engine or something they want to expose as an API, right?
Maybe you're not a web developer or you're not really writing a lot of API type of things.
So which framework do you choose?
How do you structure it and so on?
So this person whose name I honestly don't know is just 8beck, the number 8beck, B-E-C, created this thing called FastAPI ML Skeletons.
So what it is, is it's a template that you can start with and adapt for serving machine learning models in a production-ready, fast, and easy way powered by FastAPI.
But it doesn't exactly have to be machine learning models.
Anything that's sort of data science that you can put behind an API, I think would fit here.
So it's tested with talks and it has example code for that and super easy to get started.
There's a few, I'll come back to some, a few little interesting tips and tricks, but it comes with a sample machine learning model that predicts home prices, right?
Just to have something concrete to work with.
And then over here, come through and you can go to the API and they're pretty well structured, right?
It uses like API router and so on, instead of jamming it all into just one file, like so many of the demos do.
You're like, oh, look, it's only 10 lines of code.
You're like, yeah, but if you keep expanding that way, it's going to be terrible.
It comes with like open API documentation by using Pydantic models for all the exchanges.
It's nice and typed and all these things.
So if you're getting, it's not super new, but if you're getting into it, I ran across this and I thought, you know, this is pretty neat.
Maybe this will be real valuable to some folks.
And Brian, I learned something because when it says, how do you start your app?
Well, what you do is you say set dash a, and then you source your env file, which is your environment variable settings.
And you set plus a, I'm like, okay, what does that do?
Yeah.
What does that do?
Are you familiar with this?
No,
I wasn't even, I'm like, what in the heck is that?
And that alone might be worth price of entry for this, like learning about this project.
So what set-a does, it says anything that you basically set as a variable in your environment, basically stays set for you, which is pretty cool.
So here, what's the right?
So set-a turns on the all export option.
Set-o all export.
From that point, every variable you assign is automatically exported to the environment.
So if you just said set dash a then like foo equals bar, then it's as if you had created a script and sourced it and all that kind of stuff.
So a cool way to quickly set some environment variables.
Yeah, I think that's-- so getting more and more.
It came up last week of possibly using DuraN for that as well.
Yeah, for sure.
Yeah, that's a more structured way, right, to do it for sure.
But I'm glad to know how to do it manually.
That's cool.
Yeah, yeah, exactly.
Like if you're creating a little alias or something, right?
You could put that at the beginning and just set a bunch of variables or whatever.
Pretty sweet.
Anyway, if you're looking for a FastAPI skeleton to get started with, yeah, it could be pretty cool.
All right.
Do you want to do your extras?
I only have one extra.
Yeah, sure.
Me too, because I tried to jump ahead anyway.
Okay.
So this one comes to us from Wei Lee.
And I'm going to cover this as sort of a gateway to like talk about even more stuff than like it's pretty specific, but it's an example of something that's pretty neat.
So back, keeping with the astral show, Ruff has a bunch of rules for how your code should be formatted, right?
And then things you should do, things you shouldn't do, maybe certain things are deprecated.
You should stop doing them, right?
It hurts when I do this.
Okay, well, stop.
But there are things like Airflow specific rules.
So Airflow is a workflow engine type of thing.
And if you pass, where's the settings?
I guess I don't have it in the docs there, but I have it in the show notes.
So if you pass certain commands to it, such as select Airflow 3, when you run rough check --fix, it will rewrite old code that was bad into new code automatically having to do with the Airflow framework. For example, in Airflow 2, you used to say from Airflow.models import DAG.
In Airflow 3, you say from Airflow.sdk import DAG, and similarly for other imports. So if you were to say that, it will actually rewrite the import statements to use the non-deprecated style. Cool, right?
Yeah.
Well, if you scroll down a bit, you can see there's similar things for FastAPI, bringing our two topics together, right? So there's certain things that have changed with the way you work with like response model or annotated or so on. So it'll go through and it'll change all those.
Do we have a Pydantic? No, no Pydantic. We should have a Pydantic because that one changed and it's used everywhere. But anyway, there's like framework specific stuff that I think is pretty neat in the rough rule set.
So thanks to Weave for sending that in.
And yeah, you do Airflow or FastAPI or other things.
You can turn that on to do migration across like semi-breaking changes.
And I actually would just encourage people to look through the rough rules because a lot of these things used to be different tools and are different tools, but rough has pulled in rules and checks for lots of different stuff that maybe it's worth perusing around on a regular basis to see what's around and new to see if if maybe you should be checking things a little bit more closely yeah
like they also have like numpy and pandas uh rules and so on watch it a prequel
i just noticed that there's a pie
test section i haven't looked through that i'd like to see oh very cool
yeah so
one of the things that's neat is um when you go into these um these rules and stuff each one of these it's not just oh here's the rule but it actually tells you does, why you should stop doing it, an example how it's bad and what it fixes. So this is actually a really good resource, which I've actually covered the rule set before is like, hey, you should go check this out just to see like what is going on with these, like do it this way, not that way.
But yeah, the framework specific stuff and like pytest specific stuff is cool.
And that's one of the also one of the reasons why they don't recommend turning everything on, because that's ridiculous. If you're not using
Airflow,
you don't need to turn on Airflow.
So, yeah, yeah, exactly. All right. I have something completely unrelated to Python that I just wanted to bring up because I'm going to head to Oregon Country Fair this Friday and I'm totally excited about it.
So,
oh, that's awesome. What is it? What?
Don't you live here?
Okay. I do. Oregon Country Fair is a three-day celebration of art, music, and food in Veneto, Oregon once a year, and it's been going on since 1969. They have their own property. Well, they originally rented it or something, but now they own the property or have for a long time, so it can't get shut down.
Anyway, it's not a county fair.
It is a country fair.
So it's music, art vendors, food, and all waste-free.
So the only garbage that they take out is stuff that people bring in.
You can throw away your candy bar wrappers if you're there.
But all the food vendors are all doing containers that are biodegradable.
So it's a fun event.
Yeah, very cool.
I missed it
last year and I'm going to go this year.
So some, some big names.
Cool.
It's fun.
All right.
That's our extras.
Are you ready for a joke?
I'm ready.
This is a short joke, but I just can't stop giggling about it.
I saw this Mike at, was it on blue sky?
I don't know.
No, I'm asked it on.
So somebody named Mike sec equals official.
So he said it's based on an idea of somebody else, Daedalus, and pending the release of some kind of official sticker to use.
I now have applied a handy reminder label to my keyboard.
What is the label?
Front towards enemy.
That's amazing.
So it's a picture of the keyboard facing away from the developer.
Yeah,
towards the computer
or towards whoever you're talking to or whatever.
So front towards enemy.
Exactly. PM maybe.
And if you're thinking, I've seen that before.
Wherever I've seen that, Front Towards Enemy, that's usually on the front of the Claymore mines that are directional mines.
So,
yeah.
Oh my gosh. Crazy. I love it.
All right. That is the show for us today.
Awesome.
Thanks for being
here as always. Bye.
Yeah. Thanks, Brian.
And I want to encourage people who are listening, if you're not subscribed to the podcast, subscribing to Podcast Player.
And if you're watching the YouTube version, be sure to subscribe and like the video.
Helps a lot.