Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 275, recorded March 15th, and I am Brian Okken.
I am Michael Kennedy.
And I'm Emily Morehouse.
Yay, thanks for coming.
I also want to give a shout out to Microsoft for Startup Founders Hub, and we'll learn more about them later in the show.
So welcome, Emily.
And if people aren't familiar with who you are, who are you?
Yeah, of course.
So I'm Emily.
I am the Director of Engineering and one of the co-founders of Cuddlesoft.
So we are a creative product development agency focused on web, mobile, IoT, and the cloud.
I'm also a Python core developer and the Python conference chair for this year.
Awesome.
That is awesome.
Said another way, you're quite busy.
Yeah.
I also have a 10-month-old, so, you know, not a lot going on in my life.
Yeah, no, a lot of time to binge watch Netflix.
10 months.
So are you pretty busy for PyCon already?
So interestingly enough, this is kind of a time that goes into autopilot in a way.
You know, like most things are already set in motion that need to be set in motion.
So it's really, we're working on the fun stuff right now, like, you know, speaker and staff gifts and stuff like that.
But otherwise, it's pretty smooth sailing and just sitting back and watching COVID numbers and hoping that we don't get another spike before April 9th.
Yeah.
Fingers crossed.
This will be the first PyCon after COVID hit.
So hopefully everything goes great.
I know people are excited.
Yeah.
Well, Brian, do I have the first one?
You do.
Do we have to wait?
Do we have to wait for me or can I talk about this?
Yes.
I'll wait.
Well, let's wait.
I'm very excited to talk about this one, actually.
This one comes from Frederick Aberpil.
I believe listens to the show a lot.
So hello, Frederick.
Nice work on this.
I was working on the Python Bytes website of all things, and I wanted to do some stuff with like uploading MP3s and having a bunch of automation happen behind the scenes.
And one of the things I did not too long ago is switch over to an async database.
I think we talked about moving to Beanie and some of the cool stuff I'm doing to like halfway move to async, but not all the way yet.
Not until we're quite ready.
But as part of that, I'm like, well, all this file stuff, this is kind of slow.
Like, this is a couple of seconds.
Is there a way to sort of set the web server free while we're doing this work?
Right.
And some of that involved calling subprocesses.
I thought, well, maybe there's some third-party package like AIO files that I could use that would allow me to asynchronously do subprocesses instead of the subprocess module.
So I did a quick Google search and I came across Frederick's article here.
And much to my surprise, I don't know if you all are aware of this, but built-in, asyncio has async subprocess management already.
That's pretty cool.
Isn't that cool?
Yeah.
Emily, have you played with this any?
Yeah.
You know, I actually think I've used this exact blog post, which is super funny.
I was actually just recently writing, like, CLI regression test and pytest.
And you basically, like, test running two different servers.
And I was, like, fighting with subprocess to get it to work.
I don't think they were using a new enough version that I could use async await, but I definitely remember referencing this.
So, yeah.
Yeah.
Very cool.
So, you can just say asyncio, the module, dot create subprocess exec for just running it.
Or if you need to sort of follow along and see what's going on, you can use even the shell one that requires shell commands like a CD or an LS type of thing.
And then you can just grab the standard out from set that to be asyncio subprocess dot pipe and so on.
You can get the results out of it and everything.
So, you just do things like await creating a subprocess with a shell or execing it and so on.
And then you can await communicating with it, which I think is pretty cool and so on.
So, not a whole lot more to say other than if you're doing stuff with subprocess and you're moving already into other areas where async and await are very doable.
Think FastAPI, SQL model, the SQLAlchemy 1.4 or later, where you're already doing a bunch of other async stuff.
You know, go ahead and write this in the async way so it just sort of flows into the rest of what you're doing.
That's pretty cool.
This is from like 2017.
It's an older article, isn't it?
Yeah, it looks like it.
Yeah, I mean.
Yeah.
It's news to me, maybe not news to the world.
Like Emily said, she was already working with it previously.
But yeah, I think it's great.
Right.
Well, the subprocess communicate is sort of people often shifted over to just run.
So, I'm hoping there's a run version of that too.
Yeah, probably is.
Anyway.
Cool.
Indeed.
All right.
Well, I'm going to explain some stuff to us, Brian.
I must.
I see the author of what you're about to talk about out in the audience as well.
Yeah, that's also.
That's very cool.
Well, this is pretty fun.
Definitely an exciting one.
Yeah.
So, this comes from.
This is TypeSplainer.
And let me explain it to you.
So, I don't know.
It's just this cool thing.
It popped up last week.
We saw it.
This is from Arian.
Sorry.
Arian Malik Wasi.
It's a pretty cool name, by the way.
But so, this is this little neat Heroku app that has you.
It's pretty simple.
You.
Well, I don't know how simple it is behind the scenes.
But.
Simple to use.
To use.
It's very simple.
You pop in any sort of Python code that has type hints in it.
And so, this one has like, for instance, we've got an example up that the default with
like a callable that takes a stir and an int and a generator.
And yeah.
So, there's a bunch of type hints in here.
This is even like kind of more than most people use all the time.
But.
And then you hit TypeSplain.
And it will show you what the different type hints mean and translate them into English for
you.
And it's just pretty, pretty cool.
I like it.
One of the things that Wasi said that he was also, when he was developing this, he was
on his way to developing a Visual Studio code plugin.
And so, there is a, if you search for TypeSplainer as a VS Code plugin, that functionality is available
to you right in your editor as well.
So, this is pretty neat.
Yeah.
This is really cool.
This explanation you have there, like dictionary of list of set of frozen set of, like, oh my
gosh, the description is something like a dictionary that maps a list of sets of frozen
sets of integers onto a string.
Like, that's way more legible and internalizable than.
Yeah.
How many brackets deeper we were?
Four brackets deep in that type information there?
Yeah.
It's interesting on Twitter with the announcement of it, or we heard about it through Will McCoogan,
or at least I did.
And some of the comments were like, not that this isn't cool.
It was like, oh yeah, this is cool.
But maybe Python shouldn't be this complicated if you have to explain it.
But it's...
Have these people done C++?
Let me just ask them.
I know.
You don't have to use types if you don't want to, but there's a lot of places where types
are helping out a lot.
And if you're running into somebody else's code that has some types on there that you're
not quite sure what that's going on, throw it in TypeSplainer and you'll be able to figure
it out.
Absolutely.
Yeah.
And I did actually take a look.
What do you think about this?
Oh, I think this is awesome.
I think I absolutely agree.
Like, you know, mypy has allowed us to do gradual typing and all that.
But a lot of times you do jump into somebody else's code base and you're like, whoa, these
are more types than I've ever seen.
And so being able to kind of convert it really easily is nice.
And I did actually take a look at how it works under the hood.
There's a really big if statement of like serialization.
But then it also, I'm a nerd for anything AST related.
And so it uses like the mypyParse under the hood, which is actually relatively complex
for what it needs to handle based on, you know, different Python versions and whatnot.
Wow, that's pretty awesome.
Nice.
Yeah.
The very first time you were on TalkByth enemy was to talk about the AST, the abstract syntax
tree, right?
Yeah.
It was right around my first conference talk back in the day.
Yeah.
Awesome.
Yeah.
Way back in the day.
I think we met in Vancouver to set that up or something.
When you were up, you know, we met at PyCascades there.
I generally think of myself as a smart person, but people that can handle doing AST work in
Python, I'm like, oh my gosh, you know, it's over my head.
Yeah, that's pretty awesome.
One thing really quick before we move on, Brian, if you go to the homepage of the typesplainer,
which is basically the back one.
So it's got this fairly pathological insane example to show you, like you can take crazy
stuff and explain it.
Yeah.
But you can type in there, like you can take that code away and put whatever you want in
there and then hit typesplain.
So if you just made like a function that just took, you know, yeah, exactly.
Give it a name and do a dot, dot, dot.
Yeah.
Give the function name.
You'll be good.
And then you hit typesplain.
Oh, it needs a function name.
Oh, I didn't.
It's not JavaScript.
Come on.
Brian knows.
Yeah.
Wasi.
I mean, it's not a super huge explanation of what an integer is, but like you can take
some random code and drop it and then go explain it to me.
Yeah.
I guess now you can also use the VS Code extension, which I haven't seen with.
Anyway, I thought, I thought this was cool as well and certainly saw a lot of people talking
about it on Twitter when it came out.
So, but final thing, I think this is noteworthy as well.
And I think it's worth mentioning.
Wasi is just 14.
So speaking of people like Emily, who can do like AST stuff like crazy, like also, if you
write this when you're 14, well done.
You're on your way.
Plus it's, it's really good looking for something right out of the gate.
So it looks nice.
Yeah.
Awesome.
Yeah.
I also think the, the like architecture of it's really great too.
So I really like that he embraced sort of building out the tool itself and then building a CLI
and a web interface and a VS Code extension.
So I think that is a really great example of how to structure a project like this too.
Nice.
Yeah.
That's awesome.
Hey, Emily, we lost your screen.
If you want to share it back or I can just add in while you're working on that.
Let me just follow up with Sam real quick who pointed out, be super aware of the limitations
of your hardware.
When you try to write files in async environments at this project that ground to a halt because
too many workers are trying to run at once.
Yes, absolutely.
Good point, Sam.
That is generally true for any limited resource that you point async things at, right?
If you're going like async against a database and a couple of queries will max it out.
And if you end up hitting it with a hundred queries at the same time, it's not going to
go faster.
It's only going to get worse as it like fights for contention and resources and stuff.
And then on this one, on the typesplainer, Brian Skin says, agreed.
Very nice work.
So awesome.
All right.
So this is another...
Emily, you're up for the first one.
Yeah.
So this is another one of those like new to me things.
But Marlene's article just came out and that's how I actually found out about it.
So Marlene wrote this really excellent introduction to using IBIS for Python programmers.
IBIS itself has been around for like seven years or so.
It's a project I think that was started by Wes McKinney.
But they are a productivity-centered Python data analysis framework for SQL engines and Hadoop.
So you get a ton of different backends.
It's going to compile to, you know, basically any flavor of SQL database and then a bunch
of like more data science focused backends.
But this popped up on my Twitter feed from Marlene and it's just a really great introduction.
Also just a really interesting sort of application.
So she went through and wanted to pull some like art information about a city that she was
going to visit because she likes to experience the culture of a new city.
So it just walks through like how to get data into it and then how to interact with it with IBIS.
So I'll actually switch over to the IBIS documentation.
Oh, and this is now just different because it's small.
But yeah, I think I was really interested in it because we have like a pseudo legacy system
that we're moving all the migrations out of Django and we're actually managing it with a tool
called Hesura.
So we're so used to having, you know, Django that's going to use SQLAlchemy and ORM and
everything just kind of is magic from there.
And you give it a YAML file and you get seed data, right?
Right.
So we're trying to figure out how to manage seed data in like a wildly different environment
where you have to load it in via like the Hesura CLI tool.
And you need SQL.
And I don't want to write SQL, like anything I can possibly do to avoid that.
So this was a really neat way for getting around needing that modeling.
So let's see if I can get to this.
Super cool.
Yeah.
It also looks like it integrates with Hadoop and other things that maybe are not direct
SQL compatible.
It might need a slightly different query language anyway, right?
Yeah.
And it's super interesting.
So they have a few different ways that it works.
So it directly will execute pandas and then it compiled in a few different ways to either,
you know, those SQL databases, Dask, Hadoop, BigQuery, like a bunch of different stuff.
But yeah, it's not necessarily just going to be straight SQL, but it's going to
handle that for you.
So you're really sort of, you know, future proofing yourself away from that.
But yeah, they just got a ton of like really intelligent ways to filter data and interact
with data in a really performant way.
I'm actually going to go back to Marlene's blog post real quick and do some quick scrolls.
It's also like one of the most hystonic like tools to integrate with SQL that I've seen.
So she gets to the point where she has this database table.
So you just tell it, you know, your table name and you set the variable and then you
can interact with it as if it's just a dictionary.
So you've got your art table and you want to just pull these columns and you've got it and
it's there.
So you would say something like a db.table of quote art and then you say art, you know,
art equals the art bracket for artists and display and then boom, you get those back.
Right.
Yeah.
That's awesome.
As a dictionary, I guess or something like that.
Yeah.
That's cool.
So there's a ton of different things that you can do with it.
I highly recommend checking out their tutorials.
They've got a ton of different options.
My favorite one is the geospatial analysis.
So if you check out their example, they're going to show you how to pull information out
of a geospatial database and then a really quick way of actually like mapping out the data.
So if you check out these examples, I know it's not going to come through necessarily on audio,
but you can, you know, pull information out of these like land plots and then tell it to graph it.
And it gives you, you know, a really nice looking graph with all the data there in like a whopping
10 lines of code.
Wow.
Yeah.
Generating that picture in 10 lines of code.
That's, that's awesome.
Yeah.
It's pretty neat.
It makes me think I should be doing more with geospatial stuff.
Like I don't do very much because I'm always afraid like, ah, how am I going to graph it?
What am I going to do?
Like, but there's a lot of cool layers in that graph and everything.
That's neat.
Yep.
Yeah.
The API reminds me a little bit of PyMongo actually, where you kind of just say, you know,
dot and give it the name of things.
And it's really kind of dynamic in that sense.
And you get dictionaries back and stuff.
So yeah.
But it's different databases, right?
Right.
Yeah.
But I do like that perspective.
Like it really is kind of taking any database, but especially taking a relational database
and giving it more of a document oriented interface to it, which is pretty cool.
Yeah.
This is cool.
I definitely want to check this out for, especially for exploration.
It feels like it's really got a lot of advantages for data scientists.
Like they're going to fire up a notebook and they're like, I just need to start looking at
this and playing with it.
And they don't really want to write queries and then convert that.
Right.
Well, it also looks like, as far as I can tell, it looks like both in this article and
in one of the tutorials on the main webpage is that there's a good relation, almost a one
to one relationship between SQL, things you can do in SQL and things you can do here.
So that people already familiar with SQL can transfer over pretty easily.
So that's pretty neat.
Absolutely.
Yeah.
This is a nice find.
All right, Brian, before we move on, can I take a second and tell you about our sponsor?
Yes.
Very excited about this.
I think it's a big opportunity for people.
So let me tell you about Microsoft for Startups Founders Hub.
This episode of Python Bytes is brought to you by Microsoft for Startups Founders Hub.
Starting a business is hard.
By some estimates, over 90% of startups will go out of business in just their first year.
With that in mind, Microsoft for Startups set out to understand what startups need to be successful
and to create a digital platform to help them overcome those challenges.
Microsoft for Startups Founders Hub was born.
Founders Hub provides all founders at any stage with free resources to solve their startup challenges.
The platform provides technology benefits, access to expert guidance and skilled resources, mentorship and networking connections, and much more.
Unlike others in the industry, Microsoft for Startups Founders Hub doesn't require startups to be investor-backed or third-party validated to participate.
Founders Hub is truly open to all.
So what do you get if you join them?
You speed up your development with free access to GitHub and Microsoft Cloud computing resources and the ability to unlock more credits over time.
To help your startup innovate, Founders Hub is partnering with innovative companies like OpenAI, a global leader in AI research and development, to provide exclusive benefits and discounts.
Through Microsoft for Startups Founders Hub, becoming a founder is no longer about who you know.
You'll have access to their mentorship network, giving you a pool of hundreds of mentors across a range of disciplines and areas like idea validation, fundraising, management and coaching, sales and marketing, as well as specific technical stress points.
You'll be able to book a one-on-one meeting with the mentors, many of whom are former founders themselves.
Make your idea a reality today with the critical support you'll get from Founders Hub.
To join the program, just visit pythonbytes.fm/foundershub, all one word, no links in your show notes.
Thank you to Microsoft for supporting the show.
Yeah, so $150,000 credit people get.
So if you're doing a startup, you know, that would have been awesome when I was trying to do a startup.
Now, this next thing I want to tell you about, I think, I think this kind of lives in your wheelhouse as well.
And keeping with the theme of the show, this one is recommended by Will McGugan.
So thank you, Will, for all the good ideas.
I know you're out there scouring the internet for all sorts of cool things to use on textual and rich and whatnot.
And this is one of the ones they said they are going to start testing on.
And that has to do with performance.
So the topic or the library is airspeed, velocity or ASV and the pip nomenclature.
And the idea is basically setting up profiling and performance as a thing that you can measure over the lifetime of your project rather than a thing that you measure when you feel like,
oh, it's slow.
I need to go figure out why it's slow for now.
So as you automatically do, as you do check-ins, as you know, like CI runs and stuff like that.
So probably the best way to see this is to just like pick on an example.
So if you go to the link in the show notes, airspeed, velocity, there's a thing that says, see examples for AstroPy, NumPy, SciPy.
I'll pick up AstroPy.
And you get all these graphs.
So each one of these graphs here is the performance of some aspect of AstroPy over time.
How cool is this?
Look at that.
That's pretty cool.
And if you hover over it, it shows you the code that runs that scenario.
Wow.
Yeah.
And, you know, this is a sample, this is a sample.
And then they did a huge improvement.
You can see there are like two massive refactorings on the sky coordinate benchmarks, you know, scalar, whatever this is.
Right.
This particular test they did there, it goes along pretty steady state.
And then there's a big drop and a little spike up and then another big drop and then steady state for a long time.
So wouldn't it be cool to have these different views into your system about like how it's performing over time?
Yeah.
So lower is better, right?
I believe lower is better.
Yeah.
I think lower is better.
You can pull up regressions.
You can say, okay, well, what got worse?
Like, for example, timetable outputter got 35 times slower.
So that might want some attention.
And it lists the GitHub commit or really technically, I suppose it just lists the git commit, which is probably on GitHub, which is on GitHub.
So that you can actually say, this is the code that changed that made it go 35 times slower.
Wow.
That's neat, I think.
I think one of the other challenges here is what about, what if you wanted this information, but you're only now learning about this project, right?
You're only like now realizing, wouldn't it be great to have these graphs?
How do you get those graphs back in history?
So Will pointed out that you can actually connect it with your git repository and it will check out older versions and run it.
It'll like roll back in time and go across different versions and different versions of Python and generate those graphs for you, even if you just pick it up now.
That's awesome.
Any idea of if it's like restricted to packages or if you can also apply this to general projects?
I think you can apply it to general projects.
I don't remember where I saw it.
I got to pull it back up here.
Somehow I've escaped the main part.
But yeah, I think if you look at the using airspeed, you basically come up with a configuration file that says, you know, this particular project with these settings.
And then here's like the run command.
You come up with one of these test suites.
I don't think it has any tie into packages per se because I think it goes against git, not against PyPI.
Yeah.
So pretty neat.
People can check that out.
But like here you can specify like which versions of Python or is this 2.7 stuff?
I don't know.
But yeah, so you can run it against all those old versions.
You can configure how it runs and so on.
Okay.
So you can even you can set up like since you're defining what's being timed, you can you can time large things like a particular workflow through lots of bits of code first.
Things like that.
Yeah, exactly.
So you basically come up with a couple of scenarios of what you would want to do that you're going to run against.
Here you can see like you can benchmark against like tags and things like that and git or branches.
Yeah.
So Will says he ran it.
Let's pop his up.
Ran it against two years worth of rich releases.
That's cool.
And found a performance regression.
Nice work.
I love it.
Optimizations that made rich slower.
Isn't that true?
Like this is going to make it better.
No.
Yeah.
So pretty cool.
And have to give a nice shout out to the full embracing of the my Python reference.
If you go back to the AstroPy version in the top left corner, it says airspeed velocity even unladen.
Oh, yeah.
I did notice that.
That's awesome.
It's nice.
Yeah.
Very cool.
Well, yeah.
Thanks for sending that over.
Well, yeah, I got some projects.
I'd like to do that on.
But speaking of testing things, this one comes from Anthony Shaw.
This is Perflint.
So this is a this is a pilot extension to check for performance anti patterns.
And it's Tony somewhere.
Anthony.
Some guy named Anthony Shaw.
Anthony Shaw.
I thought we mentioned him.
Tony Baloney.
Says.
Oh, here it is.
Project is an early beta.
It will likely raise many false positives.
So I'm thinking that might be why he went went with an extension to pilot instead of like an extension to PyFlix because or flicate because pilot gives lots of false positives.
No, at least in my experience with pilot.
It is takes some configuration to get happy with it because it will show you things that maybe you're OK with.
Like I threw pilot against some demo code that I have for like teaching people stuff.
And I'm using short variable names like, you know, X and Y and things like that.
And one of the one of the restrictions for pilot is you have to have almost most everything has to be three characters or longer.
And, you know, for production code, that's probably fine.
But if you have different rules, you can change that.
But back to this.
I really like I like the idea of having something look over my shoulder and look at performance problems because I I'm an advocate for don't solve performance problems unless you find that there's a performance problem.
So don't do premature optimization.
However, having some things are just kind of slow that you should get out of the habit of doing like when using list in a for loop, if the thing that you're using a list of already is an iterable.
That's that's a big performance hit if it's a huge thing, if it's because that turns an iterate iterable or a generator into an entire list.
It creates the list.
You don't need to do that.
So that's a that's a big one.
Anyway, there's a whole bunch of different things that checks for.
And I like the idea of just as you're writing code and as you're test, you know, running this and and trying to figure out if, you know, there's problems with it.
You can kind of get out of the habit of doing some of these things.
So, yeah, these are nice.
It'll catch just some of the things you might think you need to do.
You're not super experienced with or whatever.
Right.
Yeah.
Like one of the things here is a error W201 8201, which is loop invariant statement.
And this is one of that's kind of interesting is like there is an example of taking the length of something within a loop.
And if that never changes within the loop, don't do the length in the loop.
Take it out of the loop.
Those are.
Yeah, there are.
Exactly.
There's a few examples that you like you might not notice right away, especially if you've taken something that was a linear some linear code that you kind of added it inside of a loop and indented it over.
And now it's in a loop.
You might forget that some of the stuff inside might not might maybe shouldn't be in the loop.
So, yeah, this example here, you're doing it 10,000.
You're doing a loop 10,000 times.
And every time you're asking the length of this thing that is defined outside the loop and is unchanging.
So you're basically doing it 10,000, 9,999 times more than necessary.
Yeah.
So kind of fun.
I'm going to give it a shot.
See what I think in as using it.
So, yeah, definitely.
Emily, do you use some of these linters or anything like this that give you warnings?
Yeah.
I mean, I think we mostly use Playgate, but I'm definitely curious to try this out, too.
I can see how this would be tricky to get really consistent errors for these things.
So props to Tony Bologna for taking it out.
Well done.
Yeah, this is exciting.
I'm glad to see this coming out.
I know he was talking about it, but I didn't see actually anything on GitHub yet or anything.
So, yeah, very well done.
Yeah, this is cool.
I like stuff like this that really takes you to that next level of like, this is something that somebody would hopefully notice in a code review.
But if you can automate it.
Yeah, I think that's a great point.
I think a lot of these things that would have to be a discussion during a code review, if they could be automated and you could save the code review for meaningful stuff like security or, you know, like, how are we going to version this over time?
And it's going to be tricky.
Like, are you really storing pickles in the database?
Let's not, you know, stuff like that.
Yeah.
All right.
Pep 594 has been accepted, which is super exciting.
So, Pep 594.
If you don't know what that is, it's a Python enhancement proposal.
So, a proposed change to the Python language itself.
And so, this one is removing dead batteries from the standard library.
It was written by Christian Himes and Brett Cannon.
I think I saw a tweet from Brett saying that it had been accepted.
So, this is just really exciting for anyone who's followed along with any of this discussion.
It's been a long time coming.
I think there was a major discussion about it at PyCon US 2019.
It must have been.
And shortly after that, there was a pep.
But it's been since then that it's kind of been off and on in discussion and finally figuring out what is going to be the thing that really works for everyone and for the future of the language.
So, this is going to be targeting version 3.11.
So, just a quick recap of the release plan for that.
Development on 3.11 will start this May.
So, May 2021.
The final release, even for 3.11, is not until October 2022.
And even then, this is just going to be deprecating modules.
So, it'll be deprecations in 3.11 and 3.12.
And it's not until 3.13 that it will actually be fully removed from the language itself.
So, you can kind of get a glimpse into how long of a process this is and how big of a decision it was to get everyone on board.
Yeah, it didn't look at all like anything rushed.
When I went through and read this, it was like, here's the things that we think we can take out.
Here's why.
There's a table in there that shows third-party alternatives to certain things.
Mostly, yeah, that's the one.
So, there's certain things in here.
You're just like, you know, that probably isn't needed or it's really superseded.
So, there's pipes.
But then we also have subprocess, which will take care of that.
And that's a built-in one.
And then async core.
Just use async.io.
But then there's other ones.
There's a bunch in here I've never even heard of.
Yeah, that's the thing, right?
There's one called Crypt.
And it's like, look, just use Passlib or Argon or Hashlib or anything that is better and modern.
You know, this was from 1994.
Cryptography is not exactly the same as it was then.
So, you know, maybe it makes sense to take it out, right?
Yeah.
I guess.
Yeah.
Yeah, I think it's a really like, it's a thin line to walk, right?
Like, some people are using these and some of these modules maybe didn't have a lot of like maintenance over time.
But that also meant that there wasn't somebody watching it for bugs or security vulnerabilities or anything like that.
So, the balance of is it worth pulling it out if somebody was relying on it versus the maintenance cost or the lack of maintenance that could really.
Yeah, it's a liability, right?
There's a CGI library.
That's something else.
That takes you back from 95.
Yeah, that's how I started.
But not with Python.
I was doing CGI with Perl way back in 95.
Yeah, that does go back.
It also talks about whether that bit of code has a maintainer and whether that maintainer is active.
For example, CGI has no maintainer.
Like, no one wants that.
One of the things that's interesting here is you could take this code and you could still use it.
You could vendor it into your code, right?
Yeah, now you're the maintainer.
Yeah.
Yeah, exactly.
It's all yours.
You can have that.
But you could just go to CPython on GitHub, get that module, copy it over, and now you kind of still have that functionality.
Just, you're taking it on.
I expect maybe one or two of these might end up in their own GitHub repository as a package that is maintained.
They did talk about that, right, Emily?
About that being one of the possible paths they decided against.
Yeah, that was like the big conversation back at the Language Summit in 2019 was, you know, could we get libraries on a, you know, more independent release schedule and pull them out of the standard library entirely and just have them be sort of their own standalone thing?
Which, as I have briefly outlined since the release schedule for 3.11, you can see that it is on like a very long scale timeframe.
So, I definitely agree.
I think that some of these that people are still using, people are either going to go in there and grab the code and hopefully grab the license with it as well.
Or they're just going to become, you know, modules that enough people care about that live on their own in PyPI.
I don't see anything here that I would miss, but that doesn't mean that there's not people using them, you know.
So, on the good side, I mean, it totally makes sense to like remove things, especially stuff that's not getting maintained and there's no maintainer and that possibly has bugs in it now.
Nobody knows.
But, like, what are some of the good aspects, other good aspects?
Is it going to make the library or the Python standard or the install smaller?
Or, I mean, you'd think, anybody know the numbers on that?
Okay.
I don't know the numbers on that.
But that is something interesting to look at.
I would say the biggest change is, like, maintenance.
Just no one has to worry about whether there's a bug in CGI that someone discovers because it's just not there.
Yeah.
And especially with CPython, there's often a very big, like, barrier to entry.
So, like, if a CGI bug was even filed by somebody, where would you start to debug it and reproduce it sort of thing?
Right.
And then the other thing, too, is maybe somebody else goes through the effort to fix it.
But it always takes a core dev to review that PR and get it merged in.
And so a lot of times, if you don't have an owner of a module, it's just not going to get a lot of attention.
So as a whole, it should be hopefully an impact on how we interpret core developer time.
Because right now, I think we're at, like, over 1,000 PRs open on GitHub.
So a lot of times, you know, it's not just core developers writing code.
And a lot of times, you can have even more of an impact being that person that, you know, tries to review PRs and keep that number down.
Brian, out in the audience, points out that the comment threads on discuss.python and elsewhere are really interesting.
If you want to see examples of these old modules still in use.
Yeah.
I've got a couple of them here.
I think I linked them in the show notes.
But if they're not there, I'll make sure it's in there.
Nice.
Yeah.
You got a link to Brett's discussion there.
That's cool.
No, I think this is good.
I think this is good.
And quick shout out to a new theme, right?
Yeah.
So it's a brand new PEP site.
So it's pep.python.org.
And there's this really lovely theme on it.
It's really clean and modern.
You've got a nice dark theme here as well.
Cool.
Yeah, I noticed the dark theme.
That was cool.
And I think it even auto adapts to the time of day, which is great.
Brian, is that it for all of our main items?
I think it is.
It is.
Do you have anything extra for us?
Would it surprise you if I said no?
Yeah, it would.
Nothing extra.
I know.
I always have like 10 extra things.
No, I don't have anything extra this week.
Oh, really?
Yeah.
Nice.
Okay.
How about you, Emily?
Cool.
Yeah, I've got a couple of extra things.
So as I was prepping for this, I looked at, I think it was just the most recent episode
before this one.
There was a blog post that I think Brian shared on like a better get flow that basically was
saying like, commit all your stuff, reset everything, and then recommit everything once
you're like ready to make a clean PR.
And so I wanted to share this as well.
This is one of my favorite tools that I learned about probably a few months ago.
Again, it's 2015.
Not a new thing, but new to me.
So you can do auto squashing of get commits when you're interactive rebasing.
So essentially, if you've got a ton of different commits, and you realize, oh, like, I had
a style commit, commit for styling all my new stuff, a few commits back, but like, I want
to make this one more change.
Instead of needing to, you know, rebase immediately or remember to, you know, stage it in a certain
way in the future, you can actually go ahead and just commit one more time.
And then you flag that commit that you're making with the fix up flag.
So it's just dash, dash, fix up, and then you tell it the commit that you're wanting
to sort of amend.
So you can just keep working like that, make it fix up commits.
And then the only thing that you do right before you PR is you tell it to rebase with auto
squashing.
So once you do that interactive rebase with auto squash, it's going to find all those fix
up commits.
And, you know, when you interact with rebase, you often have to like, move commits around and
tell it to squash into the previous commit.
You've got to get it in the right order.
This handles all of it for you.
And anything that's flag with a fix up, it finds that commit ID and auto squashes it back
in.
So you get a really, really clean history without having to like, redo all of your like, commit
work that you had done a lot of the way.
Yeah, that's really nice.
And this looks built into Git.
Yeah.
I've never heard of auto squashing.
I've definitely never used it, but it looks really useful.
Yeah.
Thank you.
Yeah.
All right.
What's your next one?
Yeah.
And then a couple, couple other cool ones.
There was a tweet from Dustin Ingram about an award that the Python Software Foundation
actually received.
It's from the Annie Awards, which is, you know, animation version of the Academy Awards sort
of thing.
And it was for Python's use in animation.
And so I think this is just super cool.
It's one of those like applications that you don't necessarily think about for Python all
the time.
I don't think it gets talked about enough.
I actually tried to find Paul Hildebrandt had a talk at PyCon Montreal, but I think it was
back before we were recording these.
So if you ever see Paul at a conference, you've got to ask him about, you know, how Python is
used in animation and at studios like Disney.
Oh yeah, that's really neat.
So exciting.
I would have never expected that, but that's great.
And congrats, Guido, for getting the award.
And two more quick ones.
The PSF Spring fundraiser launched yesterday and they're having a ton of fun with it launched
on at least Pi Day in the United States.
So if you donate with some sort of contribution that is related to the number Pi, you get like
a free swag band.
So just a fun twist on this.
You can donate $3.14 or $31.41 or $314.116.
It goes pretty far out.
If I remember Pi, there's a lot of numbers in there.
So yeah, just keep going.
Yeah.
Because whatever your bank account will allow.
Exactly.
All right.
Anything else you want to throw out?
Yeah.
Just one last quick one.
Just a small plug for us.
Cuddlesoft is hiring.
We have a bunch of different positions open, but we're especially always looking for Python
engineers.
We're a small team.
We're a team of about eight people right now.
Predominantly female engineering team.
And just like the pride of what I have done in the last few years of like building this
team.
So if you're looking for someplace that is always innovating, always focused on like really
high quality tested code.
But you want to work in a small team environment, get hands on with clients, get hands on with
product.
Come check that.
Cuddlesoft looks really cool.
You'd seem to be doing a lot of bunch of different small fun projects instead of just getting stuck
in like one huge legacy code.
So if you're looking to kind of bounce around from project to project and learn a lot, I think
that'd be a good place, right?
Yeah.
Absolutely.
All right.
Well, I have two jokes for us, even though I have no extras.
So I'm making up for it there, I guess.
Nice.
So Aaron Patterson said, I heard Microsoft is trying to change the file separator in
Windows, but it received tons of backslash from the community.
That's pretty funny, right?
But the forward slash works fine in Windows.
People just forget to use it.
It actually does.
It totally does.
And following along there.
Oh, Emily, I think this is the perfect follow on for you as well.
Do you ever look at people's GitHub profiles if they apply?
Like they say, yeah, right.
Of course.
I mean, it'd be crazy not to, right?
So this person here, you know, if you go to your GitHub profile, it will show you your
public activity over time.
And it'll say like on this day, you know, in September or on Monday, you had this much
work and then on Tuesday that much.
And it'll color like different colors of green.
Yeah.
So if you all check out the link here, we have a GitHub activity for a year that spells
out, please hire me in like the exact amount of commits on just the right day.
And I think that's...
I think there's some history manipulation going on here, but...
Probably some auto squashing.
I don't know.
I mean, hey, I would look at that and think that they had some decent enough Git skills
to manage that.
It does mean that you're probably not doing like normal Git work on one hand, but on the
other, like I'd have to think for a while to figure out how to get it to draw that out.
So that's pretty cool too.
It's one of the main reasons why I switched my blog to Hugo so that blog posts count as
Git commits.
Exactly.
Double dip.
Yeah.
Nice.
Well, that's what I brought for the jokes.
Nice.
Well, thanks everybody for showing up.
Thanks, Emily, for showing up here and also for the Walrus operator.
Love it.
Yeah.
And we'll see everybody next week.