Python Bytes - #318 GIL, How We Will Miss You

Episode Date: January 10, 2023

Topics covered in this episode: PEP 703 - Making the GIL Optional in CPython FerretDB Four tips for structuring your research group’s Python packages Quibbler Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/318

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 318, recorded January 10th, 2023. I'm Michael Kennedy. And I'm Brian Ocken. And this episode is brought to you by Microsoft for Startups Founders Hub. Thanks to Microsoft for again supporting the show. And Brian, I just want to let people know real quick at the beginning here that they should join us here on YouTube, like right now live if they want. They can go to pythonbytes.fm slash stream slash live or just go to the website and click live stream at the top.

We typically record on Tuesdays at 11 a.m. at Pacific time. And you can also see the older video versions. People want to find them there. So it's always nice to have people in the audience. And we also put information in there about future episodes. So if for some reason it changes, we keep that up to or you do. Usually what I'll do is I'll just schedule whatever time we're going to record a week in advance and YouTube will notify you if you smash the bell, you know, that sort of thing.

Smash the bell. Yeah. What do you got to kick us off with today? Well, I want to start with something like right hot off the presses. So we, um, pep 703, this was, uh, suggested by Will Shanks. Um, and the author is Sam gross and it really was, uh, the pep was created just yesterday, January 9th. Um, or at least, yeah, so that's pretty cool. Uh, so very recent new pe pep smell yeah it has that new pep smell um and um what also one of the things that that the pep thing uh peps.python.org has a uh uh like a dark mode and light mode thing i didn't didn't know that i was playing with that today anyway um so the pep 703 is making the GIL optional in CPython. I knew that there was talk about this.

I heard Guido talking about it, possibly going in 3.12, but I didn't know if it really was. And it does, I mean, it's still in draft stage, so it's not promised yet, but it's targeting 3.12, which is the one that's being worked on right now. It's pretty exciting. So yeah, a couple of things that's being worked on right now. It's pretty exciting. So yeah, a couple of things that jump out from reading just the title. Optional, not removal.

Yeah. Okay. That's, that's interesting. I have, like you said, it's still, still brand new. So I haven't got a chance to research this a lot yet to understand the nuances of what that is, but you know, a lot of the prior talk, we had the galactomy and other things like that. Eric Snow's sub interpreters, all of those were about how do we remove the gill or effectively remove it? And this is like, well, well, not really. It is not really optionally selectable while you're running. It's a the option is a compile time flag. So this is and we probably should link to that, that, um, that really long interview with Guido. Um, but there's a, there's an interview with,

uh, Guido van Rossum that's, um, that in it, he talks about some of the GIL challenges and it's an interesting bit, uh, conversation anyway. So there's a flag, a dash dash without Gil flag that's going to be added for compiling C Python. So when I first heard this, I'm like, well, I don't really want to compile C Python. I mean, I could, but I'm not that kind of guy that likes to do that in their free time. So we have good news. I'll share with that with you later um but the the idea around this is and there's a lot of a lot of interest because there's a lot more scientific computing and machine learning and all this sort of stuff that's running on python now that wasn't before or just i don't know what it was doing before

but there's a lot of there's a lot of interest in this and uh scientific computing especially has a lot of concurrency that you can speed things up dramatically if you can run if you've got like these huge vectors that you can all compute at the same time so there's there's ways around it we have some really fast libraries that can do this but these are like engineering feats that people have to do to make this all work and they're usually in c api extensions and you and whatnot so um one of some of the motivation is that the uh there's a there's a lot of obstacles for concurrency uh because the gill is in place so what do we do so the kind i'm going to jump to the uh the

the distribution part which i'm pretty excited about uh distribution um the distribution is is going to be easier than i thought. So I thought people are going to have to build it themselves. It doesn't look like that's the case. It looks like Sam is going to work with Anaconda to distribute a without Gil version of Python together with compatible packages. And I imagine, so this will take time. One of the things that's is going to be important is to get this out quickly so that people can start building packages. Because, and one of the reasons why I'm glad

this is almost a different distribution, I know this is going to be a lot of work, but people can't really use it until the packages that allow them to use it are there. Straight Pythons aren'tons the c layer might if you're integrating with c or something it might assume that there's a gill and not yeah the safety it needs to do or something yeah right and even even if there's no changes that have to be made they're going to be uh they're going to be have to these packages are going to have to be recompiled

