Python Bytes - #275 Airspeed velocity of an unladen astropy

Episode Date: March 16, 2022

Topics covered in this episode: Async and await with subprocesses Typesplainer ASV perflint Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/275

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 Ocken. 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. 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 PyCon core developer and the PyCon 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, it's pretty smooth sailing and just sitting back and watching covid numbers and hoping that we don't get another spike before april may yeah fingers crossed this will be the first pycon after covid hit so hopefully everything goes great i know people are excited yeah yeah well brian do i have the first one do we have to wait do we have to wait for me or can i i talk about this uh yes i'll wait well let's let's await i'm very excited 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 Aberpill. 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 till 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 sub processes.

I thought, well, maybe there's some third party package like AIO files that I could use that would allow me to asynchronously do sub processes instead of the sub process 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 async IO has async subprocess management already. 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 pi test. 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 async IO, 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 could just grab the standard out from set that to be async IO subprocess.pipe and so on. You 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. 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 fast API, SQL model, the SQL alchemy 1.4 or later, where you're already doing a bunch of other async stuff, go ahead and write this in the async way. So it just sort of flows into the rest of what 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, 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, you're 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. That's also, that's very cool. Uh, well, this is pretty fun. Definitely an exciting one. Yeah. Yeah. So this comes from, this is type splainer and let me explain it to you. Um, so I don't know. It's just this cool thing. It popped up last week. We, we saw it. Uh,

this is from Arian, sorry, Arian Malik Wasi. Um, and it's a, it's a pretty cool name by the way. But, 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 it's simple 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 stirred and int and a generator. And, um, 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 type splain and, um 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 Wasey 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 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 it like oh my gosh uh 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 in that type information there yeah it's interesting on on twitter uh with the announcement of it or um uh we heard we heard about it through will mccugan or at least i did um and uh some of the some of the comments were like that that 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 oh i think this is awesome i think i absolutely agree like you know my pi 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 um 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 my pipe parse 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 Talk Python to me 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 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 um 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 a name you'll be good and then you hit typesplain oh it needs that it a function name, you'll be good. And then you hit type explain. Oh, it needs a function name.

Oh, I didn't. It's not JavaScript, come on. Try it in this type, let me say. Yeah, see? I mean, it's not a super huge explanation of what an integer is, but 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. Anyway, 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 really good looking for something right out of the gate.

So it looks nice. Yeah, awesome. Yeah, I also think 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. 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 type explainer, Brian skin says agreed. Very nice work. So awesome.

All right. So this is another for the first one. Yeah. So this is another one of right, Emily, you're up for the first one. Yeah. So this is another one of those 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 iBits for Python programmers. iBits 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 basically any flavor of SQL database and then a bunch of 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 a pseudo legacy system that we're moving all the migrations out of Django and we're actually managing it with a tool called Hasura. So we're so used to having, you know, Django that's going to use SQL alchemy 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 Hystera 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. 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 das kadoop um big query 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 um so you're really sort of you know future-proofing yourself away from that um 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 Pythonic 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 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 I thought it was like a really beautiful idea. So you would say something like db.table of quote art. And then you say art, you know, art equals,

say art bracket, quote artist and display, and then boom, you get those back, right? Yep. That's awesome. As a dictionary, I guess, or something like that. Yeah, that's cool. So yeah, 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 um 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 so oh 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. 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? But there's a lot of cool layers in that graph and everything. That's neat. Yep. Yeah, yeah. Cool.

The API reminds me a little bit of PyMongo, actually, where you kind of just say 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 against 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, 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? Yeah.

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 web page, 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 the 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 slash Founders Hub, 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, ah, 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 neat. 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 okay well what got what got worse like for example a timetable outputter got 35 times slower so that might want some attention and it lists the github command 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 if you wanted this information, but you're

only now learning about this project, right? You're only 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 if it's restricted to packages or if you can also apply this to general projects? I think you can apply this to general projects. I don't remember where I saw it. I've 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 this particular project with these settings, and then here's the run command. You come up with one of these test suites. I don't think it has any tie-in to packages per se, because I think it goes against Git, not against PyPI. Yeah, yeah, so pretty neat.

