Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 346. I'm Michael Kennedy. And I'm Brian Okken. And this episode
is brought to you by us. Check out all of our things and support the show by taking part in
them. We have our courses, the pytest one Brian wrote, a bunch of other ones. I just did the async
Python and MongoDB combo with a little bit of FastAPI and load testing in there. That's a good
one to check out. And if you want to be part of the live stream, just Python by set up him slash
live and you'll see the next scheduled one we got set up for you queued up for you. Usually 11am
Pacific on a Tuesday as it is today, but that's not always the case. So be sure to check. It is August,
Brian. Yeah, the summer is moving along. And so is the Python. You have some big news to share. I know
I have a bunch of fun, small things, but you got some big ones. You want to kick us off?
Yeah. So we, I think we've covered this before. There was a PEP 703 to make the global interpreter
lock optional in CPython. And well, we have some news from the steering council. So the steering
council has come back. There's a Thomas Wooters posted a steering council notice about PEP 703.
And there's a lot of news in here that I think I'll let you help me dig through this. So I'm going
to jump down to the, so there's, there's some assumptions and some discussion around this
Gill removal thing, but I'm going to jump to the short and midterm and longterm actions. So it's going
to be in stages. So the idea is in the short term, there'll be a no GIL build as an experimental build.
And that will be a part of possibly Python, their version 313 or 314. It looks like they're hoping
for 313, but that's so that what that's like next year or something like that. So and then, okay. So
then we'll have two builds. What do we do with that? Well, midterm is there is to have, and the
default is the default version is going to be the, the, the GIL version, of course, just as usual,
as things go through it, as they figure out and everybody deals with like the rest of the Python
environment and the community and all the third-party libraries figure out how to deal with the no Gill
version. So in the midterm is there's going to be a community, hopefully community support to help,
help get through this no GIL part. And, and then longterm, the no GIL version becomes the main
Gill or the main, not the main Gill, the main version of Python. And we deprecate the GIL version. So
the timeframe looks like about the longterm isn't super long. It's like in the five plus year timeframe.
Well, the plus means like, who knows how long it will be. But I think that there's a lot of energy
around getting this done and getting a lot done in the next few years. So yeah, the, the timeframe of
it being an option in three 13, I would put it in October of next year of 2024. Yeah. And some,
some alphas and betas earlier then. So yeah, for sure. That's pretty quick. And then, so there's just some
caveats in here saying they're this, everybody's excited about it, but they, they reserve the right to
just cancel the whole thing. If it's really not sound, if it's not working out. So, but I don't
think that will happen. Yeah. Yeah. We'll see how it goes. But we talked about this a little bit on
our AMA episode about the value and basically what the other languages do. Most of them have some
constructs, but assume that developer is kind of responsible. You pointed out that it's not as
burdensome as people might think, because most code is not parallel code and you don't have to worry
about it. It's just kind of a, no, no big deal. You don't have to think about it unless you're writing
libraries where, you know, that will be used in a thread safe way, you know, things like that, then,
then you do have to take that into account. I think the trade-off is worth it. We're not getting,
we're not trending towards a world where there are fewer CPU cores, right? Yeah. It's only getting to
the point where, you know, like for example, on, on my Mac, if I run some Python program, it has access
to 10% of the capacity. If I run it on my SIM computer, SIM racing computer, it has one 16th access
to one 16th of the CPU capacity, right? It's just, if you want to work in modern hardware,
you really need to have access to parallelism when you need it. So for me, this is a real positive.
I think the other thing that we previously covered is meta said they will come along and dedicate three
experienced engineering engineer years to this project to help make, not just it happen in CPython,
but to make it happen in the important libraries outside there, like NumPy and those types of things.
So I think for me, this is a super positive. It's always been a little bit weird that Python has been
so restricted. It's also one of those reasons that might, it's like one of those springboards
that might eject someone from the community that they would otherwise love, right? You might be told,
well, we got to get better parallelism. So we're not doing this in Python. We're going to do it and go
or some other place where you're like, kind of like Python, but I guess it's not a fit anymore,
right? This would mean that it's a better fit in other places. So this is awesome. I know it's
going to be a lot of work. It's going to be another legacy Python versus non-legacy Python sort of deal.
hopefully not too bad. Maybe having gone through it once, the community will go,
oh, we'll do it again. It's not as bad as we thought.
Yeah. But I mean, like the goal is so that you can have, like, if you're just writing a little,
a little single threaded thing or a little script or whatever, the small sort of things you do with
Python also, that those things are just as easy as they are. They've always been and just as fast.
That's what we want.
Yeah. That's certainly the goal. I'm just thinking about the code that uses the Python API for important
libraries that calls the API, release the gill, take the GIL. When there's no more gill, does that
library become unusable? Does that become a no-op and it's just undefined behavior? You know what I mean?
Like there will be some kind of consequence in the ecosystem. I just, I'm not sure what the knock-on
effect will be.
Yeah. Yeah. And it'll be interesting to see how, like, applications like Django and things like that
deal with it.
Yeah, for sure. And Liz out there points out, get through this long-winded breakup with a GIL.
We have a semi-toxic and ambivalent relationship with a GIL. We love it and hate it at the same
time. For sure.
Yep. Definitely.
All right. Well, Thomas, thanks for the updates on this. Yeah. And it's going to be an interesting
journey. Brian, it'll give us plenty to talk about. So that's cool.
Yeah. Stick with this. Make sure you subscribe to Python Bytes to keep up on everything that's going
on with the GIL breakup. Yeah, exactly. It'll be fun. All right. I got to adjust my browser before
we switch or I'm going to spoil the joke. All right. So I want to do just a quick one. This is not
Python specific, but it's super important for web developers. So we had Google with flock. Remember
that federated, cohorts of, learning of cohorts. Oh yeah. And then we had the sandbox groups,
which was kind of like that. And I, I don't remember exactly what that was called, but that was
another technique because the flocks met with such resistance. Like you could really do some bad stuff
by putting people into these groups. And so the, I'm not sure where the sandbox stands, but it turns out
there's now a new proposal, to try to get rid of third-party cookies. My feeling, I don't know for sure,
but Google is trying to get rid of third-party cookies because they're easy to block and it hurts
their advertising and they're retargeting. If you can just easily block it by checking a box,
like, do you want to be tracked? No, thanks. You know, in your browser, right? Like Firefox does,
like Vivaldi does. You know what? Oddly, I don't remember that setting being a default in Chrome that
it just offers to block the Google network. That's interesting. It must've been an oversight.
So anyway, this, they're now out with a new thing and the, over on a bleeping computer,
they say browser developers push back against Google's web DRM. So basically the different websites
can choose or be made to choose to force you to verify certain things, that, basically
prohibit things like ad blocking, like prove that you don't have ad blocking on. So you can visit my
website or I'm going to tell you, you can't write new authentication system could let websites block
extensions, jailbroken devices, and other important things. So the, the headline is Google has been
trying to implement plans to move beyond cookies for years. That sounds great. Comma without denying its
partners and itself, the means to sell targeted ads, which form the backbone of the company's revenue.
This new one comes, proposal to guarantee user privacy and security comes to the, the cost of
freedom of functionality, AKA the open web. So there's a bunch of, it talks a little bit
about how this works, but basically the website has to come along and decide what browsers it trusts.
And the web browsers themselves have to implement a mechanism to guarantee who they are. Not surprisingly,
Vivaldi comes along as one of the first people to push back against this and calling it dangerous.
If an entity has the power to decide which browsers are trusted and which are not, they say there's no
guarantee that they will trust any given browser. And a new one that comes along would not by default,
not be trusted until it's somehow proven itself to the people who run that website. And what about the
next website? What about the next? And so on, you have, of all these kind of an interesting position like
this, they, they're just, they use a fork of Chrome that's stripped down of a lot of things. But when you go
to a website or you look at the user agent, that's how browsers nowadays tell people who they are, right?
And just send whatever you want. But it usually is a consistent thing. Vivaldi lies and doesn't say,
we're Vivaldi version. I don't know, whatever version we're on. It says, I'm Chrome. And whatever the current version of Chrome is, it just says that. That way websites don't go, oh, you're going to need to use Chrome because,
your, your web browser isn't one of those. You know, it's like, it actually is internally identical.
Just, it's got a different name, right? So they're in this situation where they kind of lie to the world about who they are, the web server world. And this would kind of break that as well. The Brave team says, the Brave team says, they don't really care. They're not shipping it. We'll see if that's a problem or not. And Mozilla doesn't have an official opinion. But one of the folks said the mechanisms to attempt to restrict these choices are
are harmful to the openness of the web ecosystem. And this one's might be interesting to Brian. Additionally, the use cases listed depend upon the ability to detect non-human traffic, which as described would likely obstruct things like web assistive technologies or automated testing.
So anyway, this is one of those things that probably deserves enough interest from people in the Python web world to just voice a little bit of no.
No, the answer is no.
Yeah. And yeah. So anyway, I, it's, you know, not super actionable. It's not a thing that's out there yet. But like the previous two, it's, it's the folks behind the web side of Google, the web browser side of Google, the web standard side of Google saying, how can we basically change the web?
So that it's so that we will be able to completely still control and track and sell you right right now. The third party cookie thing is not looking good. Even, you know, parliaments and Congress have gotten into it and said, Oh, you can't have these cookies. We have these stupid pop-ups everywhere.
This would make those all go away and you would just be like part of the machine. You know what I mean? this is just the third, the third version of how do we make them part of the machine? and this one I think is probably the worst.
Cause not only is it something that would go into Chrome, which was the previous two, but this is something that would basically make the websites reject browsers. You might say, Michael, why would a website do this? I mean, obviously terrible places like CNN that have some like 45 trackers.
They put on you every visit, you might see why they would do that, but why would, you know, random little website not want you to come? Well, there could be things like, Oh, do you want to have Google ads on your site or any double click or any ads from any ad network?
Well, we're not going to allow you to have them at all. Unless your website has this, you know, please reject the ones that we don't like sort of setting turned on. And here's the script will help you do that.
So it's not ideal. Yeah. It's like, nobody can make money off of traffic except for me. sort of thing.
Yeah. It's, it's, I mean, it's pretty bad. It's kind of a monopoly type of situation. One in the browser space and then two in the ad space. They're kind of both sides of that markets. It's, it's pretty, pretty much not good.
I wonder how many people are turning off ads, because I mean, I've gone, I've got Vivaldi running and it's turning off ads and I, I run into websites that say I did. You can't read this unless you turn on.
Turn on if turn off your ad blocker and I'm like, well, I'm not going to read it then. I'm like, I'll go somewhere else. yeah. But how many people really do? I mean, it's can't be that many, many of us.
I would say for developers, the developer audience looking at when I used to run Google analytics before I decided they were evil and turn them off. It was about 40 to 50% of the traffic would not show up.
Yeah. Okay.
So that is not quite all blocking. There could be robots like, you know, requests doing a request like Python requests, doing a request that also wouldn't register, but that's, that's pretty good. And just, you know.
Yeah. We'll go back to like magazine ads, never had tracking in them and they did fine.
Yeah, exactly. So, I mean, it's not just, we're trying to be jerks to websites and we don't want to pay for stuff or we don't look at ads like this headline.
How long is this? This is just, you know, six months ago or nine months ago, hackers abuse Google ads to spread malware in legit software. Right.
There's just stuff over and over. Plus what, you know, there's all like the reselling stuff, the NSA, CIA stuff.
Yeah. Buying your, I mean, there's just lots of, it's not just, I don't want to see ads. There's really negative effects to these things. And it's honestly, it's a little bit disappointing that Google is doing this.
Right. And we have advertisers and we put ads on our website for the advertiser.
Absolutely.
And it's, but it's, there's no tracking. So.
And they're not even blocked because we're not trying to send it through some creepy network with retargeting. We're just, we tell you things that we've, we've evaluated and thought you might like.
And people paid us to help spread the word. And, you know, there's certainly ways you could do that. Right. Like this last thing, there's this page we're on here. If it had ads, I don't know if it does or not, cause I'm blocking them like you.
But if it did, it could easily show you ads about privacy. It could show you ad about browsers. There's like certainly relevant ads that can be put on here just based on the context of the page, not who is viewing it. Right.
And those work almost as well without all the negative stuff. So anyway, one more thing to keep an eye on folks. And Christopher on the audience says, interesting how Google has lately continuously, continuously been trying to do the exact opposite of don't be evil.
Yeah.
Shareholder value, Christopher, shareholder value. Let's have it.
Well.
All right, Brian, over to you.
That's pretty rough news, man.
No, it's okay. The last two sounded bad, too. And they both got, you know, pushed out of existence. I suspect this one will as well.
No, I was just trying to do a rough transition.
Oh, that was pretty rough.
Anyway, so there's an article. Oh, I lost the author. It's from Matthias.
From Matthias. How rough changed my Python programming habits. And we've covered rough, I think, several times on the show. But I, I and I've used it on a lot of projects. But, but I, I was excited to see this because it's some stuff about rough that I've, I haven't been paying attention to. It just works. And it's really fast. But there's a whole bunch of cool stuff. So this, in this article talks about, he talks about using pre commit.
Pre commit. Or has long been using pre commit. And flake eight and black and I sort of all that sort of stuff. And I knew that rough was going to start picking up some of these extra things. But I didn't know how far it went.
So in this article, he talks about using different rules within, within rough, like, like pie flakes and pie code styles. So that's, and the McCabe for cyclomatic complexity checker, just to make sure that you don't have too many nested, huge loops and different things like that.
I love that magic.
So all these things you can turn on within, just within, within rough.
I sort, PEP 8 naming.
That's cool.
Pi upgrade.
Love that.
Flake, flake eight 2020.
And I'm going to shortly show where you can look these up.
So there's a whole bunch of really cool things.
I really like bug bear, flake eight bug bear also.
So apparently that's been supported for almost a year within rough.
Um, like a Django pie simplify, but this, these are just the, the ones that this person likes
or has, is he trying out and using.
Um, so I went ahead and kept looking.
So that's, that's this article, which is a pretty decent article about using how it changes.
One of the things I want to highlight, and I've been trying to use, I, when I tried to use
pre-commit a while ago, I haven't been using it lately because a lot of these things take a
bit.
Uh, they take a bit of time and it's, he writes, there's always a trade-off between
development speed.
I.e. waiting on get commit is very boring and strictness.
And I have to agree.
So what I've been doing is mostly putting these tests in CI and not doing it as part of pre-commit,
but having it within, within rough is super fast.
And you can go back to using pre-commit with rough and just turn on a bunch of these things.
So, link also linking to the rough configuration, documentation.
And for example, these aren't, all these things aren't turned on by default.
We get, I think the air, the, PY code style warnings.
Oh, it does not turn on.
It doesn't turn on PY code style warnings.
It by default, it turns on PY code style errors and PY flakes, errors.
So those, those are turned on by default and you turn it on with this, like, in within
the toml file with like a select equal.
And then you have like just a, a string of characters like E for, PY code style F for PY flakes.
And then there's a whole list of these.
Um, so there's an example of you do B for like a bug bear.
And then there's another page for, rules, where, in the rules list, all of the
different, different ones.
So like the PY flakes start with F.
So if you would add F for that, there's a whole ton of these things, that I'm excited about
trying to turn, turn more of them on.
And I have on one of my projects and it's just super fast.
So you just like within pre-commit.
So there, when I try to commit something, it'll run these on the files that have changed,
and try to run, or I can't, I actually don't know.
It's happening so fast.
I don't care.
Maybe it does the whole thing, but it's just super fast now.
And I don't have to wait to commit, but I know the checks are being done.
Super fun.
The other bit that I wanted to, the one last link I want to share is, astral, which is
the now company, around rough, has a rough pre-commit, hook that you can set
up for get, for GitHub actions.
So, if you just add a, this little snippet, that we have a link to, there's just a,
astral, astral dash sh rough pre-commit repository with a river, with a version and, with
the hook and you would, that will make it so that your project runs within GitHub actions
also.
So super fun.
Okay.
Yeah.
Very cool.
I also like having it set up.
So not as a pre-commit hook, but also as a high charm plugin.
Yeah.
Oh, right.
I just misspoke.
This isn't a GitHub action.
It's a pre-commit hook.
So it's, it hooks rough in with pre-commit.
Sorry about that.
Yeah.
Nice.
Well, so that way as you're typing and you see the stuff, it just puts a little squiggly
send there, there and suggests sometimes it can even auto fix it, you know, alt enter,
fix this thing by, for example, applying strict equals true and the zip.
Okay.
So you just have rough rough running in, in PyCharm.
And it just runs constantly as you type.
But again, it's so fast.
Like, you know, you don't notice.
Well, one of the fun 10 cores, I can do it over there.
One of the things with the, with the having it be a commit hook also is, you can set
it up to, to auto fix.
So rough isn't just, you have errors, but it can find the errors and fix them and not even
tell you about them.
It just fixes.
Oh, that's nice.
Yeah.
So like, well, I turned on bug bear or I can't remember what I turned on one of the extra
rules and it showed some, some, like some spaces at the end of the lines.
And then I added the command to just fix them for me.
And then it just didn't do it.
It just would fix them without even telling me, which is great.
It's way better than complaining.
Yeah.
Like I sort stuff.
Well, if I, if I, if I'm just, just sort them, if I got them in the wrong order, just
like, you know, I'm going to do it and that's fine.
Yeah.
And Henry says rough also has a VS Code language server plugin as well.
So either side of the fence that you sit on for those, that's all good.
All right.
Onto the next, onto the last.
All right.
Onto the last.
We've discussed F S back file system specification, I'm guessing.
And the idea of F S spec was that what you can do is you can have all these different
different file systems that when you would do like open, you know, open some file name
encoding as this append.
So on that kind of work, you could point it at different places besides the hard drive.
You could point it S three.
You could point it at a, some kind of web dev or some other, you know, blob storage network
drive, all these different things that you could possibly do.
And you have exactly the same API as just opening a standard file.
Right.
So that was like with open as file stream, dah, dah, dah, dah.
You go do your thing.
Right.
Well, a lot of us are fans of using, pathlib, right?
So create the path.
You do like a cool thing.
You do the, the slash, the division is overridden to look like you can separate the file names
and all that.
Right.
So there's this thing called universal pathlib.
Now that's, it looks like this project was created two months ago and this was sent in to us.
So I want to say thank you to Justin Flannery.
Remember he had that, that camping CLI thing that we could find campsites that are sold out and stuff.
Yeah.
Uh, and so we talked about that a few months ago.
So he sent this in and said, look, FS spec is awesome, but now there's a universal pathlib and it extends, the built-in pathlib.
So the pathlib module dot path API to use basically FS spec, which is awesome.
And so if you want to talk to things that are not file systems, but you really like the path class, then you can use this one.
Either saying, you know, import it as you path.
You could also just import it as path if you want, for long as you're not mixing it up with the other and just treat it the same.
Right.
So for example, you could say you path, instead of giving it a directory name or a file name, you would say like S3 colon, you know, slash, slash, some path to your S3 information slash some file.
Right.
And you could ask, what is the name?
What is the suffix?
Does it exist?
And read it.
And so on, just like you would with a normal file.
But now this thing is in S3.
We have file.
We have Azure storage.
We have HTTP and HTTPS.
We have Hadoop, Google cloud, S3, web dev.
And one, I think that would be really cool for testing Brian is memory.
Yeah.
Right.
You want to create a file, work with it, make sure, you know, pass this path like object to other APIs, let it do things.
And then it just goes away when it goes away.
Right.
That's pretty cool.
Yeah.
I love using memory file systems for testing.
Yeah, absolutely.
Like SQLite has one memory colon, I think it is, or maybe two colons on the front.
Same thing for the database.
But yeah, this is really handy.
Not to be, you might be wondering like, why would I ever use memory?
Because you don't want to touch the file system.
You just need to pass a file and there you go.
So super simple.
There's a little example notebook that I blasted past somewhere.
People can check that out if they want to just see how to use it.
Okay.
A bunch of examples play with it.
So if you are working with these alternative file systems, this is definitely worth giving it a look.
Yeah.
Cool.
Nice.
All right.
Well, I have no extras.
How extra are you feeling today?
I guess I don't really have any extras either.
Just thinking something funny might be nice.
I think so.
And I know that you've done, you do a lot of C these days still, and I've traditionally done some, although not too much lately.
So I want to have both a joke and something to help people think about pointers and pointers to pointers.
Because Python is all about pointers, even though we don't realize it, right?
When you create a variable, it points out to a thing.
You've got a list.
It doesn't hold the value of the thing that's in the list.
It holds the pointers that point to the things that are the values.
So here's the joke.
There's an int just written out in memory, just out in space floating there.
And there's an int star to a pointer to the int.
It's like an anime character pointing out to it.
And then what is a pointer to a pointer?
Well, it's just the anime character pointing at the int star that points over to the other one.
What do you think of this?
I think it's just a great, I agree with the comment.
It's just a great way to describe pointers.
Actually, somebody pointing.
Yeah.
It seems completely non-scary.
Whereas thinking about int star star avoid star star, something like that is pretty crazy.
Well, it's got 18,000 likes on, I don't know what it's on.
What website is this, Brian?
The company formerly known as Twitter?
Yes.
And yet what is the title of the pages?
So and so on Twitter and the domain is twitter.com.
But the logo is X and I don't know what a mess this is.
But anyway, the joke is funny.
Well, the next, so the, and the icons, there's an X for closing, which is still confusing.
Yeah, there's two X's in my tab up there.
Yeah.
The left X and the right X.
Yeah.
We just, hopefully nobody renames their company greater than greater than and weird things like that.
Yeah, absolutely.
So, hey, I want, want to add one more funny thing.
This is not really programming related, but I've been watching a lot of like streaming, catching up on some TV shows.
I'm watching.
I can't remember the name of it now catching up and I want to skip through the beginning.
Have you ever done that on streaming shows?
You skip the intro.
Right.
So, I saw this the other day.
It just cracked me up.
Apparently, it's rude to poke someone in the head, the forehead and say, skip intro when they start talking to you.
I know people heard the first hour.
Yeah.
Like I, okay, can you skip the preamble and just go to the, whatever you wanted to talk to me about.
So.
Pretty funny.
I imagine it probably is a little, little rude, but you know, sometimes you're in a hurry.
Yeah.
You've heard it three times already.
So get to the end.
Awesome talking with you as usual.
Indeed.
Thanks for being here.
Thank you to everyone who is listening and everyone who participated in the live stream.
See you all next time.