Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds and mine. And this is episode 417, recorded January 21st, 2025. And I'm Brian Okken.
And I am Michael Kennedy.
And we're excited about this show today. And nothing ain't nothing going to bring us down.
So but before we get started, I want to thank everybody that has supported us through
Talk Python training through pythontest.com, the courses through ByMyBook, our Patreon supporters,
of course, you rock. And of course, many of the sponsors that have sponsored us in the past.
And we love them too. But we also love people that support us directly.
If you'd like to send us topics, please do so through there's contact form on our website.
But also you can send them to us at Blue Sky or on Mastodon. And those links are in the show notes.
And if you are listening to this, thank you. And also share it with a friend. And if you'd like to
join us live sometime, check out pythonbytes.fm/live to see when the next episode is going to
be filmed, filmed and recorded. And you can join us and comment while we're going live. And thank you
also for people that subscribe to the email newsletter. If you go to pythonbytes.fm, you could subscribe there
as well. And get the list of all the topics directly in your inbox so you don't have to go look those up.
Yeah, we're evolving the format of that a little bit, trying to make a little deeper analysis,
but also skimmable. And yeah, it's a huge resource. I think it's great.
Yeah.
People listen as well, but it's also nice to just have that written down in one place.
And we cover lots of great topics every week. And what is our first topic this week, Michael?
The first topic will be the LLM catcher. The name, not terribly descriptive of what it actually does,
but here's the deal. I'm sure everyone has done this at this point. I know I've done it recently as I was
yelling at the Bodo 3 API because there ain't nothing as frustrating as a little bit of a little
Bodo auto-generated, no comments, no documentation, no idea what parameters go in it. Anyway, you might
take those errors and pass them over to an LLM and go, please, dear chat, co-pilot, anthropic,
whatever. What is going on here? What am I missing? Right? And it's super helpful. But this
project is a little bit different. It's like a gateway to those types of things. So here's what
you get. If there is a crash, obviously you have stack traces or tracebacks, depending on the language
you and how you say it. They describe it here as the unsung villains of debugging. Why wrestle with the
wall of cryptic error messages when you could let LLM catcher do the heavy lifting? So here's the thing.
You basically, I'll go down here somewhere. What you can do is in your try accept blocks,
you can say, you know, given an exception, diagnose or dot diagnose, passing the exception,
and it will pass those details over to various LLMs and say, help me understand this and print out a
message that will show me how to fix it, not just traceback. Okay. So I don't know if I can find it.
Yeah, I think it's pretty dope. I would not use it in production, though you could, you could,
if you want your logs to have messages about here's actually what happened, it's your debugging
sidekick. So what you do is you can run OLAMA locally, and that's the default, or if you give
it your open AI API key, it can pass it over to whatever level of model you possibly have. You know,
it'd be awesome if you could have a one mini or something like that, diagnose it over at ChatGPT.
So there's different ones that we'll work with. But basically, when it gets an exception,
it says, hey, I'm working on this thing with FastAPI, and I get this exception, help me figure out
what's going on. So the OLAMA one is a local free just running your machine version, open AI, well,
we know, all know about ChatGPT, right? So you can put it as a decorator on a function, you can manually
do it in a try except block, or you can even register a global exception handler. So anytime
a global exception happens, it's uncaught in your system, it'll diagnose it has both async and async
API, and you can set it up through environment variables. So, you know, it shows you like how to
pull down the qwen 2.5 coder model for OLAMA, which is pretty excellent. And just off it goes,
look at that. So you've got your diagnoser.catch on a risky function, or in your try except block,
you just say, you know, diagnose or async diagnose, because you know, it's going to run for a while,
it's going to make an API call either locally or out to ChatGPT. So you don't want to necessarily
block your system. So you just make a little async await, boom, off it goes. Yeah, there you go.
That's pretty much it. You can get formatted or unformatted information back. So if you need plain
text to go in some kind of JSON field, you can do that. Or you can get it with
proper formatting to make it more readable. What do you think, Brian?
I'm going to withhold judgment on this until I give it a shot at some point.
But yeah, you can even specify the temperature, aka the creativity you want the model to apply to your
analysis. That's funny. Yeah, it's an open AI thing.
I kind of like it to like, on any exception, just upload my entire code base and rewrite my code to
fix the error. Exactly. Don't diagnose it, just fix it. Why am I even in the way here?
Yeah, so look at it. Yeah, you can even do the full on 01 model of ChatGPT, which is like the really,
really high one. Is that the $200 one?
That's the $20 one, but you only get to call it 50 times a week. So not too many errors. If you get the $200 one, you can call it all day long.
Yeah, I'd like people to get the $200 one, put this in your CI and do it over all versions of Python so that we just fill up all of the data.
And then we'll get an announcement of, oh, the entire West Coast is blacked out because we broke the power grid.
Yeah.
But anyway, I think it's interesting, right? Just plug that in.
Yeah, it looks like it might be kind of fun.
Yeah, it does look kind of fun. And this was recommended by Pat. So thanks, Pat, for sending that in. Pat Decker.
Oh, and Pat's here. Thanks, Pat.
Yeah.
Over here.
Well, I kind of want to talk about bad packages a little bit.
Like no Christmas presents for them or what's going on?
Yeah, no wrapping paper. Actually, we are talking about wrapping. So I want to talk about the Python packaging index and malicious stuff. So let's scroll down here.
There's in the in the there was a security and safety engineer first year in review. This was from Mike Fiedler and and he talked about a lot of stuff.
But one of the things he talked about was quarantining. And this came out in August. But but I just am catching up.
So it's like if they catch COVID or what's going on.
No, it's it's you know, it's like bad packages. So if somebody says, you know, there's a there's there's malware in a in a package shouldn't be there.
What do we do with it? And they used to like have the option to investigate it and then yank it.
But it just sort of makes the whole thing go away.
But there's a new process. And they just recently at the end of December wrote about it.
And there's it's called Project Quarantine. And in this we're linking to an article that really talks about it.
So if you're if you're worried about malicious packages and you're curious about what IPI is up to, go ahead and check this out.
I'm not going to go through the whole thing. However, it is kind of interesting.
So the idea is if we jump back down to like future improvements and automation, hopefully we'd have some sort of automated way.
Like let's say a couple people report that a package has malware in it.
Administrators of PyPI can go ahead and and and somehow have some litmus test to say or some thing to say rather quickly.
Let's get this get this get this under control.
And the quarantine doesn't delete the whole thing.
It it puts the there's an API simple API that an admin can go in and say, hey, we're going to quarantine this project.
And the package goes into quarantine.
And at that point, there's a bunch of the bunch of stuff happens.
The it's not installable, but the owner can still see it.
And the only owner can can make I don't know if they can make changes.
But, yeah, it's not modifiable while it's in quarantine, but they can see what's going on.
Administrators can look at it and and determine whether or not there really is malware there.
And possibly it's possible that, you know, we might have some bad actors reporting packages.
So we don't want people to like report stuff that's fine and have things to remove just because they're angry about it or something.
But that hasn't happened yet.
So this has been in place for a little while.
And looking at the statistics, it's been let's see since August.
They put this in place.
There's been 140 reported packages and they've been gone into quarantine and only one of them exited quarantine.
And it's because why was it the there was obfuscated code in there.
Then that's a violation of the PIPI acceptable use policy.
Project owner was contacted.
They fixed it because they just, I guess, weren't aware that you can't do that.
That's a really interesting.
I didn't know that was a policy.
Yeah.
Well, I mean, if you want to ship something that you I know there are companies out there that would like we would like to obfuscate our code, but we still want to make it available.
But we don't do it through PIPI.
I guess don't do it through PIPI.
Okay.
Yeah.
I don't want to pipe obfuscated code.
So I understand that that's primarily a shield that malware hides behind.
Right.
Like, yeah, they'll have a base 64 encoded string of something or other than they'll decode it and execute it.
Right.
And that's it.
Yeah.
So, yeah, there's created some outreach templates.
So the full process, if you're confused or if you have a, this is something, if you get notified by an administrator that one of your packages is in quarantine, they'll probably point you to this anyway.
But, you know, check this out.
I'm glad that they're working on this and we're making the environment easier for PIPI admins to deal with, but also just safer for everybody to use.
So it's good.
Yeah.
Excellent.
Well, you know, I'm sure you're aware of this, Brian.
Testing.
Testing makes your code safer to use.
Yeah.
And I have fully embraced the async lifestyle these days.
You know, I talked about rewriting Python and Quart, the async version of Flask.
And I blogged about that and brought it up on the show, I'm pretty sure.
But how are you going to call APIs?
I'm working on some projects right now that are like all about calling APIs.
And I'm like, oh, my gosh, so many APIs.
This thing calls that, which, you know, so on.
If you can do that asynchronously, that'd be awesome.
And I would say probably the best kind of, I'm a fan of requests, but I want async story these days is HTTPX.
Yeah.
Which has got some basically very, very similar, not identical, but very, very similar behaviors and API patterns as requests, but also has an async variant.
Create the async client and then await all your calls, which is great.
So you might want to test that, right?
Even asynchronously as you're writing code.
That's async.
So I want to introduce people to RESPX, like response X.
Probably is the way you pronounce that.
I'm not talking about HTTPX or response X.
I don't know.
Whatever.
HTTPX.
And what it does is it lets you mock out HTTPX requests.
Super, super easy.
However you like.
So for example, if I want to make a call where I say HTTPX get, and I want to make sure that if that URL comes in, it's going to return some particular value, like a 204.
You just say RESP.same function call with the values.
And then you just say .mock and you set the values or the behaviors that you want it to do.
And off it goes.
That's pretty cool.
Yeah.
And it also comes as a pytest plugin, if you want to roll that way.
So then you just say RESP.mock.whatever and just call the functions.
And then all the examples here, like first line, mock it.
Second line, call it.
But, you know, probably you're testing some function that then internally is using HTTPX through like a width, async width block.
And, right, like there's a lot of layers going down there that you might need to work with.
And so, right, that would be a more realistic example.
You call the mock and then you call your code and then something happens, right?
So that's pretty cool.
You can even use mark.
It probably makes sense of this pytest.mark statement here for me.
What are we doing?
Well, what do you mean?
Okay.
So you got pytest marking it with RESPX.
So the project is to find a custom mark and it's passing in the base URL of foo.bar.
And then within it.
Yeah, you don't have to, I guess, say the base URL, right?
Right.
Because you're just passing it in.
You can, because it's really, it's not that bad.
Not that hard to pass in through markers of variable to fixtures.
So that's what's going on.
I see.
So you kind of pre-pare it with your mark here.
Okay.
Yeah.
Awesome.
Yeah.
And then the, then the fixtures passed in.
Okay, cool.
And that's pretty much it.
There's not a whole lot of, not a lot of to say about it.
But if you need to mock out HTTPX, instead of using generic mock stuff, you can use this
library that basically has exactly the same API as HTTPX.
Pretty cool.
Sometimes I forget that not everybody has completely internalized the entire content of my book.
Well, we can work on that.
We can work on it.
Yeah.
I learned something new.
Oh, really?
You know what?
If you, I think if this is your next topic, I had no idea about this either.
So I'm about to learn something new.
Okay.
Well, so this is actually something that Rodrigo also learned something new because he marked
it as a TIL for today I learned.
And I kind of love people posting the TILs, but also I'm, I'm personally, personally somebody
that I don't think you need to prefix things with TIL for today I learned.
If you just have a small blog post, go ahead and post it.
I like small posts.
Anyway.
So unpacking keyword args with, or K-Kwargs.
I usually just say keyword args.
Do you have, do you say quarks?
I'm K-W-Args.
K-W-Args.
Okay.
But I know people say quarks, but I don't know.
It sounds like I'm speaking Klingon or something.
I don't do it.
Yeah.
It makes me think of Deep Space Nine with quark.
But unpacking keyword args with custom objects.
So let's say you got, so there's a couple of things.
And we're talking about the star or the double star or the splat splat or double splat.
I don't really want to say it.
So let's say you've got a dictionary and you want to pass that, the contents of the dictionary
as arguments to a function or something.
That's how we often use it, is doing a star star with a dictionary and it unpacks it into
keyword args for a function call, which is cool.
Or you can just do it.
Here's an example of merging two dictionaries with this.
I don't do it.
I don't usually do this much, but cool.
You can do that.
There's a newer syntax where we use the pipe on dictionaries as well.
And that's the same thing.
There's like three or four ways to do this these days.
Yeah, because with Python, there should be one obvious way to do.
And if there's not, there's four.
Unless it's strings, then there's six.
Okay.
So there's a lot of times where doing this star star unpacking is like so cool and convenient.
And but if you have custom objects, not dictionaries, if you have your own objects, what do you want?
How do you deal with that?
Can you do that?
Yes, you can.
And that's what this little TIL is about.
All you have to do is you have to add a keys function to your object or your class.
And the keys function needs to or method needs to return an interval.
And in this case, just a list is an interval, for instance.
And and then the example, he's got a Harry Potter class.
It was returning first, middle and last.
And then a get item that presumably that takes a key and returns something.
And that's all you need.
And then you can you can do this double splat thing.
And it works.
Oh, that's awesome.
And also the example is good also to just to remind everybody that when you're doing the get item to go ahead and do an else clause with a with a key error.
So if people pass in the wrong thing, they get the appropriate exception.
So anyway, thanks.
Yeah, I love it.
Very, very cool.
All right.
For items, right?
That's it, I guess.
You feel pretty extra.
I can see.
I do feel pretty extra.
I got more extras than I had normal things.
So let's jump in.
So let's do it.
Over on python test dot com.
Oh, a couple of things.
I'll just kind of go backwards.
First off, I finally fixed it.
I had X up or Twitter and I don't do Twitter anymore.
So I replaced it with a blue sky icon.
And also on my contact form has blue sky now.
So I fixed those things.
Also, I had like incorrect podcast stuff up.
So I fixed my podcast data.
Testing code and Python bytes and stuff.
Of course.
Anyway, that's not what I really want to talk about.
What I want to talk about is the top pytest plugins.
I've been researching a lot of the stuff in here for the testing code season two.
And I'm relying on with this data.
I'm relying on the top PyPI packages.
And this is an excellent resource.
And it uses BigQuery.
And there was just a new article from the person that created this, Hugo.
He wrote an article about what's going on with this.
A surprising thing about PyPI is BigQuery data.
And it's interesting and also kind of exciting news.
So the interesting thing is he's using the free version of Google Big Cloud or BigQuery stuff.
Whatever you need, a Google account.
You get a few BigQuery queries.
And if you do it too much, they kick you out.
And so at first he started with 4,000 projects.
Then he bumped up to 5,000 projects.
And then 8,000 projects.
But there's more than that.
So he's like, well, I wonder how much I can do.
And so this is a little test that he went through.
I'm going to jump down to the punchline.
And the punchline is that you can do.
He went up to tried a million packages.
And there aren't a million packages.
But it returned 531,000 packages.
And it was the same bytes processed as even just doing one for 30 days.
So it doesn't matter.
It turned out it didn't really matter how many packages to query.
What it was was how the date time, the date spread.
So if he did like five days, it was way cheaper than 15 days, which is way cheaper than 30 days.
And it's relatively linear.
So it looks like what he's going to do is change it so that we get like a ton of package data.
Like as much as we can get.
531,000.
But he's probably going to report that in smaller chunks too.
Because a lot of people are.
Daily or something, yeah.
But a lot of people aren't going to want to see 531,000.
The top 8,000 is probably sufficient.
You really got to zoom in to see them all at once.
So I'm excited because when I'm using the 8,000 data set and the top pytest packages,
there are currently 133 in the top 8,000.
And I'd like to have a bigger list.
So if I've got the top 10,000 or 20,000, I could probably get a bigger list of pytest packages.
Anyway.
So that's it.
It's just an interesting thing if you're doing BigQuery data.
It's the date that is the big effector of the price.
Right.
Because it probably counts the number of downloads for each day or per download individually.
Whereas if there's only 500,000 packages, there's that.
But there's way more downloads than there are packages.
The other thing that might change is, I think is going to change,
is that it cost more to filter on just pip packages.
And now we're getting a lot of UV, people using uv to download stuff from PyPI.
And so he wants to include that too.
So it'll probably, I think he's going to change it so that the data is from everything instead of just PIPs.
That makes sense.
Yeah, it makes sense.
Yeah, it definitely does.
Yeah.
Anyway.
Awesome.
Cool.
Do you have any extras?
I do.
Not too many, but let's do it.
So, oh, and I think it's going to be a good thing.
Dash secure the project.
I was speculating.
I was speculating where, what API it was using.
He wrote in to say, it's going to be a good thing.
JSON API, JSON API at present to query for package vulnerability.
Same thing that pip audit does.
It does work at it asynchronously to try to make it a little faster, but it's just the simple API there.
So that's what that is.
Not something like sneak or some other more advanced threat modeling setup.
And yeah, that's it.
That's all I got for my extras.
All right.
Cool.
How about a joke?
Oh, I've got a joke.
People, if they like puns and stuff, this is going to be good.
It's at angle bracket slash angle bracket code puns or codepuns.com.
So we've all written bad code and I know that sometimes testing will shake out the bugs, Brian,
but do you know why programmers prefer dark mode?
I think this is not totally wrong.
I think we should switch it.
I think it's a foul fallacy here.
Why, I guess, I'll read it as it is.
Why do programmers prefer dark mode?
Because light attracts bugs.
I guess if you're talking moths, but if you're talking cockroaches, it's the other way around.
But here's the thing.
That's a great joke, but you can click more puns and they just keep going.
My love for coding is like a recursive function.
This is not a very good one.
That's fine.
Why did the for loop stop running?
It took a break, semicolon.
How do you comfort a JavaScript bug?
You console it.
I see.
There's a lot of good stuff here.
Because console.log is how you debug that thing instead of bug.
Oh, okay.
Okay.
It's the print debugging equivalent of JavaScript.
I'm not a JavaScripter.
Okay.
Well, you certainly can't console your JavaScript bugs when you create them.
All right.
Why do you not want to function as a customer?
Because they return a lot of items.
Come on.
Anyway, you can go to codepuns.com and click through until they can't take it anymore.
Yeah.
That's probably why you want to see customer because they only return one item.
Oh, that's true, right?
Yeah.
Well, good stuff.
Yeah.
Good stuff.
All right.
Well, thanks again.
Thanks for showing up for Python Bytes.
And thanks, everybody, for listening.
Yeah, you bet.
Thanks for meeting you.
Bye, everyone.