People can check that out. But here you can specify which version's a Python. What 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 set up, since you're defining what's being timed,

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 get yeah or branches yeah uh. So Will says he ran it 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?

This is going to make it better. No. Yeah. So pretty cool. And I have to give a nice shout out to the full embracing of the my python reference uh if you go back to the astro pi version in the top left corner it says airspeed velocity of an 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, uh, testing things, um, this one comes from Anthony Shaw. This is perfluent. So,

uh, this is a, this is a pilot extension to check for performance anti-patterns. And it's, uh, um, Tony somewhere, Anthony,ony um some guy named anthony shaw anthony sure we mentioned him tony baloney um 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 um went with an extension to pilot instead of like an extension to pyflakes because or flake eight because um pilot gives lots of false positives no at least in my experience with pilot um it it is uh takes some configuration to get happy with it because it will show you things that maybe you're okay with like i I threw pilot against some, 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 all most, most everything has to be three characters or longer. And, you know, for production

go, that's probably fine. But, uh, if you have different rules, you can change that. But back to this, I really like, um, 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, um, having some, 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 a big performance hit if it's a huge thing. Because that turns an 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 uh different things it checks for and i like the idea of just um as you're writing code and as you're test you know running this and uh and trying to figure out if um 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 they'll catch uh just some of the things you might think you need to do you're not super um experienced with or whatever right yeah like one of the things here is uh uh error w201 8201 which is loop invariant statement and this is one of that's kind of interesting is like hit there there's 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 uh 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 9999 times more than necessary yeah yeah so kind of fun i'm gonna give it a shot see what i think in as using it so yeah definitely emily do you use some of these

linters or any things like this that give you warnings? Yeah. 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 on. 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 like takes you to that next level of like, this is something that somebody would hopefully notice

in like 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 yeah security or you know like how are we gonna version this over time it's gonna 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 like the release plan for that, uh, 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. Um, so it'll be deprecations at 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 that are just like, you know, that probably isn't needed or it's really superseded so there's pipes but then we also have sub process which will take care of that and that's a built-in one and then um async core just use async io but then there's other ones um 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 pass lib 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 yeah it's a liability right there's a cgi library that's 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 pearl way back in 95 so 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. 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, 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, yeah, 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 i that doesn't mean that there's not people using them you know so on the good side i mean i it totally makes sense to like remove things especially stuff that's not getting maintained and there's no maintainer and and um does that possibly has bugs in it now. Nobody knows. But what are some of the other good aspects? Is it going to make the library or the Python standard install smaller? I mean, you'd think.

Anybody know the numbers on that? Okay. I don't know the numbers on that. It is. 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 yeah yeah and with especially with c python 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 take that off

sort of thing um and right and then the other thing too is maybe somebody else goes through the effort to fix it um but it always takes the core dev to review that pr and get it merged in um 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 a thousand 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, 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. Yeah. I've got a couple of them here. I think, 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've got a link to Brett's or the 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 the, 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. Yeah. I noticed the dark thing. 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 gift 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. It's not a new thing, but new to me. So you can do auto squashing of Git 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 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 fixup flag. So it's just dash dash fixup. And then you tell it the commit that you're wanting to sort of amend. So you can just keep working like that,

make your fixup 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 to 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 flagged with a fix up it finds that commit id and auto squashes it back in so you get a really really clean history um without having to like redo all of your like commit work that you had done yeah that's really

nice and this looks built in to get 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 um yeah and then a couple couple other cool ones um there was a tweet from Dustin Ingram about an award that the Python Software Foundation actually received um it's from the Annie Awards which is uh you, 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. 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 bag.

So just a fun twist on this. You can donate $3.14 or $31.41 or $314.116. And yeah, like that's... 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. KettleSoft is hiring. We have a bunch of different positions open, but we're especially always looking for Python engineers.

We're a small 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. Kettle Soft 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, 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. All right. Well, I have two jokes good place, right? Yeah. 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, 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, I would look at that and think that they had some decent yeah exactly 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 post count as get commits. Exactly. Double dip. Yeah. Yeah. So that's it. 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.