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 Okken.
And this episode is brought to you by Microsoft for Startups Founders Hub.
Thanks to Microsoft for again supporting the show.
And I, Brian, 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 could go to pythonbytes.fm/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 date.
Or you do.
Yeah, exactly.
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 out off the presses.
So we have 703.
This was suggested by Will Shanks.
And the author is Sam Gross.
And it really was the PEP was created just yesterday, January 9th.
Or at least.
Yeah.
So that's pretty cool.
So very recently.
That new PEP smell.
Yeah.
It has that new PEP smell.
And what also one of the things that the PEP thing, peps.python.org has a like a dark mode
and light mode thing.
I didn't know that.
I was playing with that today.
Anyway.
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 312.
But I didn't know if it really was.
And it does.
I mean, it's still in draft stage.
So it's not it's not promised yet.
But it's it's targeting 312, which is the one 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.
OK, 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 Gilectomy and other things like that.
Eric Snow's subinterpreters, all of those were about how do we remove the gil 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, yeah, this is and we probably should link to that that that really long interview with Guido.
But there's a there's an interview with Guido Van Rossum that's that in it,
talks about some of the guild challenges.
And it's an interesting bit conversation anyway.
So there's a flag, a --without Gil flag that's going to be added for compiling CPython.
So and when I first heard this, I'm like, well, I don't really want to compile CPython.
I'm 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.
But the idea around this is in 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 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 one of some of the motivation is that the there's a there's a lot of obstacles for concurrency because the GIL is in place.
So what do we do?
So the I'm going to jump to the distribution part, which I'm pretty excited about distribution.
The distribution 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 is like quickly so that people can start building packages.
Because in one of the reasons why I'm glad this is like 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.
That like allow them to use it, you know, can are there straight pythons.
The C layer might if you're integrating with C or something, it might assume that there's a GIL and not 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 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 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 to 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 collection of packages that already support the GIL lists python will grow over time.
And I don't know, I'm okay with having that be coordinated through anaconda.
It 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 for people watching the video.
But there's a lot of discussion around the motivation of all the lot of the difficulties of different types of parallelism that you are hard to express with with the GIL in place.
And it's just an interesting, this part's an interesting read.
There's 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 didn't think, 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 two to Python three, 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, 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 pie 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 GIL 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.
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 gill, 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.
And, 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 at Meta.
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 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 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, you've decided not ever to do that.
Right.
So there's like some interesting piling on effects.
And also that was talking about, I didn't, I don't remember the word, but something about a certain, a lock free thread, thread safe type of way to do the increment for the.
Well.
For the reference counting.
I mean, I was familiar with just like brute force reference counting.
Of course, it's a, it's a common way to deal with shared objects.
But the, one of the things I loved about this is the discussion around biased reference counting and deferred reference counting.
The notion that like statistically looking at how multi-threaded applications work.
Most objects really are only like most, most things are only, 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, the process for what reference counting is for the owner is different than the process for the, or, or different, you know, the non-owner, non-thread owner, you know, people accessing the object.
And, and all of this is, hopefully invisible to, the people using it.
Um, I mean, clearly at some point we're going to have to have like some way in Python to be able to utilize this is like, it should, it, it can't be invisible forever.
Um, so it'll be interesting.
Yeah.
The bias reference counting, that's the word I was looking for.
That's, that's pretty interesting.
Like the, the owner thread might not have to lock it.
It just does whatever.
And the others have to care.
Well, and this 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.
I mean, one of the things I was 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.
Um, 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, 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 very 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, Rosie.
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.
Um, the reference in here talks about somewhere between a five and 10% performance hit, but we've already seen these like massive gains in performance.
So, and the, the work on improving the performance of Python is going to continue.
So I personally optimistic.
I think that the, the gains in, in performance elsewhere are going to far outweigh the possible slowdown of, you know, single threaded stuff.
I mean, a lot, a lot of, a lot of people don't really care about 5% difference.
I mean, the code they're running, that's more simple.
It, it's probably not performance sensitive a lot of the times.
And when it is, you, 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 5% 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 5% probably doesn't matter.
Yeah.
I don't, I don't, I don't, I don't, 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 also, that's always been the reason we still have the GIL is it's like, we would like to make changes, but they make a con 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.
I'm just, it's going to 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've got some good jokes and stuff.
People can stick around for those.
They should.
Yeah.
Stick around to the end.
What do you got for us next?
All right.
Well, I want to tell you about the ferret.
You heard of ferret DB?
I have not.
Like a mongoose, but it's not quite a, I 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 ferret DB is this thing that I think someone told me about.
Let me see if I got some credit.
Yeah, this comes from John Boltmeyer.
Boltmeyer, sorry.
And thanks for sending that in.
It said, ran across this.
So ferret DB is pretty interesting.
We'll see where it goes.
It's a truly open source mongo DB 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 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 ferret DB.
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.
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 a license.
So 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 is 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 ferret DB is built on top of Postgres SQL, 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 ferret DB 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 Postgres SQL 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 pretty neat.
What do you think?
That's actually, the architecture of that sounds great for an open source project to not try to do the entire database backend, but built on top of Postgres.
Yeah.
I mean, there's Edge, there's EdgeDB, right?
Which is quite popular in the Python space.
And I believe they're doing basically the same thing.
Like build something.
Yeah.
Powered by Postgres.
Maybe just the query engine.
I'm not sure if the database engine as well for the EdgeDB folks.
I interviewed them, but still pretty, pretty neat.
I can get ahead with the joke.
Yeah.
So, FairDB, 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.
So, yeah, you pretty much write the regular MongoDB code that you 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 FairDB 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 it does 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.
I don't know how far along it is, but support for issues, for indexes.
Look, this issue here looks, 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 him.
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 mirror something that exists.
So you could do that.
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.
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 FairDB is careers.
So this is not, 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.
So where are they going with it?
Right.
So I would imagine they have a FairDB as a service in mind out there, but you're right.
It's certainly, it has an ink and.
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, FairDB, 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.
A 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 prebuilt with CPython with no gill?
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 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 that 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 open AI, 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 to 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/foundershub 2022.
The link's in your show notes.
So if you're interested, give it a click.
All right.
Over to you, Brian.
Well, I was, 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 putting it into subdirectories and stuff like that.
So this is talking about packages 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, this is everyone struggling with this, including me, even though I've been preaching
this for a long time.
It's hard.
There are some great examples of what not to do.
So the, 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 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.
You don't need to.
It's just some great examples of better versions.
Right.
It already has the, the, the top level part of the package as the namespace.
Yeah.
If you want to be explicit, just, you know, package dot sub package.
And so they're talking about how, 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 like, is toolkit really adding any information?
Maybe just EMG or something.
And then having, instead of having like solvers and a whole bunch of prefixes, just put solvers
in a directory name and then put the types of solvers underneath.
You don't have to have EMGs under everything or yeah.
EMG underscore.
Or a brute force solver and a, a star solver and all that.
It's just solvers dot a star solvers dot 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 I think, so I'm not going to go through this, this entire thing, but import modules is
something I've seen.
A lot of people will do like a from package solver import and then list all the things that
they're importing.
And I think, and I've been guilty of this to 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 that you can shorten the name for you, even if you can't shorten it for others
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.
Anyway, some great, even discussion of sub packages of, and this is something that I
always forget that is difficult.
It's a, 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, you can do that again.
It can, it can keep going down and, and some people forget to do that.
So the reference is that as well.
So it's good.
You can have packages inside of packages inside of packages.
Nice.
I think Robert out in the audience, that's 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.
There's sure the startup time is 10 minutes, but it's fine.
Yes.
And then Pampho 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, you know, people trying to write, 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, 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, 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, I don't have a ton to say about it actually, but you know, if you're working
with matplotlib already and you're like, you know, what'd be really nice is if we could,
you know, move some of these things around and create interactive graphics a little bit
more than, you know, just wrapping the independent variables in iQuib interactive bits.
And it turns the whole, the whole graph into something that's, that's pretty excellent.
I, you know, I think this is, it looks great.
I don't see why you wouldn't, wouldn't want to use it.
Yeah.
That's, that's, that looks fun.
Yeah.
Cool.
And someone out of the audience says it loves Quib.
So they must have experience with 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 go with the tradition of Python and say, 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.
But 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 it's got pictures of turtles.
So 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, we don't, we, there's the turtle moms hang out in
the rivers or somewhere near the, the, the, the, the hatch, the eggs on the sand.
And they just wait for him or something.
Well, are they talking?
It probably not, but they went out and recorded anyway.
And it's lower frequencies, frequencies that we don't normally hear.
And, that's also slower timeframes.
Like a conversation can be like hours for a reply.
So it 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.
That's really cool.
So, kind of not one of my extras, but I'll go through this in is the next coming talk
Python episode is, around the, the story of imaging black holes with, Dr.
Sarah.
I, I said, 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 few, 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.
Um, let's do your extras.
Yeah.
Let's do my extras.
So here we go.
So I've published the thing on RSS a little while ago and talked about a lot about RSS.
So I have more RSS stuff because I said reader 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, now I 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, Android.
People care about that.
And read wise, we talked about, but I've been playing the read wise and it continues to
be interesting.
Cool.
Can, 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, 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 Talk Python Training course,
like if we go down here, there's a, pie test one somewhere getting started with pie tests.
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.
RSS seeing more of the things over at talk Python, the podcast, not the courses.
I, we were talking about this right before the show.
I did a ton of stuff for sort of helping people find when were, 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.
So a close second.
Yeah.
So Brian's been on 10 times.
Brett Cannon, nine.
Anthony Shaw, nine.
Dan Bader, six.
Lucas Lenga, five.
Cecil down there at five.
It's Cecil Phillip as well.
Anyway, if this is a new resource on the podcast.
So go, 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?
Oh, 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.
Yeah.
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.
No, just kidding.
All right.
Speaking of jokes.
The real Brian is still embroiled in a lawsuit to try to get this to stop.
The real Brian will never defeat the AI.
Okay.
So I thought of you actually, Brian, when I saw this one.
This is on Program and Humor.
And it says it has this dog-looking 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.
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 the floating dog.
Okay.
I can't remember where I got this, but every cloud architecture.
It's just, I don't know.
It's an image with some stuff that I really...
There's a lot.
I'm not going to 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.
Yeah.
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.
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...
Oh, we might hear from Good Tech Things again.
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.