but there probably are changes they have to make but But they're trying to keep it to a minimum. But anyway, they'll at least have to get recompiled and they'll be not binary compatible with both versions of Python. So we'll have this two Python world for a little bit. But it's really targeted. And I think going through Anaconda is a good way to do it.

It's targeted to people developing these C API extensions so that they can start developing it. So that's pretty, pretty neat. And this, this, this collection of packages that already support the GIL list, Python will grow over time. And I don't know, I'm okay with having that be coordinated through Nandacon that seems reasonable. Yeah. One of the things I loved about this article is it talked about some of the challenges. So zooming really fast. Apologies effects on Python library usability. There's effects, you want to be able to, GPU heavy workloads require multi-core processing

to coordinate the whole thing together. There's a lot of stuff that we've done engineering-wise to work around the GIL. And it's kind of exciting that this is, I actually didn't see this happening this quickly. So this is pretty exciting. Yeah, this came out of the blue for me too. The one of the things that the discussion, oh, cool. I found it. The what's going to change. So I had this surprise to me. The surprise to me was that the there's supposedly going to be relatively few changes to the public python and c

apis so this isn't like a moving from python 2 to python 3 you have to rewrite your python code hopefully you won't have to change your python code at all it's going to be some of these extensions and these are these i mean like the people writing numpy and things like that pandas they might they're probably going to have to do some changes and pillow and and you know types or what like pi torch and things like that they really care about this and they're going to be working with it but they they're the ones that didn't want the gill there in the first place so i think they're motivated to make these changes it's pretty exciting but okay so what what is changing and a lot of the internals of CPython? So there's and I think this is a fascinating thing just as a like a computer science discussion of of this is a big problem. What are the problems? Well, there's and how do we what are the changes to solve it?

And there's reference counting and memory management, container thread safety. Like if you've got multiple multiple threads using the same list how do you deal with that locking and atomic apis and there's a great discussion in here on all those so i really loved this just as a refresher of some of these cs topics and how they're still relevant in in today's programming so it's pretty cool yeah yeah the container one's pretty interesting especially with python's extreme dependency upon dictionaries. Yes. Even being like the foundation of classes and stuff.

The reference counting is the one that's always been held out as a holdup, right? Like, well, we have reference counting and that can be so fast because we don't have to do any locking or any thread safety around it. As soon as you remove the gillill all that stuff goes out the window it's it talks about a couple of building on on one of the things that was done previously which is pretty interesting you know sam gross behind this and a bunch of other folks have just put together a whole host you know a lot of this comes out of cinder i believe it meta um there's a lot of small building blocks this is not just like well here's the change right and one of the things that i saw in the um the reference counting section is

immortal i think it was immortalizing oh yeah right so one of the things was can we make it so they like basically we're pretty sure that we don't want to ever remove these so we're just going to take them out of the reference counting checks and just assume that they're going to be here for the life of the program. Yeah. Just for performance and memory caching and all that kind of stuff. However, you also don't have to lock something that you're not incrementing and decrementing because you've decided not ever to do that, right?

So there's like some interesting piling on effects. And also it was talking about, I don't remember the word, but something about a certain lock-free thread safe type of way to do the increment for the reference counting. I mean, I was familiar with just like brute force reference counting, of course. It's a common way to deal with shared objects. But one of the things I loved about this is the discussion around biased reference counting and deferred reference counting. The notion that statistically looking at how multi-threaded applications work, most objects are only accessed by one thread. There's not that many objects that are shared. So having like a, each object having a thread owner

and the process for what reference counting is for the owner is different than the process for the, or different, you know, the non-owner, non-thread owner, you know, people accessing the object. And all of this is hopefully invisible to the people using it. I mean, clearly at some point, we're going to have to have like some way in Python

to be able to utilize this. It's like, it can't be invisible forever. So it'll be interesting. Yeah. Yeah, the buy-in reference counting, that's the word I was looking for. That's pretty interesting. Like the owner thread might not have to lock it.

It just does whatever and the others have to care. Well, also a lot of this is around, I mean, we do reference counting, but partly because of the reference counting and how our object model is. surprised by when I moved from C++ to Python or picked up Python and with objects and everything is that like in C++, you totally know when the destructor happens. But in Python, we don't really talk about destructors too much. We have constructors, but we don't really put a ton of work in destructors because you don't really know when it's going to really go away. And I think that's a good thing because now we can say it's actually going to be a little bit longer. You thought it was going to, you know, it probably would have disappeared earlier, but

