Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 356, recorded October 10th, 2023. I'm Michael Kennedy.
And I'm Brian Okken.
And this episode is brought to you by us. Courses over at Talk Python Training,
the complete pytest course from Brian, Patreon supporters, and find us over on Fostadon.
That's probably the best way to chat with us these days. And also be part of the live show,
pythonbytes.fm/live, usually Tuesdays at 11 Pacific time. And you can also see all the old
versions there as well. So Brian, what are you going to start us with today?
Well, I thought I would start with a, it's kind of going to have a theme of getting information from
from Fostadon, people letting us know. So I saw today a post by the PsychoPG group. So
PsychoPostgres and the post says it feels weird, but it's time to stop considering PsychoPG2,
the present and PsychoPG3, the future. We've entered the time where PsychoPG3 is the present
and two is the respectable past. Update, updated the feature page and a few other resources on the
website to reflect this. So I thought I would check it out. So
Awesome. That's big news. You know, Postgres is clearly the biggest database that people use in
the Python space, according to the survey we talked about recently. So yeah, this is relevant, right?
Yeah. And this is a great library. I've been using the version two for a long time. And I guess
kind of like haven't been paying attention to the three, but it's been out for a while.
So the three page talks about, basically talks about the, it's a new implementation of the most used,
reliable and feature rich Postgres adapter for Python. And there is some differences though. So
the apparently most of two was written in C, but three is written in a combination. So a lot of it's
in Python and some of the speed ups are in C. And so the big announcement really is that there are no,
so we're going to link to both the three page and the features page. And the features page has a nice
comparison of the, of two versus three. So the really, the recommendation is they're still going to
maintain two, but you should maybe think about mostly think about three for new projects. So if you
already have an existing project that's running to go ahead and leave it running with that, I couldn't
find where they're doing it when, or if, or where they're doing announced an end of life. So I don't
think that's even planned at this point for end of life for two eventually probably, but so two has been
around since 2006, three started in first release in 2021, but they've got a whole bunch of cool things
in here. So some of the things I thought were pretty cool was we've got a native asyncio support.
That looks pretty nice. Native support for more Python types, such as enums and Postgres types.
So Postgres, one of the cool Postgres types was a multi-range. So that's supported now. That's pretty
nice. And then I don't know what parameter bindings are actually, but apparently two has a client side
parameter bindings and three defaults to server side parameter bindings. But you can still do client
side if you want to. So lots of fun stuff in here. Advanced connection pool, static typing support.
Yeah. So I say, why not try three and only go back to two if you really need to.
Yeah. This is super exciting. Those are a lot of great features. I think the async support was previously done
through a separate library and now it's just part of it. That's pretty cool.
The what is the present? What is the past? What is the future? We'll come back to that in our extras.
We'll have some fun there.
Okay. And then also our audience is awesome. Mike says, Hey, I migrated PyPI from psycopg two to three in June. It was not too hard, but took some time to do safely. So, Hey, when you pip install things or IPI look up things, it's already using this. Awesome.
Yeah. Oh, that's cool. Nice. Indeed. Indeed. All right. Shall we convert some data? That's what I got next.
Sure. Let's talk about it. So we all know about Pydantic, right? And Pydantic is cool. So Pydantic lets us like create classes that derive from some Pydantic base type, base model, and it will do conversions and parsing of JSON and so on. But maybe, maybe you know about data classes, right? These are built in. They're not anything separate.
They're part of Python itself. And so being able to use them is pretty cool. And Raymond Peck commented on one of our YouTube videos and said, Hey, I use this thing called Daysite. Hopefully that's the right pronunciation. Daysite. And the idea is it allows you to create Python data classes in a similar way. All right. So simple creation of data classes from dictionaries.
So APIs and other things. And you just create a data classes as you normally would. Data classes, just sort of classes with, you know, global or static, static level field type, right? Like class user name, colon string, age, colon, and so on.
So if you just put the data class wrapper on it, right? And it gives it a bunch of nice things like hash ability, comparability, et cetera, right? Constructors.
But if you've got a dictionary that has sub objects that themselves should be data classes and maybe a list of other things that should be data classes, actually turning that JSON into one of these more complicated versions is a hassle, right?
You also might need to do data conversion, as well, right, to make sure that the types match. So that's what you can use this for. And it's pretty neat. You can just say from dict, a site dot from dict, and you say what data class it's going to go to, and what the dictionary is and like a little factory method out pops one of these objects. Cool, right?
Yeah, that's pretty cool. Yeah. And let's see, features include nested structures, like I described, basic type checking, optional fields, union. So if you say it can be an enter a string, it'll check that it's one of those two, but not a float or something, forward references, collections, and interestingly, custom type hooks. So for example, you can say anytime that you're going to take a string, actually call string a lot dot lower dot strip on it, if it's not null, right, if it's not none, things like that, right?
So you can actually get into the parsing side a little bit if you need to. So that's pretty neat. What else have we got here? Let me scroll down and talks, of course, about all the things I said. Yeah, I think that's, that's probably it. I guess one thing it's worth pointing out, it says, right in the docs, they say, it's important to mention that it's not a data validation library. Now, when I first read that, I'm like, but there's all these types, right? Is it like, is it supposed to find out when I say the thing takes a string and an int and a bool for it?
It's three fields, like it will actually do that. It does that, but you can't say like the string must be this regular expression and this many characters and the int has to be positive and like those types of things it doesn't do, right? So it's just dictionary to object, possibly complex data class object, but with type validation and that's about it. But still, I think that's super, super useful.
So kind of partway validator things.
Yeah. Yeah. More like a proper parser without the validation itself. Yeah. Yeah. Indeed. So anyway, that's what I got for people. It's, it was news to me. So check it out.
I think that's pretty neat. So I am going to continue on with a topic of guests, the ever rustification of, of Python projects. And this one is one that we use every day pip. So this was, this came to us from Owen, Owen Lamont, I think.
Owen Lamont. Thanks, Owen. So I said, said, Hey, you guys might be interested in this. It's a, a pro under the project group.
And I was ready to go try it. It's not ready to try yet, but it's still pretty exciting. So the kind of the headline fast bareboins pip implementation and rust, and it's not just an installer though. So it has, it's got, what does it have so far? It's got, you can download an aggressively cache,
a pipe PI PI metadata, resolve PI packages using a pack project called resolvo, which is a kind of a rust thing.
And then still on the planned list is actually installing the files.
So doesn't, I I'm just chuckling because yeah, I just jumped the gun, but this is new.
So it's, it's fine that it's published early.
So first commits look like about two weeks ago. So I'm pretty excited about, about this. I think it'd be fun to try it out.
And, and look at different, possibly different resolvers and how they handled it versus normal pip. So kind of neat.
Yeah. When I saw this too, I was pretty excited. So thanks Owen for sending this in. Yeah, it's, it's cool. And Mike says, let her rip. I love it.
Yeah. So it looks like maybe we should swap the, these last two topics, but I don't know. Let's go with the, with your next topic.
Well, I do think that this one would have been pretty good for you to cover, but too bad. I'm already on it. So here we go.
I guess the only like stronger tie to me is it's in response to a talk Python episode. So this one comes to us from Marwin and thank you Marwin for sending it in and writing this article called how not to foot gun yourself when writing tests, a showcase of flaky tests.
And it says, I was writing an article. I was writing this article after listening to talk Python with Gregory Kempfhammer and Owen Perry talking about flaky tests. So that was the subject to that basically talked about all of their experience here, which is cool.
Um, like a definition and really a lot of examples of flaky tests. I thought, I mean, you know, Brian, did you get to check any of these out?
I haven't looked at this yet. No.
Well, we'll do it live. Okay.
Okay.
So the first one is, really about concurrency and said, well, look, I've got a bunch of tests. Maybe I could speed them up by using threading and run a bunch of them.
Oh yeah.
That'd be fun. However, there's a real simple example of like, Hey, I've got an account and I can transfer money from one account to the other. So first account that withdraw this amount and then second account deposit that amount. Right. And how could that go wrong?
So do a bunch of those in a, Hey, if we want to make those faster, let's run them in some threads, right? Rather than using say one of the pie test plugins, like more properly. Right. This is more to highlight, like what might go wrong.
You know? and it turns out that we have the GIL and I think, I think Marlon's right. I think people do think that, the GIL will just kind of save you from concurrency. Right. Because only one thing can run at a time. So how are you going to have a problem? Well, well, it's one thing.
It's one kind of byte code at a time.
Exactly. One Python byte code. But here's the thing. If your program ever enters into a temporarily invalid state ever, you may, you may need, some kind of concurrency locks or something. And I think my reading of Python stuff, I don't see this very often. And I think actually a lot of people should be doing more locks, honestly.
So even in this example, I withdraw some money and now for just a moment, the program is in a temporarily, temporarily invalid state until it's deposited into the other account. Right. So that's this moment. Like if the GIL says, okay, you read enough, we're going to switch to the other one. Then somebody tries to, the other one reads that state. That's going to be trouble. Right. So they were talking about, well, how do you actually, you know, how do you actually check this? And here's something I actually didn't even know.
There's look, you can actually make that switching back and forth more aggressive. You can control that switching that the, the GIL does on the, how much Python on one thread it'll do before it switches to another by getting the switch interval. And here they set it to one 10th of a millisecond.
Oh, wow.
And then they do a bunch of work and then they put it back. And that's pretty interesting. Did you know you could do that?
I didn't. This is pretty cool to,
I know this might be worth covering the article right here. Just that.
Yeah. Good for testing these race conditions.
Yes, exactly. Like make it, make it worse. And also running on more cores potentially. I don't know. Probably that doesn't too much matter.
Okay. So to avoid boilerplate, you can reach out to the high test repeat plugin. Weren't you just talking about this? I know you're doing some stuff with it.
Yeah. I'm one of the maintainers on it now. There's my picture.
Yeah. I feel like you, yeah, I feel like you had actually just mentioned it. Maybe it was the get, the get article or something. But anyway, recently I thought you were just talking about this.
Yeah, that's sweet.
Yeah, exactly. Also worth pointing out a similar and more straightforward plugin possibly for this job is pytest FlakeFinder, which is meant to find flaky tests.
Oh, yeah.
Okay. So let's just hang out for here. One of the differences they're saying is that you can repeat your test multiple times with repeat or FlakeFinder, you can repeat your whole suite.
That's one of the things I need to change for repeat because you can do the same thing with repeat. You can run the whole suite.
It's just kind of hidden in two lines of the readme and it needs to be more bolded that you can change the scope and repeat the whole thing.
Oh, nice. Nice. All right. Randomness. For example, algorithms that are non-deterministic, like heuristic ones. So that's pretty interesting. So they do, what is this, like a distance algorithm or something that's heuristic.
So they say like, you know, NP close, which they're testing on NP close, whereas NumPy, like are these vectors close, says basically fix this by actually, you know, computing the tolerance and they use a little statistics.
Yeah. Probably more statistics than I know, but let's say three standard deviations away or something like that. It's interesting. Obviously floating point arithmetic is always trouble. Lost precision is always trouble.
But one they talk about here that's interesting is using integers, like integers in Python are arbitrarily large, which I think probably complicates C interoperability every now and then. But otherwise is like a good thing generally.
However, if you're doing NumPy,
NumPy has C backing for a lot of its types, right?
Like int32 and so on.
So you could end up with,
if you specify a particular data type in there,
when you create your array, right?
Data type is np int32.
Then you do have to care about the 2.14 billion limit, right?
Yeah.
I mean, you probably know that all the time from C, right?
You've got to worry about variable sizes and unsigned shorts and whatever.
Yeah.
And be careful about the order of operations
so you don't overflow in the middle of a set of operations.
Yeah.
Let's see.
There are some interesting things about fuzzing your data,
like sending a bunch of crazy data
or even using hypothesis to try to find edge cases.
Timeouts for external systems.
Be like super explicit about those.
So there's just, you know, there are a bunch of cool examples.
And you're like, this is a really properly long article here.
Nice.
So I think it really highlights a lot of good examples.
Follow up to that podcast episode, but just good for testing as well.
Yeah.
I can't wait to read that more in closely and listen to that episode.
I have to admit, I haven't listened to it yet.
Yeah.
It's a good one.
Blaze out in the audience wonders if we have to reinvent these corner cases for Rust.
I imagine we probably do, Blaze.
Good point.
Yeah.
Possibly.
How extra are you feeling, Brian?
I'm feeling pretty extra.
Actually, myself, not too much.
I've just, I've been, I've been actually doing a lot of personal projects.
So I haven't been doing a lot of work projects to announce.
However, those are wrapping up.
The personal stuff's wrapping up.
So I hope to get more Python people and Python test episodes out soon and more course chapters
coming.
So everything in due time.
Nice.
How about you?
I have some extras as well.
First, I just got back from Pi Bay last night.
So that was a lot of fun.
Pi Bay is always a good time if I zoom out and get the video to play even.
So really cool environment.
And it's all, you know, nice to meet a lot of people there.
So for those of you I met, great to meet you.
Also, I just want to give a shout out to Sparkmail.
I just started using Sparkmail to try to kind of like unify some stuff.
What a cool, what a cool app for macOS email.
So people, if you're like fed up, was using different web front-ins for different things.
And it was like, ah, they're all a little bit different.
One has E for archive.
One has A for archive.
But like ProtonMail, like the A for archive only periodically works.
Sometimes it works.
And then you're like, why is it so frustrating?
I'm like, maybe I could just use one thing.
And all in that was really fun.
So also, I think a big part of the development team is in Ukraine.
So happy to be supporting those folks as well.
Nice.
Somewhere it says like made from, you know, made from like hello from Ukraine or something
like that, which is cool.
However, one of the challenges is one of my personal email domains is actually backed by ProtonMail.
I think I talked about that before.
But ProtonMail has end-to-end encryption.
And so you can't talk to it with a third-party email client, right?
Okay.
Because it can't decrypt it.
It doesn't use IMAP.
At least not directly.
So if you use ProtonMail and you want to have something that is not, you know, there's a
proper, like a standard email client.
You can install this thing called Proton, what's it called?
It's Bridge.
ProtonMail Bridge is its name.
And what it is it runs locally on your computer.
It does all the end-to-end encryption and then puts it like it has a password protected but
not end-to-end encrypted IMAP thing that just runs on localhost.
So you just attach to localhost for your IMAP.
And then you have ProtonMail plugged into, you know, their examples are Outlook, which
just made me get a little wheezy just thinking about it.
But, you know, it also works on SparkMail and other nice things.
So I had been using SuperHuman, which was really nice, but that's only Gmail, which is such
a hassle.
So this works for anything, which makes me super happy.
Yeah, I don't think I'm using...
What do you do for email?
I just use the web clients, but mostly it's FastMail.
Yeah, nice.
That's what I had been doing for 10 years.
But I just kind of like, there were just too many and they were, I don't know, weird.
And I'm like, let me try this.
I really like it.
I think I will check it out.
One of the things that you brought up Outlook, I thought it was...
I have to use Outlook for work and it still drives me crazy that Control-F is not find.
It's forward.
Oh my gosh.
Yes.
It's terrible.
Yeah, this thing is nice.
It has sort of digital well-being stuff where it will only show you...
You can have it timeout.
So it brings you to this thing like, hey, check your email.
It's like two or three times a day.
Show me on this little list here that'll just show, say, people that are important to me,
but nobody else.
You can block senders.
It's pretty sweet.
Nice.
Cool.
Yeah.
Okay.
Next, one I hinted at before is I ran across this YouTube channel called Dust.
Okay.
Man, are they making amazing science fiction.
Have you seen this?
Just, you shared it with me last week.
It was pretty cool.
Yeah.
It's just this independent channel.
And they are posting like new, if you like short sci-fi, like 10, 20 minutes sci-fi stories.
The production quality is just off the chart.
So I recommend to people actually interested in this, FTL, Faster Than Light, which is about
faster than light travel.
And it's pretty neat.
Like the graphics and stuff is, it's surprisingly good for what it is.
So people can check that out.
And also one called Oceanus, which is like about this sort of underwater world.
And yeah, it's like this one's 30 minutes.
It's long.
But anyway, if people want, you know, short form science fiction, this is pretty awesome.
I'll link to it in the show notes.
Oh, that's pretty cool.
Yeah.
Blaze out there says FTL is a great short.
I totally agree.
It's very, very well done.
Neat.
Yeah.
And it's not always the Hollywood, like, of course the good person has to, you know, the
hero has to triumph at the end.
Of course, it's just a matter of how.
Yeah.
You never know.
Some of these are pretty open-ended as you might expect a 10 minute show to be.
Well, you know, I think, you know, there's some half hour shows on TV.
That really are only like 15 minutes if you take the commercials.
I know.
A lot of the comments on, if you look at like the FTL one, for example, the comments are
like, this is a better show than Hollywood studios make with millions of dollars and large
teams.
Like, how are you all doing this?
So anyway, I thought people might appreciate this given our audience is probably a little
bit techie.
Yeah.
Cool.
Right.
Have you ever wanted to just like rewrite your software, like some old junkie thing,
wrote it in some old code and you're going to rewrite the new awesomeness?
Uh, frequently.
Yes.
There's an amazing, so this is the joke.
So there's an amazing video, a music video, which is a parody on American pie.
And for those of you who are not familiar with American pie, it's one, it's a really great
song.
Oh, you're just singing.
But it's eight.
No, I'm not singing.
Okay.
It's eight and a half minutes long.
And so this guy, Dylan Beattie, he's really talented and he redid one that basically is
like a journey through all the follies of his different perspectives through his programming
career.
And it starts out in like assembly.
And then it goes, I don't know what it's the next one.
Is it VB6 or something?
And then, oh, it's just, it's an amazing, amazing thing.
But eight and a half minutes, I'm not going to play it.
So I'm just going to say, go watch the video.
Yeah.
It's, I'm sure it will connect with you.
What do you think, Ray?
It's very good.
And then check out his channel because there's a bunch of great nerdy videos on his channel.
So it's good.
Yeah.
If we scroll down here, what will we find in the recommended?
You give rest a bad name.
That's funny.
That was a good one.
Yeah.
The bug in the JavaScript, I think we featured before, but it's like starting to think I might
need a drink because the bug is in the JavaScript.
That's pretty good.
Yeah.
Fun.
Yeah.
Fun.
Anyway, so this is an entry point into quite a bit of time of programmer fun ideas.
Okay.
So that, and that's a programmer one.
I've had like a dad joke, science joke that I wanted to share because I just, I ran across
it recently and I just thought it was so funny.
So it's just a comment.
There are more hydrogen atoms in a single molecule of water than there are stars in the entire solar
system.
And I talked to several people about it and they just looked at me blankly and said, that
can't be true.
I'm like, sure.
There's two hydrogen atoms in a molecule of water and there's one star in our solar system.
That's awesome.
And those two hydrogen atoms.
Do the hydrogen atoms come from stars?
I don't know.
Were they just the stars?
Anything larger than that should have come from stars.
Yeah.
That's awesome.
I love it.
It doesn't make you think, cause like if you think galaxy universe, whatever, right?
Yeah.
But solar system, I mean, solar singular.
Yeah.
And I had, it was funny that some of the comments were like, like trying to calculate the volume
of the water and how many atoms might be there.
And I'm like, no, it's not an atom.
It's single molecule of water.
I'm not, not a glass of it.
So pretty fun.
Yeah.
That's how I first started.
Like, well, how large is the glass?
How many?
Okay.
How many more is that?
And how many?
No, wait.
That's not what it says at all.
That's irrelevant.
Yeah.
I love it.
Anyway.
All right.
Well, cool.
Well, once again, great chatting with you weekly.
Yep.
You as well.
And thanks to everyone for listening.
See y'all later.