Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 395, recorded August 6th.
And I am Brian Hawken.
And I'm Michael Kennedy.
And it is way too hot still.
I thought we were going to be done with the heat by now, but it's crazy.
It is August.
This week's episode is sponsored by us, so please check out the offerings we have.
We've got courses at both Talk Python and at PythonTest.
And we've got Patreon supporters.
We don't shout out to them much, but we do appreciate Patreon supporters.
So thank you.
If you'd like to connect with us, we're all on Fostadon, at mkennedy, at Brian Hawken, and at Python Bytes.
But, of course, those links are in the show notes.
And if you were listening to us later than Tuesday at Pacific Time, 10 o'clock, you can catch us either on podcast, of course,
but also you can watch live if you ever want to do that.
Usually Tuesdays at 10 a.m. Pacific Time.
And we appreciate that.
And also, really appreciate everybody signing up for the show notes email.
That's been going really well, and it grows every week.
And we are going to do a giveaway.
We haven't met our milestone that we're looking for yet, but we would love to give out some free stuff to people.
So sign up for that newsletter.
Brian, let me motivate some folks.
13.
That's how many we need.
13 more, and we're doing our giveaway.
All right.
Okay.
We just need 13 more people.
So get on that.
What do you have for us first, Michael?
Well, you know what I really like about that giveaway is that it's totally free, as in free threaded Python.
Let's go.
So last time we talked about some of the member we talked about, I think it was Simon Willison, hopefully that attribution is correct, about installing how there's a binary installer for free threaded Python.
Yeah.
Right.
Well, in there, I think he was linking to, but certainly I talked to Stan Siebert from Anaconda and that's coming out and I would talk Python shortly.
And he pointed out, pi dash free dash threading dot github dot IO, which is a website that tracks, gives you some advice on how to create your package or update your package so that it works.
And free threaded Python, but also most importantly, it has a status tracker for popular packages.
So you can look and see, are there wheels for free threaded Python?
Because apparently did you know that there's special wheels?
Like you could have wheels for Linux, wheels for macOS, Intel version wheels for macOS, arm version, but there's also specific wheels for free threaded Python.
So that's interesting.
Maybe you have different compiler flags with, you know, threading primitives built in versus skipped, you know, in that version or something along those lines.
Anyway, so it has a compatibility tracker for that.
Talks about installing it, which really means installing it on Linux.
It's really, I think all it covers.
But yeah, it gives you some, some more examples, how to verify that you're running free threaded Python and so on.
Yeah.
What I'm really excited about here is the last two bullets at the top talking about setting up CI and finding testing and debugging currency issues.
Yeah.
Yeah, for sure.
That didn't really occur to me, Dale.
You just brought it up that if you have a popular package or even a semi-popular package or one you rely on, you probably want to start testing it to make sure that it's not going to break in free threaded Python.
Indeed.
All right.
So let's look at the compatibility real quick here.
Compatibility.
It says this page and you can see it's got a big grid of, of statuses.
Basically it's not that long.
So if you have a package and you expect it to work with free threaded Python and stuff submitted here so we can see its status.
Anyway, the page says this page tracks the status of packages for which we're aware of active work on free threaded Python support.
It contains pages with extension modules as well as build tools and packages that need code specifically to support free threaded.
Now it also says note that pure Python code works without changes by design.
So it does not track pure Python packages.
Oh, okay.
Two things one.
So if you have a pure Python package, don't try to submit it.
Hey, here's our status.
It's like, well, you already got that.
So you can just probably do any for your platform and your wheel and you're good to go.
But there's, there's a difference between executes and works in my mind.
It says pure Python code works without changes.
Pure Python code will run in free threaded mode without any changes by design.
It's kind of like saying it compiles in a static language.
So it's fine.
It may be built to have a bunch of race conditions, but that, but it doesn't need a special wheel.
You know what I mean?
So don't take too much confidence that it's just pure Python, right?
Your pure Python code can have five steps, four of which have invalid state.
And if those things run in parallel and one of them observes that state while the other
one is halfway through its steps, you're going to have a bad time, even if it's pure Python,
even though it executes.
So just a bit of a statement from the reading there in general, right?
But like, if you look through here is there's some interesting things, Brian.
So for example, CI build will is tested in CI has a PI PI release.
So you can pip install it.
It talks about which version first supports it, but it does not have nightly wheels or
a nightly wheel link.
On the other hand, CMake only has PI PI releases.
Contour.py only is tested in CI, but is not available on PI PI.
And it talks about which platforms have nightly wheels and then their links and so on.
So you can go through this list.
For example, NumPy is tested, but there's no release of NumPy at the moment.
But there are nightly wheels.
I theoretically, I guess you could use if you want.
pip install from there.
We got pandas, same status.
A lot of them are, that's the most common.
They're tested in CI, but they're not yet pushed to PI PI, which is fair.
You know, it's, there is no release of Python that has free threading officially.
There's only betas, right?
So the fact that they're not just pushing this stuff out to PI PI is, I think.
Also interesting notice here, Brian, there's pip, even though it's pip pure Python.
I don't know.
I thought so, but check this out.
So if you go over to the installing section, it says, okay, basically you can get some binary
installers off of pipi.org.
Or here's a bunch of talk about how to set it up on Linux, how to set it up on Docker for
Linux and build it from source.
If you run it, it says, here's how you run with the guild disabled.
So if you run with Python dash, capital V, capital V, you'll see, it'll start and say, Python, such and such experimental free threading build.
Right?
Sounds lovely.
And, you know.
Yes, it does.
You're living so far in the future, aren't you?
And then here you can, there's a little one-liner you can execute to see that it's working.
Yep.
Talks about porting extensions modules to free threading.
And here you go, Brian.
GitHub actions.
Let's go.
It talks about how to set the GitHub actions.
And a bunch of code on how to actually test and debug all the things.
I love that.
How to set up CI.
And by that, we mean how to set up GitHub actions.
It's fair enough at this point.
It is consolidating a bit, isn't it?
It is, yes.
All right.
So if you are interested in free-threaded Python, a.k.a. the one that has had the Gilectomy done to it by Sam Gross and crew, this is a good resource to have around.
And if you have a package that you think might need some special treatment to work in that space and you have intentions to potentially support that,
let these folks know about it.
You can see the GitHub in the top right.
I'm sure you can submit an issue or something there.
Yep.
Nice.
Well, if you need support, change your transition here.
Supporting.
If you want to support free threading, great.
But also, we want to be a supportive Python community.
So I did it.
A nice transition there.
To Python's supportive and welcoming environment is tightly coupled to its progress.
This is a post on the Python Software Foundation blog.
And it is very nice.
I think that everybody should go read this.
And one of the reasons that indicate that maybe this is kind of important is this is signed by a whole bunch of people.
Deb Nicholson, Don Wages, Tanya, Quan Han, Kushal, Georgie, Janice, Christian, Christopher, Denny, and Chuk, and Simon Wilson.
Lots of signers of this.
So what is this?
I want to highlight a couple statements here.
Python is as popular as it is today because we have gone above and beyond to make this a welcoming community.
Being a friendly and supportive community is part of how we are perceived by a wider world and is integral to the wide popularity of Python.
I totally believe this.
We even won, apparently, won a wonderfully welcoming award at last year's GitHub Universe.
And it's often referred to as like come for the language, stay for the community sort of a thing.
However, with the recent bylaws changes, there was a lot of drama on the mailing list.
So much drama that we had, even though there were only a thousand people approximately subscribed to a PSF vote mailing list, 45 of those people dropped out.
I think probably because of the toxicity that was going on that mailing list.
So this is a good reminder that we are a welcoming community and we want it that way.
I like another, I'm going to hop down.
There's a lot of information and history if you're curious.
I like this statement here.
We have a moral imperative as one of the very best places to bring new people into tech and into open source to keep being good at welcoming new people.
If we do not rise and continue to rise every day to this task, then we are not fulfilling our own mission of our own mission to support and facilitate the growth of a diverse and international community of Python programmers.
Goes on to talk about how technical skills are a game changer for people that are trying to better their position, try to get a better job.
Python's a great way to get into tech and into programming.
And we need to make sure that that stays a great pathway.
So kind of a serious topic, but it's serious to me that the future of programming stays with this nice on-ramp of Python.
And we maintain this to be a good place to be.
So further continuing, some of the consequences of some of the bad actions that happened is that the forum and the mailing list and some of the other avenues of discussion will be, will be, or they've turned on moderation.
And they're going to continue with moderating it to make sure that there is not toxic behavior going on.
And I applaud that.
I think that's the right thing to do with something as important as communication from the PSF and Python.
So box over.
Cool.
Thanks for sharing.
I do think making it welcoming to new people.
I think what a Python's powers, superpowers, is really that people come and they don't feel intimidated.
Right?
They don't consider themselves programmers.
And they kind of accidentally slip into like, wait, I think I just published a package.
Does that make me a programmer?
You know, like six months later.
And having the community being welcoming, not just the syntax and the tooling.
Yes.
It counts, yeah?
Yeah.
I see a lot of times people will, like a lot of PyCon goers, for example, will bring along one of their kids, even though they've been going for a while, bring one of their kids.
And having the kids be able to go off and learn also and realize that, hey, this is kind of a neat place.
We're probably getting software engineers from the community just because of this that maybe would have not considered it.
All right.
Planting the seed there.
All right.
You've got some good news for us, don't you?
I do.
Well, I have last week, I have planted a seed.
And this week it has grown.
So I was going to cover a new topic, but I want to have more time to digest it than I've had.
So let's, I want to do a follow-up instead, Brian.
So remember last week I talked about Uptime Kuma, which is a fancy self-hosted monitoring tool.
And a lot of folks chimed in over on Mastodon saying, you've been using this for years.
It's super awesome.
And so on.
I said, hey, maybe I'll, maybe I'll play with this.
That would be cool, right?
Yeah.
Well, guess what?
If you go to Python Bytes and you scroll to the bottom, server status right there, and you click on it, it shows you the Python Bytes operational status.
What is the status of the website?
And all these little green dots, each one of these are a sample of either up, down, partially up, partially down.
I guess those are the same thing.
But so you could see those sort of like over time.
I wish I could control how much time this is, but this is basically just the samples, some number of recent samples.
And I think I've got it set to every minute or two minute it checks.
And if it goes wrong, it'll send me an email or something like that.
But you can also see this 100% of time.
It's basically since I set it up.
But I think that's 30 days or something.
I'm not sure exactly the window of that, but that is more, that tracks more of it.
But anyway, we've got the Python Bytes web.
You can see its certificate expires in 82 days.
So that's good.
Plenty of time.
It's 90 days by default.
So quite new.
The RSS feed, what is it?
Status.
The CDN status that actually delivers the MP3s, which is a whole separate bit of infrastructure at bunny.net.
And the MongoDB database that powers the website.
So you could see, well, maybe the website's down because the database is down.
Or, you know, there's just a problem with the website.
Isn't that cool?
It is pretty cool.
Yeah.
And even more involved because of all the course stuff is if you go to the one for the bottom of Talk Python, you can see you've got all those things I described.
But also like the mobile APIs, the video CDN, the podcast CDN, the courses website, all those things.
And all are making me smile with almost 100% of time.
I think I broke when I set it up.
I didn't configure the setup right for RSS.
So it's got a little lingering broken bit.
But I don't think it's actually had any downtime.
Okay.
I was good.
Actually, I'm pleased to see that because I was just wondering if you're rounding up to the nearest hundred.
No, no.
This is like to the it's to the hundredth.
So it's like 99.86% up.
But I think it's just I broke it when I was trying to set this thing up.
So, yeah, incredibly easy.
Just.
This is cool.
Yeah.
Where's there's.
So if you go here, basically just Docker run.
And I've talked about this whole Docker cluster.
I've had.
I've migrated everything to all the infrastructure, too.
And adding this as a thing that runs over there.
Incredibly easy.
It took probably 20 minutes to get it set up running as its own bit of infrastructure.
And now it just chills in its own Docker container watching all the other things around the world.
So very cool.
Neat.
Yeah.
So if you want to play with that, you can check that out at the bottom of both of the podcast websites in their footers.
Same for talk by the training as well.
It's in there as well.
But basically, you know, just it's just an example of someone putting up uptime Kuma, which so far I'm pretty happy with.
And if what you see on the status page is a public thing.
But if you log in, you get a lot more detail of like responses, response time, overtime, and all this.
So you can kind of use it as a performance monitoring thing as well.
Oh, cool.
Yeah.
I should check that out.
Indeed.
Neat.
All right.
Well, something else to check out is something upcoming possibly in Python.
There is a new PEP.
Well, there's often new PEPs.
But here's PEP 751.
This is authored by Brett Cannon and started at the created at the end of July the 24th.
What is this?
This is PEP 751, a file format to list Python dependencies for installation reproducibility, which is a bit of a mouthful.
But to be honest, some of the details in here are a little detail oriented.
But I like to look the abstract and the motivation make total sense.
So the idea is, well, I'll just read it.
For the abstract, this PEP proposes a new file format for dependency specification to enable reproducible installation in a Python environment.
The format is designed to be human readable and machine generated.
Installers consuming the file should be able to evaluate each package in question in isolation with no need for dependency resolution at install time, which is interesting.
So what's the idea?
I thought we had this already, don't we?
We have dependency, but we don't have like this whole like lock file stuff is not is not is not a standard.
It's just implemented several places.
So there's no under motivation.
Currently, no standard exists to specify what top level dependencies should be installed into a Python environment.
And no standard exists to create an immutable record such as a lock file of which dependencies are installed.
There are at least five well known solutions to the problem.
We've got pip freeze.
We have pip-tools.
UV has a solution.
Poetry and PDM all have a way to deal with lock files in general, but we don't have a standard for this.
So I am, I guess, welcoming the idea that that that this will be a standard or something similar to it.
This is early in the PEP lifecycle.
But yeah, anyway, since it's a packaging topic, these don't necessarily have to come out at the same rate as Python because pip is not pip and other packaging tools are not on the same year timeframe as as as Python.
So not sure if if it were when this comes about.
So yeah, definitely.
This is cool.
I actually had this open in another tab.
I can so I can go close that now.
Thanks.
Because I wanted to read about this.
This is exciting.
I always love what Brett Cannon's working on.
Yeah, I think I like the idea of having a lock file that we can use because you every tool you pick, it's got a solution, but it's incompatible with all other tools.
So some project uses poetry, for example, to manage its dependencies.
And you just you don't want to use that.
Yeah.
When you you want to use something else, like I'm a big fan of UV's implementation of pip-tools.
Well, that doesn't work with it.
Or maybe it does.
But, you know, like you've got to you've got to get it depends on how you're using it.
Right.
But having something interoperable between these would be nice to allow you to choose your workflow.
Yeah.
Regardless.
One of the one of the aspects in here under rationale talked.
about, which I think is pretty cool, is that the file format, the tool that creates the file doesn't necessarily have to be the tool that reads and parses it.
The important thing around that is that there might be like, yeah, anybody you can anybody can create the lock file with whatever tool you want.
But but a service like, you know, something like Anaconda or some other service or a packager that pulls everything in.
Well, you might have their own standard way to do all of that.
And it doesn't have to be they don't have to support flit and PDM and all sorts of other tools.
I guess flit isn't one of the on the list, but you know what I mean?
Yeah.
Lots of different things.
So yeah, it'll be interesting to watch this and see where this goes.
And as always, I appreciate how much Brett thinks about packaging and packaging was.
I know that there's that that XKCD comic about packaging being horrible in Python, but it's a hard problem.
And I'm glad that we have bright people like Brett and other folks he knows to work on the hard problem.
So anyway.
Indeed.
I just one thing I hope is that whatever file gets generated out of this, that it's not so noisy that diffs of them over time become hard to read.
For example, using the tools version, if you flip on hashing, like the hashes take up so much of the of the text that I feel like it's just super hard to read all of a sudden to just like diff a thing and go, OK, what's the what's new?
What's what's changed?
What's the same?
But it's just, you know, yeah, maybe I should turn word wrap off or something on my editor.
But it's like you're trying to read, OK, this thing is installed because these three things depend on it.
But there's just blocks of hashes like all over the screen.
You know what I mean?
So I did notice that that was actually called out in the rationale around it.
It said the format is designed so that viewing a diff of the file is easy by centralizing relevant details.
Oh, awesome.
Yeah.
Like maybe it could have all the things and why they're installed there.
And then it could have the hashes in a separate place.
Yeah.
You don't have to look at, you know, that don't mix in.
Yeah.
Cool.
Yeah.
Yeah, this is great.
I'm glad that that was a that was that's part of the concern is to make sure because, yeah, that's I might not read it maybe theoretically human readable like XML.
But the only time I'm actually reading XML is in a diff.
So, yeah.
Anyway.
Cool.
Well, that's our items.
Do you have any extras for us?
I do feel a little extra today and I hinted at this some of the stuff I'm going to cover here.
So, first of all, mypy has a new release and there's some interesting things to call out, Brian.
mypy 1.11.
So, if you don't know, mypy is a faux compiler for Python, I will say.
It's a type checker, but what it does is basically go through your code as if it was a compiler and make sure that everything would hang together.
Like here, you say this thing is an integer and you're passing it into a function that can take an optional integer.
Right.
Not an optional string.
And it would be an error and it would tell you that it's not okay if it weren't.
Right.
Just like, I guess, like a compiler kind of would.
So, you can get that.
That's very cool.
It has support for the new 312 simpler generics, right?
Like class C of T, just a bracket of T, and then you have T goes to et cetera, et cetera.
Very nice there.
The one I wanted to call out, though, is functools.partial.
You talked about functools, no, iter tools last week.
Now, how about functools?
Have you heard of functools.partial?
Yeah, I've used them.
Partials are fun.
I've never used them.
So, in Python, we can have default values like f of a and b, f of a comma b, right?
You could say b equals one, so you don't have to specify the value.
But it could be another value, right?
It could be if somebody wanted to, they could override that, right?
You can't say here's a thing with a default value but never set it.
So, you can say partial of that function and specify the second parameter.
Yeah.
Or whichever parameter you want, right?
And it'll pass that in.
But now, mypy checks those.
We also get better type inference, better type hinting and expressions, and a bunch of other stuff.
So, it's a pretty big release.
People can check that out if they want.
The thing that I hinted at the beginning is fast HTML.
I know there's been a lot of talk about this, right?
Yeah.
So, fast HTML is a, they describe themselves as a modern web application, building a framework for modern web applications in pure Python.
Think kind of view components a little bit, but a flash style programming model for the server side with a lot of those components actually written in Python, which is pretty interesting.
You can create them, make reusable things.
And it's, it's interaction and its dynamic aspects are based on HTMX, which is one of my very favorite JavaScript frameworks as well.
So, if you were thinking of doing stuff like Streamlit or Gradio or some of these dashboard types of interactions, and you're like, I need to go beyond what is capable of this and not just put dashboards, but more interactive elements and sort of more of a web app, but not a ton more.
Then, this is a framework that it's upper bound is much higher where you can keep going and going.
So, you can definitely create some, some cool apps real quickly with not very much code.
So, I'm going to play with this a little bit more and I think I'll talk more about it next week.
I'm looking forward to that.
I was going to bring this up as well.
Yeah.
Looks interesting.
We could share it next week if we want.
All right.
And then also, we're coming up on last chance to go be part of the Python and web and database course in Castle in Italy, the Python Zero to Hero 2024 event that I'm doing in a luxurious Tuscan villa.
And hopefully, you can be there.
But if you've been on the fence and thinking, maybe I want to go, but not sure, I'll find, you know, on your to-do list to think more about it.
Well, you got to think soon because we're going to close enrollment pretty shortly.
So, please, if you want to go, jump on that.
If not, that's totally good too.
And that's it for my extras.
All right.
I've got one extra of pretty much what I've been doing in my free time a lot is working on the new course, Hello pytest.
And I really want it to be accessible to everybody.
So, I do have a landing page now.
If you go to courses.pythontest.com, you'll see a link to it.
There is, I don't know.
I haven't decided what the final cost pricing structure is going to be.
But I'd like to start it at $10 because I'd really like it to be something that people can take a look at.
So, the idea around it is not to teach you all of pytest.
It is to get people started with it.
So, to cover some of the basics like parameterization and fixtures and stuff.
And the idea being, I would love to have something to hand out to teammates so that everybody can get up to speed.
So, the one pytest expert on the team doesn't get questions all day long.
That's where I'm trying to fill this in.
So, that's still up.
In order to do a pricing page, I had to pick a date where I was going to deliver it by.
I picked the 19th, which is, what, 12 days from now?
I think it's going to be done before then, but that's my deadline.
So, working on that.
Awesome. Congrats.
You know, people, if you look around online courses, like especially Udemy, it's an arms race to have the most content.
We have the super mega course that's 36 hours of content.
You know, and it's like, and it's only 50 bucks.
That one over there, that's 50 bucks.
It's only five hours.
That is nothing compared to this.
That's an additional 31 hours of your time you've got to put into it, right?
And not everybody has 36 hours of interest in learning pytest.
They just need enough to get going and get started.
And so, I think there's real value in having a concise thing.
Yeah.
Well, I was surprised.
I was talking to a team that was considering my larger course, and they decided not to because it was because of them.
They were like, oh, I really want somebody to be able to do this in half a day or less.
And I'm like, oh, okay.
So, there's real value in half a day or less courses.
So, I think.
I agree.
I don't want to spend 36 hours learning anything.
I mean, over the course of the history of working with a tool, sure.
But over, like, right away?
No.
I'm not going to do that.
Yeah.
Cool.
Exactly.
All right.
Let's want to joke about open source a little bit.
Yes.
All right.
So, this joke is called open, exclamation mark, AI, exclamation mark.
So, it has this sort of meme of two people talking to each other.
It says, hi, my name is open AI.
So, you're open source, right?
Right?
No.
Yeah.
Not really.
Hmm.
It should be closed AI.
Yeah.
At the bottom, it does say, okay, open AI is not open source.
The open means that AI is open to receive our data.
Okay.
Very well.
Oh.
Very well.
Yeah.
Okay.
Yeah.
Bart agrees with us.
Ain't nobody got time for that.
For long courses, not open AI.
Yeah.
All right.
Cool.
Well, good, again, to talk with you, as always, this week.
Thank you, everybody, for joining in on the live stream and everybody else for listening.
And I hope you have a wonderful rest of your summer or next week.
So, talk to you next week.