we're going to defer that and have a garbage collection phase where it also includes, uh, making sure that the threads are concurrency is saved and stuff like that. So yeah, interesting. It's a, it's a very fascinating read. I just had a quick read of it this morning, but, uh, it looks clever. And I'm, I'm all for it. I'm here for it. Let's do this. I don't want to like paint it too rosy. And everybody paying attention to this knows that there is a performance hit for single threaded stuff. So and I thought it was going to be larger. The reference in here talks about somewhere between a 5% and 10% performance hit. But we've already seen these massive gains in performance. And the work on improving the performance of Python is going to continue. So I'm personally optimistic.

I think that the gains in performance elsewhere are going to far outweigh the possible slowdown of, you know, single threaded stuff. I mean, a lot of people don't really care about 5% difference. I mean, the code they're running, that's more simple. It's probably not performance sensitive a lot of the times. And when it is, you might be trying to squeeze even more performance out of it, right? And, you know, my little mini here has eight cores python only cares about one of them yeah if i could use all eight or six or something i could do way more than five percent better you know so i could more than make up for that if i actually leverage this feature yeah and if i don't care about performance plus or minus five percent

probably doesn't matter yeah i don't i don't i Yeah, I think they have to bring it up because there's going to be people saying, ah, but it's going to be slower. And so I'm glad that- Yeah, and that's always been the reason we still have the gill, is it's like, we like to make changes, but they make the most common use case less good.

So we're not doing it, but maybe this is close enough, possible improvements even down the road. So yeah. Yeah, I'm just, it's it's gonna be i'm excited to see how this how this pans out so yeah i'm excited as well very very cool i would say certainly the biggest news of the show is right here and we got some good jokes and stuff people can stick around for those they should yeah stick around to the end like What do you got for us next? All right. Well, I want to tell you about the ferret.

Have you heard of ferret, DB? Have not. Like a mongoose, but it's not quite a – honestly, if you showed me a mongoose and a ferret and said, which is which, I don't know if I could tell. Maybe the ferret mongooses are more intense. I don't know. But ferrets are more pet-like.

They're pretty similar, right? Is mongo from mongoose? No, it's from Humongous, but there are some frameworks in the JavaScript space called Mongoose from the Node.js side. Anyway, so FerretDB is

this thing that I think someone told me about. Let me see if I got some credit. Yeah, this comes from John Boltmeyer. And thanks for sending that in. I ran across this. So FerretDB is pretty interesting. We'll see where it goes.

It's a truly open source MongoDB alternative. By the way, I'm going to accept the cookies. You know, a cool way you don't have to have cookie policy pop-ups is not to track other people. That's even better. But I'll go ahead and accept it for them. Our site doesn't have any, does it, Brian? Because we don't have third-party cookies. So 5,000 GitHub stars already.

That's pretty incredible. And these folks are big fans of MongoDB and also really big fans of 100% true open source. And that's why they decided to make this thing called FeridDB. So here I'll read from their page a bit. MongoDB is a life-changing technology for many developers, empowering them to build applications faster than using relational databases. Yes. However, MongoDB abandoned its open source roots, changing the license to SSPL, making it unusable for many open source and commercial projects. Now, MongoDB is still open source, but this is like, I'm pretty sure this is licenses.

Basically, you can't make our thing as a service and then sell it without us. Like AWS had a MongoDB as a service and Mongo's like, hello, we want to be, we didn't expect it to be used in this way. So I don't think it's, I mean, it's not like a huge bash against Mongo, I don't really think. But if you really wanted it to be unencumbered entirely, well, MongoDB is not it, right? Right. So here's the idea. So FerretDB is built on top of PostgreSQL, but it is wire compatible with MongoDB. That is, you can use the different libraries

or drivers from different languages, you know, Python, JavaScript,.NET, whatever. You should be able to just change the connection string over to the FerretDB and off it goes. Wow. And it exchanges the binary JSON encoding across the wire just like MongoDB does. I'm guessing they're using the json column

stuff in postgresql to match i couldn't imagine they're trying to do a relational thing over there they're probably just like stashing the blobs but yeah it's it's pretty neat what do you think that's actually uh the architecture that sounds great for an open source project to not try to do the entire database back end but built on top of postgres yeah i mean there's edge uh there's edge db right which is uh quite popular in the python space and i believe they're doing basically the same thing like build build something yeah powered by postgres under the hood maybe just the query engine i'm not sure if the database engine as well for the hd folks. I interviewed them, but still pretty, pretty neat. I can get ahead with the joke. Yeah. So Veridb, formerly MangoDB, is an open source proxy that translates MongoDB wire protocol queries

to SQL with Postgres as a Postgres SQL as the database engine. MangoDB. That's a little bit too close, I think. Yeah, a little bit. Mango, yeah, that's maybe pushing it too close i think yeah a little bit mango yeah that's maybe pushing it so yeah you pretty much write the regular mongodb code that you would would write but it apparently works now somewhere i don't know where the roadmap is let's see they did a blog post yeah maybe that's where i should be looking and on the blog post, they have something about their roadmap. I don't know. I'll link to it if I can find it. But there's a VeritDB roadmap, and there's one really notable thing that people are going to need to be holding out for, and that's indexes.

Oh, okay. And so if you don't have indexes, you have a real hard time doing fast database stuff. So I think they said they're trying to get it kind of all finished up by the end of 2023. So this is not like a, hey, you should just jump right on this and run with it. Because I don't think it's far enough along. It's written in Go, for what that's worth. MongoDB itself is written in C. So it's not like it makes it more or less friendly to Python folks.

So, oh, here's the public roadmap. Perfect. So it's linked off their GitHub pages. And so you can see the end of alpha is supposed to be in the past. And those look like they're all done. You can see their beta stuff they're working on. But then for general availability, this index stuff that's supposed to come. Actually, I said 2023. This is supposed to be done January 2023, which felt like a long time ago.

Not long ago, but that's actually now. So I don't know how far along it is, but support for issues, for rather indexes. Look, there's issue here. I don't see a lot of traffic on it, but still it would be basically required, right? If you've got many, many gigs of data, then you have to have indexes. Right. However, the devil's advocate here,

development work on a project that utilizes this can proceed before you get tons of users and stuff, knowing that it's coming soon, I guess. Yeah, that's a good point. If you trust it. Yeah, although because it's wire protocol you could just run mongodb and then flip it theoretically right you don't have to it's not like a complete new creation you've got to build upon right it's meant to to mirror something that exists so you could do that um yeah i think we've got like five six seven gigs

of data in the database that backs Python bytes. Like if you do queries against, you know, give me the 20 things out of this, these millions and millions of records that match this without an index. It's actually, I think MongoDB may refuse to do it. There are certain situations where it's like too much data, no index, not going to be able to answer that question. So it might be really slow or it might actually error out and say this, you need to create an index.

So anyway, long story short, like this is a big deal until this comes in. I would not touch it in terms of a, I'm going to try to run on top of this. Yeah. But if that, if that comes through, then you already have Postgres, but you want some kind of document like experience for part of your app or one of your apps, but you don't want to switch to Mongo, that would be pretty cool. So one of the things notable in the menu bar of FerretDB is careers. So this is intended to be something commercial at some point, unless they just feel like hiring people for the fun of it yeah that is interesting uh where are they going with it right so the i would imagine they have a

ferret db as a service yeah mad in mind out there but you're right it certainly it has an ink and uh i mean that's not necessarily bad that's probably a good thing that there's money behind it, but just interesting. It is interesting. Yes. Very interesting. All right. Well, fair to be something I put out there for people to keep their eye on, not necessarily to jump on right away, but quite interesting.

Yep. Oh, by the way, we have a couple of excited folks out in the audience. Gil Optional would be amazing, says Ciro. And I know that Ciro is working on some real high-performance web framework stuff. So that would be cool. And how about a Docker container pre-built with CPython with no GIL?

Pick your Docker container and run that one. Sure, that'd be cool. Yeah, that's not a bad idea. Yeah. And Seth out there says, good thing we invested in faster CPython earlier. So now we can roll it back a little. Yeah. I mean, kind of, we knew that was coming.

So that's one of the reasons for the speed ups in 3.11 and planned for future. So yeah, indeed. All right. Let's switch over to real quickly. Talk about our sponsor before we move on here. As I said at the beginning, this episode is brought to you by Microsoft for Startups.

We just got an email. I don't know if you saw Brian from somebody who signed up for the Microsoft for Startups program and said, this is a really great. I was a little bit skeptical, but I signed up and this is a really great project, a really great service and offering for them. And they actually, it's working really well. So that's great. Yeah, it was really good to hear. So, you know, Microsoft knows that starting a business is hard. They want to help support startups that can then later, you know, be customers of theirs, of course. So they put together this Microsoft for Startups program to help them understand what startups need to help them be more successful and to create a digital platform to help them overcome those challenges.

And they call that Microsoft for Startups Founders Hub. And it provides all founders at any stage with free resources to solve startup challenges, provides tech benefits, access to expert guidance and skilling resources, mentorship, network connections, and much more. It doesn't require the startups to be investor-backed or third-party validated. You just apply. Microsoft says it looks like you would be a good fit for this program. You're in. And with that, you get access to a bunch of cloud resources, GitHub and Azure, Office 365, I think. You also get access to OpenAI,

which, you know, chat GTP, pretty hopping these days and might be something cool to leverage. And through Microsoft for Startup Founders Hub, becoming a founder is also no longer about who you know. You have access to their mentorship network, which I think is one of the biggest values you probably get. Talk to people about idea validation, fundraising, management coaching, sales and marketing, and all those things.

And you get to book one-on-one meetings with those mentors. So make your idea a reality today with the critical support you'll get from Microsoft for Startups Founders Hub. To join the program, just visit pythonbytes.fm slash foundershub2022. The link's in your show notes. So if you're interested, give it a click. Yes.

All right. Over to you, Brian. Well, I want to guess transition is difficult for me apparently right now, as are words. Anyway, the next article I want to talk about is four tips for structuring your research group's Python package. So I think this is just a Python package, but research group, I think this is from David Aaron Nicholson. And I think the idea around it is a lot of people with scientific computing and various things like that might not be, might be struggling with lots of Python code. So they're

packing, you know, putting it into subdirectories and stuff like that. So this is talking about packages in that directory, in that sense of it's a directory with a dunder init and you can reference it by importing it through normal import the import mechanism it's not about packaging for like ipi or something like that it's still some really great information so the four tips are one give your packages and modules terse single word names whenever possible and there's some great examples of what not to do later. Number two, import modules internally instead of importing everything from modules. Make use of sub packages.

And the last one is prefer modules with specific names instead of things like utils, helpers and support. And this is everyone struggling with this including me even though i've been preaching this for a long time it's hard um there there's some great examples of what not to do so the uh the what was this the give your modules terse single word names whenever possible and i guess there's a couple examples of what not to do so there's a really long uh directory name called electromyography toolkit yeah that's a bit long and then prefixing everything with emg afterwards within it yeah don't do that um you don't need to just some great examples of better versions so right it already has the the

top level part of the package as the namespace. Yeah. If you want to be explicit, just, you know, package dot package. And so they're talking about how, what it looks like when you're importing it is different. So I'm going to scroll down of like importing stuff. I guess I'll just drop to one. A better thing would be like EMG toolkit. And I would say even even like is toolkit really adding any information maybe just emg or something um and then having instead of having like solvers

and a whole bunch of uh prefixes just put solvers in a directory name and then put the types of solvers underneath you don't have to have uh emgs under everything or yeah emg underscore brute force solver and a a star solver and all that it's just solvers dot a star so yeah brute force or something right yeah right and i'd argue that you could even just probably drop the toolkit and it'd be emg dot solvers dot brute force it'd be a better name but um i think so i'm not going to go through this entire thing, but import modules is something I've seen a lot of people do, like from package solver import, and then list all the things that they're importing. And I think, and I've been guilty of this,

doing this before also, especially if I'm only importing one. One of the things that people will do this for is because the entire name is too long. Well then, you know, make the name shorter. So instead of doing that, just import the package solver and then you dot reference everything else.

Right. Or do what the data scientists do. If you don't control the name, you know, import numpy as NP. Yeah. Then NP dot this. You can shorten the name for you,

even if you can't shorten it for others or and at the source right so one of the reminders is you can do from if you're in the same directory you can do from dot import solvers and then you can reference like solvers and entropy solver and things like that uh anyway uh some great um uh even discussion of sub packages of uh of and this is something that I always forget that is difficult it's a mind shift to say oh I'm going to throw things into a directory and then have a package but you can do that again it can keep going

down and some people forget to do that so it references that as well you can have packages inside of packages inside of packages I think Robert out of the audience has a great recommendation to simplify the code we got to write. Yeah. Just how about we just extend it a little bit from star import star.

And like, you just have access to everything. Sure, the startup time is 10 minutes, but it's fine. Yes. And Pamphil Roy is reminding us that, you know, one of the zen of Pythons is about these namespaces. Yeah, and I think it's just also be nice to people. Just people trying to write their code in Python, they're not doing weird stuff because they want to do weird stuff. They just don't know what the normal way to do it is. So gentle reminders like this post are good.

Indeed. What you got for us next? I don't want to really quibble about it, but let's talk about it anyway. Quibbler. So Quibbler actually is interesting, keeping with the data science theme. So this one here is a way to take Matplotlib and make it more interactive. So you probably know Matplotlib will make a nice, like printable, publishable, high quality image, but they're generally not as interactive as like Bokeh,

some of these other frameworks. So Quibbler is like your data, but interactive. Let me just play a little video for you here. And I'll just describe it. But this way, you'll kind of know what this is about if you haven't checked this out. So the idea is you could go and plot something with matplotlib, and you have some variable you would like to make interactive. You just wrap it in an iQuib, and all of a sudden, the entire UI becomes completely interactive, which is insane. So here's like a triangle with squares around each, based off each of the edge of the triangle.

And then if you just make the numbers, the inputs, this iQuib type, then all of a sudden you can drag them around and interact with them. And even works on like cells and zooms and other pictures. What do you think? This is amazing.

Also amazing use of video to show people how easy it is to switch. Yes. Thank you for doing that. Thank you for doing that, people. But yeah, this is a super cool project. I don't have a ton to say about it, actually. But if you're working with Matt Plotlib already, and you're like, you know what would be really nice is if we could move some of these things around and create interactive graphics a little bit more than just wrapping the independent variables in iQuib interactive bits and it turns the whole graph into something

that's pretty excellent. I think this is, it looks great. I don't see why you wouldn't want to use it. Yeah, that looks fun. Yeah, cool. And someone in the audience loves Quib, so they must have experience with it as well. All right, so if you were doing Matplotlib and you want to make it more interactive check this out awesome it's all of our

items isn't it brian even though somehow i seem to have like a screen full of tabs still i don't know how that works yeah so you've got some interesting python related stuff and i thought i would uh go with the tradition of python and say uh and now for something completely different i just ran across an article that i thought i'd share just quickly i'm not going to talk about it a lot um but um there was an article in washington post about how turtle moms talk to their eggs before they hatch and i just thought it was a fascinating read plus okay it's got pictures of turtles so um turtles are awesome i wasn't going to talk about it too much, but one of the things I thought was really cool was somebody went out and thought, oh, the turtle moms hang out in the rivers or somewhere near the hatch, the eggs on the sand, and they just wait for them or something.

Well, are they talking? Probably not. But they went out and recorded anyway. And it's lower frequencies frequencies that we don't normally hear and um that's also slower time frames like a conversation can be like hours for a reply so wow takes a while to go back and then also like some of the eggs talk to each other before they hatch um they can they can talk to each other to help possibly coordinate when to hatch because if there's predators around more of them will survive if they all hatch at the

same time so anyway just cool article check it out if you guys want to look at turtles yeah science is neat isn't it yeah yeah that's really cool so um kind of not one of my extras, but I'll go through this in is the next coming talk Python episode is a Brown, the story of imaging black holes with Dr. Sarah. I said that one. Yeah. So that's going to be really, really awesome. And then there's a good chance, not a hundred percent chance, but a good chance that I also will have a science show on the fusion, the fusion national ignition breakthrough with Python as well coming up. So very cool, very cool stuff. Very neat. You get to talk to so many cool people through that.

That's neat. I know it's, it's, I would never get to talk to these people. They're like, Hey, I have a podcast. Let's talk about it. Amazing. All right. Let's do your extras. Yeah.

Let's do my extras. So here we go. So I published the thing on RSS a little while ago and talked a lot about RSS. So I have more RSS stuff because I said Reeder, R-E-E-D-E-R, is a really cool thing, but it's Mac only. Other people are like, hey, guess what else I use?

This is neat. So there's a fresh RSS, which is like your own hosted RSS web app. I think it also does some read later type of things. Feedly. I knew about Feedly, but I thought it was just, I don't know, just some sort of web app type of thing. But apparently it has like a cool AI engine to help kind of recommend if you get like overwhelmed with all the stuff you subscribe to, you're like, well can't read it it's just insane you know it has a kind of a your own personal algorithmic feed which is i know algorithmic feeds often get a bad name but there are benefits too you know yeah have you used feedly lately i have not i've been using it for years so i didn't know about the ai bit but i

yeah i use it a lot yeah i thought that was the one you had said you were using so but yeah the the ai engine sounds at least interesting flim on um android people care about that and readwise we talked about but i've been playing the readwise and it continues to be interesting you can uh not only when i first thought of that oh rss and you know maybe read later but you can throw in like epub books you can do youtube videos and like it'll let you annotate the transcripts that it makes and it's it's pretty wild wow um and then okay going for more rss here is um just published all the talk python courses as an rss feed so if you want to subscribe to that then soon as we publish a new TalkPython trading course, like if we go down here, there's a PyTest one somewhere.

Getting started with PyTest, right? So that came out a couple months ago. And so people, if they're subscribed to the RSS feed, another one comes out, they'll get it straight away. It's cool, right? That is neat. Yeah, RSSing more of the things. Over at TalkPython, the podcast, not the courses. We were talking about this right before the show. I did a ton of stuff for sort of helping people find when was a particular person a guest on the show? When were they on the show? If they're on one episode, what other episodes did they do?

So here's a great huge list of tons of people who have been guests on the show. And Brian, who's in number one right now? I am with Brett as a close second. A close second. Yeah, so Brian's been on 10 times. Brett Cannon, nine. Anthony Shaw, nine. Dan Bader, six.

Lucas Shalenga, five. Cecil down there at five. It's Cecil Phillip as well. Anyway, this is a new resource on the podcast. So if you want to explore the data for the last seven years in a slightly different way, people can check that out. And congrats, Brian, for leading the pack there. Yes.

And last, I talked about how to do traveling around, just taking an iPad and still doing development work. And we talked about prompt and all those things. So I basically wrote up an article on that discussion I had there. So I'll link to that. People can check that out if they want to. So there's the written more formal version called Dev on the Road on my website.

Cool. All right. Ready for a joke? By the way, Robert out there is suggesting that we might need to update your photo. Now you got your cool hair. We might need to update you on that guest list there. That was a seven-year-old photo or something.

That's from when you were on the show the first time, maybe six years ago. No, I really do look like that other photo. What you're seeing right now is an AI-generated bot. Yeah, this is like a... Actually, Brian hasn't been here for a few years. This is a deep fake, and I invented him. I'm just kidding.

All right, speaking of brian is still embroiled in a lawsuit to try to get this to stop so the real brian will never defeat the ai okay so so i thought i thought of you actually brian when i saw this one um this is on programming humor and it says it has this uh doglooking thing kind of very deep in thought, projected to the sky for reasons I don't understand. But it says, am I testing this program or is it testing me? I suspect a lot of people can relate to having that go both ways. Deep thoughts. Deep thoughts.

And we've got a name for the AI. It's called brian gpt all right i know you got a joke as well for us maybe more involved than uh the floating dog okay i can't remember where i got this but uh every cloud architecture it's just i don't know it's an image with uh with some some stuff that i really there's a lot i'm not gonna cover everything but one of my favorite bits of this is the managed services, the mismanaged services

and the unmanageable services. They're held together by duct tape and like some kind of like super glue. Containers everywhere. I do like the cool databases that drive resumes and the real database that's actually doing all the actual work.

The plumbing. There's a huge bunch of plumbing around. It just has. The data engineers got very excited here. Yeah. It empties into a data lake. Which also drips into a data swamp. And there's a blame radius.

Services that stop stuff. There's one tiny cron job that keeps everything from falling apart. It's good. VPN of sadness. And of course, it's all backed by the freaking slick reverse proxy. Yeah, so this is found on Good Tech Things, which actually has a whole bunch of cool,

like funny images. So I might steal some more of these from you. Oh, we might hear from good tech things again this is this is pretty awesome all right well is that everything for us that is that is all of it so nice thank you everyone for listening brian thanks as always bye bye