Python Bytes - #155 Guido van Rossum retires

Episode Date: November 6, 2019

Topics covered in this episode: Guido retires SeleniumBase Reimplementing a Solaris command in Python gained 17x performance improvement from C 20 useful Python tips and tricks you should know * Complexity Waterfall* Plynth Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/155

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 155, recorded October 30th, 2019. I'm Brian Ocken. And I'm Michael Kennedy. And this episode is brought to you by Datadog. Thanks, Datadog. We'll hear more about them later. Absolutely.

Brian, happy Halloween Eve. Oh, right. Halloween Eve. Yeah. Spooky. I have big news. It's not my big news news but i have big news to announce i'm on pins and needles guido has retired officially from employment which you know

congratulations to him that is awesome the news is guido van rassen has left dropbox not for another position but to retire so you know i think that's great to hear okay what does that mean about his involvement in python do you know i can only speculate i don't know for sure yet but my guess is actually that it will mean more python involvement not less okay but that's just based on i've been at big companies and even when they say yeah you can work on whatever you want there's meetings and there's bureaucracy and you know the proverbial tps report he's just like you know what okay we're doing nothing today and so if he can work on whatever he wants i have no idea what he's going to work on but there's got to be some cool creative projects maybe not

next week maybe he needs a year just to sit on the beach and look at some sunsets but then eventually i bet he will come back do something yeah okay he deserves a break and you're linking to an article a post that where he announced it also right yeah so there's a link to his announcement where he wrote you know sort of the goodbye and all that uh you know his final project there at dropbox was really to work on my pi and help them convert to two to three i think it's kind of fitting right like one of his final things is to convert one of the largest python code bases from python 2 to python 3 to kind of like close that gap i mean not globally but at least in that realm right you have a not just his announcement but a thank you guido from dropbox that's kind of cool yeah so

when i wrote this stuff down it was just i don't know half an hour since that news came out and it was just full of responses of so many things so i just grabbed a couple to you know i thought maybe a nice way to close out this little section is just to read some of the messages that people wrote to guido okay on his twitter announcement that linked to his full post so luc, Lucili says, thank you for Python and helping to increase diversity in the teams that you worked with. Enjoy your retirement.

Daron Leal says, congratulations and best wishes. Thanks to the many contributions to open source software and for inspiring me. Philip Guo, congrats and best wishes on the next era. Someone just goes by Steveve thank you for your contributions to the world my boy was just learning how to code python as his first programming

languages as i read this basically and freeman croach best which is i literally don't know what my teaching career would have been like without python wow i just want to say thanks for everything that's awesome he's really created something special and he's put a big dent in the universe, obviously, right? This is a huge accomplishment of what he's done and what he's shepherded over the last 30 years. And it's definitely high time for him to retire just so that he can go and just enjoy that, not stress. It's cool that everything is in place that basically this is not like, oh my God, now what? It's just like, oh, okay, well, that's great for him, right? Like, we kind of went through that last year, actually.

Yeah, it's an interesting thing. And yeah, I don't know what more to add other than also thank you. Yeah, I love the language. We both get to work on some really awesome stuff involving Python. Yeah. And the community because of it. So, yeah, thanks. All right, well, speaking of awesome stuff built with Python, what's next?

Yeah, hard to transition away from that. But I could have swore we'd covered this, but I guess we haven't. There's a cool project called Selenium Base. And what Selenium is, I mean, most people know it because in the Python community or other places for testing websites and and such you can also test apis with it but the selenium web driver is what people often use to access selenium through python and selenium base is built on top of that and it's built to in conjunction to work with it works with other things like unit test stuff but it works best with pi test of course. And it's kind of a layer on top that makes it quite a lot easier to, the Selenium web driver right out of the box has a lot of access. You can control, basically you're driving a web browser through from Python and the

Selenium base just makes it easier. There's a lot of easier things like I'm going to link to actually in the show notes i've got a a little snippet of code and it's really easy stuff like open a web page or open with a url and assert that a title is there and you know click on elements and you can use go back and click and examine things and assert stuff it definitely makes for testing testingpages a lot easier with all these utilities. But I also wanted to highlight, I was looking through it the other day, and there's some other things that it does that I thought was kind of interesting. One of the things that it has is, well, it has support for a lot of the major continuous integration services. It also has

a plugin built into it that you can take screenshots of test results. So let's say you have a test that fails because something isn't in the title or something isn't present or something's wrong. But what is there? And it's hard to describe with code, but it's not too bad with a screenshot. So it has the ability to take a screenshot on test failures. That's pretty cool. I wonder if you could use that as an assert itself. If you had

a screenshot of the way he said, this page looks right now, and if something goes crazy, like the CSS won't load or something is, could you assert that the pixels are the same? I mean, that's sort of visual testing. There is some visual testing with it. The main component that it has with it is making sure that the DOM is essentially identical. The DOM essentially reproduces the same thing. I don't think it does a pixel by pixel comparison. Maybe there's some plug-in for it. But there is some built-in stuff to do.

Basically, it should be about the same. Some other cool stuff, it works with Selenium Grid, which I wasn't quite sure what this was, but Selenium has built in an ability to run Selenium tests on multiple CPUs so that you can do things in parallel. Grid computing. I want to test all these pages and it takes a little while, so just spread it out. Okay, that's cool. I hadn't heard of that either.

That's nice. The other thing is assisted QA. So sometimes it's really easy to have a manual procedure that basically says, you know, we want to throw this together quickly. Just look at this page to make sure the graph is there. Sometimes it doesn't show up. So, or, you know, whatever, just make sure. And then pop up a little dialogue box that says, yes, it's there. There is some assisted QA. So it's like partial automation and that's kind of neat. And I think people poo-poo this too much. This is actually very powerful to have in place.

And sometimes it's a matter of pragmatism of getting things done. So this is cool. And then one of the other cool things is it has onboarding demos capability. So since you're using it to drive a web browser, you can use it to highlight things and pop up messages. And you can essentially give a kind of an onboarding demo of how to use a web page. So this isn't a testing sort of thing.

You would create a little demo to show somebody how to use some service. So that's kind of neat. Yeah, super cool. This looks really nice. I looked at the API that you got here. If you knew the tiniest bit of programming and you knew CSS, you already understand this.

There's no documentation needed. Obviously, you've got to have some documentation for real, but it's super clear. It takes away all of the find item by element and all those sorts of things. You don't have to do that too much. Anyway, a cool thing for if you want to automate

a web browser or test a website, make sure you check this out. It's good. Yeah, it looks great. I love it. Nice find. Well, another thing that's nice is Datadog. So this episode is sponsored by Datadog, a cloud-scale monitoring platform that unifies

metrics, logs, distributed traces and more. Trace requests across service boundaries with flame graphs, distributed traces, and more. Trace requests across service boundaries with flame graphs, correlate traces with logs and metrics, and plot the flow of traffic across multi-cloud environments with network performance monitoring. Plus, Datadog integrates with over 350 technologies like Postgres, Redis, and Hadoop,

and their tracing client auto-instruments common frameworks and libraries like Django, Tornado, Flask, and AsyncIO. That's cool. Get started today with a 14-day free trial at pythonbytes.fm slash datadog. Yeah, check them out. Big support as a show. Thank you, Datadog. Yeah, plus I love my purple t-shirt from them.

It's good. For sure. Now, this next one, I want to start by asking you a question, Brian. You've done a lot of C, C++. We even talked about that last time, right? Yes. Is Python slow? No.

People are slow. People are... Very good. That's a good question. Or a good response. I like it. I think the whether or not Python is slow is a really interesting question. And people sometimes say, well, I did a tight loop and I added X plus equals one, and it

was slower than if I did that on C. And so Python is slow, right? But then you could also say, well, I have a job. Somebody told me to implement this feature. If I started in C, I would be done in 10 days. If I did it in Python, I'd be done in six hours. So, and it took one minute to run in Python

and 30 seconds in C. So Python is way faster, right? It's half a day or three quarters of a day instead of 10 days. Yes. That sort of analysis. But sometimes it's interesting just to compare directly to these things. And we also have the C layer. So yeah, sure, it might be slower than some languages,

but then if you call it NumPy, then it's probably faster than most languages. There's all these interesting angles, right? Cython and whatnot. But this thing that I want to talk about now is this host mortem done by Darren Moffitt. So he re-implemented the list users command on Solaris. It was originally written in C and he rewrote it in Python. Okay.

Which is kind of an interesting thing. A couple of stats about it. So this is from like 19, the last time the C code was touched was like 1988. That's 30 years ago, 31 years ago. That's a good long while. And the implementation of this was about 800 lines. And it was written in a time

when the number of users were small and things like that. So it didn't have to deal with tons of data. And it even had some bugs, right? But it turned out that the basic implementation of what list users does is a set manipulation. Okay. You know what language has really good set implementation?

Python. Indeed. So he decided to try to rewrite it in Python. And it turns out the rewrite of list users in Python 3 was about a 10th the number of lines of code instead of 800 lines of probably fairly gnarly C code. It was down to 80 lines of Python. Well, that's pretty awesome. And a lot of the reason has to do with the fact that like, you don't have to reimplement set, you just, you know, say the word set and you're good good but what's really interesting is on top of that for a hundred

thousand users some tests they were doing the python version was 17 times 1700 faster than the c code as well wow that's incredible pretty cool huh yeah it's actually not surprising to me i'm glad we're covering it because it because it sure should surprise some people. Yeah, it doesn't surprise me all that much either. So yeah, it's pretty interesting. It turns out that it's source open but not open source if you want to look at the implementation. What I mean by that is the list users command is,

you know, this is from Oracle, right? Like they bought Sun, so now they have Solaris. So on 11.4 SRU 9 or higher, you could just go to slash user slash bin slash users. And it's a Python file, so you just look at it, right? So you can see what they're doing and you could compare the code and whatnot. But it's not open source and it's covered by the Oracle Solaris license. So you can check it out, but it's not open source. It's sourced open.

This is cool. So not only is this, somebody tried to do it and it was faster, it also is shipping now with Solaris. Yeah, that's pretty awesome. And it's Python 3. Of course.

Of course. I bet there's some useful tricks in that code. There probably are. Actually, I was thinking about this when you brought it up with sets. So I admit it, I am capable of getting link baited by the occasional listicle and this is definitely one of them it was uh 20 useful python tips and

tricks that you should know now there's some fluff in there that i don't think that's useful but there's a whole bunch of enough of that are useful that i think it's a good good thing to uh to take a look at like for one one, I'm not sure if, so chained assignment is one of the first ones that I looked at. And you actually don't, I don't see this in a lot of Python code. So is it bad Python style or something to have like x equals y equals z equals two or something? Do you know?

I don't know, actually. But you're right. I remember seeing this a lot in C. Yeah. But? I don't know, actually. But you're right. I remember seeing this a lot in C. Yeah. But not a lot in Python, no. No, but it does work in Python. But I guess make sure that you're not doing something that's too unclear. I highlighted that mostly because what I do see, what I use a lot is chain comparison. And people coming from other languages don't know you can do this so for instance in c if you wanted to have make sure that x was between two and eight you'd have to go two is less than x

and x is less than eight or something but with the python you can just chain them together and put them together right like two less than x less than or equal to eight yeah and you can have a whole bunch of them so you can have uh like a couple variables within ranges and stuff it's nice uh multiple assignment which i think of as unpacking i guess yeah i think that's tuple unpacking definitely that's common right like if you're gonna do a four you know index comma value and enumerate of collection something like that yeah but the thing that i've been using a lot more lately is tuple unpacking with the star operator. So, like if you put a star on one of the things you're unpacking

too, it takes all the leftovers. And so if you've got a whole bunch of stuff you're unpacking but you only care about a couple of them, you can name those and then just capture all the rest of them in like a star underscore or something. Yeah, throw away. Like, I know I have to have placeholder for this but I just don't care. I've seen it in a star underscore or something. Yeah, throw away. I know I have to have placeholder for this,

but I just don't care. I've seen it in a couple articles, but it listed merge dictionaries where you do star star of both dictionaries within another dictionary in brackets, and that kind of combines them. Debate as to what you should use, but I kind of like that because it's short.

I like that one. Yeah. And then joining strings. People new to Python, it's one of those things that it's nice to, you just take like a character or a string and join all the elements in a list or in any iterable. And this is something that for some reason, especially the people I'm familiar with that come from C or C++ to Python, this is hard for them to get around, that strings themselves have object methods on them. Isn't it just a character pointer or something like that,

like char star, sort of? Yeah, yeah. They don't think of them as objects. Exactly. This brings up, you said sets before, so if you've got a list of things and you want to get the list of unique things, well, you can just convert it to a set and then back to a list and there you go yeah i do that sometimes it's really nice that's your distinct yeah yeah the only thing left that

i wanted to mention was um using this was something that was difficult for me to get to get my head around was the zip function mostly because i was familiar with using zip on the command line to actually zip files. So no, zip is completely different. It kind of pair-wises up all a bunch of lists of things. And I use it all. I don't really, it's hard to explain when you use it, but when you do need it, it's really handy. Yeah, I feel like the inner tool stuff

just has so many things. It's always something new to me, you know? Yep. I don't know all this stuff. Those are the things I thought were good, and it was less than 20. The rest of the 20 wasn't that useful to me, but these were neat. Yeah, no, those are really cool. And a lot of times with these listicle type things are like this top 10, or like, I don't know.

Some of these are cool, or whatever. Like, these all look really great. Yeah, I like it. Yeah. Cool. so let's talk about waterfalls okay now we've talked a little bit about code complexity on different things i think we've covered wiley from anthony shaw which is a code complexity analysis tool so here's an article write up sent over by Arem Aref. The article is by somebody named Nikita Sobolev, and it's called Complexity Waterfalls. Pretty interesting. It kind of talks about the origins of complexity in our code and just the challenges of how that sneak in. And nobody starts out with the intention of writing like bad, hard to understand code. You may know you're going down

that path. He's like, I don't know what I'm doing here. But most of the time it's with good intentions that everything starts out. But at some point it becomes this mess, right? Yes. Some people are really good at it too. They do have a special skill. So this article highlights some of the types of complexity that you might find, how you might address them, some of the tools to actually automatically discover them. Two of the core ideas are things that I think will resonate with you, Brian, are continuous refactoring and architecture on demand from using things like tests and continuous integration and whatnot. So basically, instead of trying to dream up this perfect architecture, just write stuff in a simple way. And as it gets more complex, run some tools, discover the problems, use your unit tests to let you refactor and grow the architecture out of it.

What do you think of that? Yeah, I definitely like that a lot. And more and more, I'm warming to the idea of of using um complexity measurements as part of your commit tools to tell you where to refactor yeah so one of the things they use in here to talk about the complexity to measure it is this thing called we make dash python dash style guide which is actually a linter not just a guide like it's a thing you could run i believe it actually outputs stuff it's not just a guide and it does uh pretty interesting stuff so you can run it on your code and it'll say you know you're missing white space between your type definition and your type your

variable definition your type annotation or between a comma or you know there's a bunch of different things right and it brings in some of these complexity measures. You've heard of cyclomatic complexity. I know we've talked about that, right? Yes. We've definitely spoken about lines of code, right? The article talks about, hey, here's how individual lines of code become complex.

Here's how functions become complex or classes or modules or packages and so on and obvious measures or metrics would be if your function is 5 000 lines long it's wrong i don't know what it does i've never seen it but i can tell you already it's broken right yeah these sorts of things are pretty pretty obvious but one that i don't know that i've ever really paid attention to is something called the i think it's the jones jones metric yeah jones complexity no i've never heard of this yeah so here's the idea like if you had a line that was 80 lines long like says the example they give in the nakita gives an article is by print three long variable names

yeah first long name with meaning second long name with meaning the third one and that's 80 lines or if you say print three calculations right like you actually compute three or four things right multiply divide whatever multiple things in each of those print you're still printing three values but somehow they feel more complex. So with the Jones complexity, what it measures is it's like, if I were to take this line of code and parse it into an abstract syntax tree, how many nodes would there be?

Oh, wow. The first one, there's like four, like we have print, and then there's the three things we're printing. The other one is like 21 different things are participating in this one line. Yeah. Right? So the reason I bring that up is, for example, the WeMake thing, I believe, will tell you this has too high of a Jones complexity. Right? Yeah.

There's too much. It's a line. Yeah. It says, it'll say things like, we found a line with a high Jones complexity of 15. This is an error. What should you do? And, well, what should you do and well what should you you should break those out into different variables right you should take those expressions and turn them

into three variables and then print them like three variables one on each line and then print them so there's a lot of concrete little steps about how do you go through and see this complexity what do you do about it and like how do you kind of evolve your architecture through it? So, you know, I don't want to go through all the details in there, but it's a pretty interesting read and it comes up with some good ideas, including pointing out this WeMake Python style guide.

One of the things I want to highlight when we're talking about this is that a lot of times it is shifting complexity. So you'll have a very complex bit of something and that's a danger field. But to eliminate it, you're going to add complexity somewhere else.

Because like the example of a 5,000 line function, that's bad. But so is 5,000 two line functions that are 5,000 functions deep. Sure. Yeah, if you were to break it into 10 lines, you might end up with a module with 500 functions. That's also a bad thing.

Right. And so that's one of the things that I like about these tools is they, you can break things out the way you think it's better and then measure it again. And also please have tests in place to make sure that you're not breaking your code while you're refactoring. Yeah. So one of the things that Nikita talks about is this iterative, continuous refactoring

stuff. Like, okay, we fixed the Jones complexity of this, but now we've actually changed the complexity of, say, the module. How do we fix that, right? Like, keep doing it until it gets better, right? Yes. And I love this because the idea, maybe some people can just think of the right architecture that they're going to need at the end, but I never can.

So starting small and building up and refactoring where needed, that's the only way I know how to work. Well, usually the challenge is you don't have a perfect understanding of the problem you're solving until you're halfway through it. Right. Well, usually not until I'm completely through it. Yeah. Yeah, for sure. So even if you try to think like, well, maybe I should be more patient. I'm going to really think through this. Well, usually not until I'm completely through it. Yeah, for sure. So even if you try to think like, well, maybe I should be more patient.

I'm going to really think through this. Well, maybe, but the way you figure out what the solution should be is by going through that step. And then there's this iterative fixing process. Well, I never understand why some coders and developers think that they really can architect the right solution to begin with. It's like expecting a novelist

to not write a first draft, to just come up with the final draft at the end. It just doesn't work. Yeah, even if it can be done, it's probably not the most efficient way to do it, right? You just stare at the wall for a week. You're like, you know what? I wrote it badly in three hours.

I fixed it in one. I went to lunch, right? We're good. Exactly. For sure. Cool. Well, if you care about code complexity and this kind of stuff, this is a pretty good write-up and definitely some of the tools mentioned are interesting. There's usually advice at each

level. Like here's what you do to make a line less complex. Here's what you do to make a function less complex. I think the advice is generally good, but it can't be taken. Absolute. Absolutely. Right? Like it talks about, well, if I have a function, fewer arguments is better. If I have a class, fewer methods and fewer fields is better. But if you push that to its extreme, you say, well, all my classes have only one field and one public function. Like, well, okay, it's kind of, you know, now you have a thousand.

You can't push it to its logical extreme, right? It's kind of a give and a take, but it's, you know, it points in the right direction, I would say. Yep. I only have one argument to every function. It happens to be a variable length tuple, but. Exactly. Yeah. Well, that's called tuple complexity. Tuple complexity. Yeah. Is that in the list? No, it's not, but it is now. I'm adding it. Have we ever talked about GUIs on this podcast? We should totally cover that because Python needs to have more cool GUIs. I think so. So this one came up recently. I don't know how to

pronounce it. P-L-Y-N-T-H Plymouth? I'm going to go with Plymouth. I could be wrong. And I don't mean to make fun of you. Plymouth, I think what it's cool. What it is is cool. So it's a GUI framework for building cross platform desktop applications with

HTML CSS and Python hey we asked for this but it looks pretty cool it integrates with the standard C Python implementation and the Chromium's rendering engine and you can basically run you run Python runs

JavaScript and Python all together with Python. And it's kind of hard to explain without looking at it, but it's, it's sort of a thing that's just starting out. And it's not an open source thing. It's a group doing this. They're going to do it for money, but it's not expensive. It's free for individuals and including commercial use for individuals. And there's a bunch of tutorial videos now i'm watching some of the tutorial videos watch you kind of like one of them's like implementing a calculator and one of them's like implementing a spinning cubicle or cubicle

no spinning cube but a spinning cubicle that'd be cool somebody should do that now they clearly know what they're doing when they're writing this and and it might be that I'm just not a JavaScript person because the code they're writing doesn't seem obvious to me. But it isn't that much, so a handful of code, a handful of little bits of code and stuff, and you can implement something like a calculator on your web browser if you want. It's pretty interesting.

So, yeah, there's a visual calculator. I see that, and it looks like a desktop app. But obviously obviously we know it's it's basically the python equivalent of electron right like html and javascript and node yeah what kind of surprises me here is the at least the calculator example is integrated with view js which is kind of actually super cool so you define a Python class in the Dunder init. It sets up the view class. And if you've ever done view, that looks really familiar.

You would say, here's the element that is the root of the app. Here's some of the bound data. Here are some of the methods. And then you just point, you basically just set the function to the various Python functions. Like they clicked on a number, they clicked on an operator. I like it. This is actually pretty cool.

Yeah, I think it looks neat. And it sounds like what they're doing is they're having some way to automatically convert existing JavaScript libraries to Python modules. So you can call them from your Python or hook up to them or something. I mean, it's available. It looks like it has development kits available right now for Python 3.6 and 3.7. Anyway, for somebody wanting to play with

GUIs for Python, I think this is something to pay attention to. I wish them luck. I'm not a zealot for open source only. I make money on this by going to work so these people can too as well. And I'm over here looking at the pricing. Free for individuals for commercial use.

Academic, it's free. Company, enterprise. Developer license, $599 per developer per four years. Honestly, they should put another zero on that, and I think it would still be okay, because that's totally reasonable. It's not like they're saying it's $1,000 per year per developer, right? It's not much. So I'm happy to talk about it. It looks great

to me. Yeah, looks neat. For sure. Well, what do you got on the extras for us, Brian? Anything else you want to throw out there? Yeah, I want to bring up a couple things. I wanted to thank you for the excellent search feature that we have on Python Bytes. You're welcome. Because every week, believe it or not,

I got to come up with like three items to talk about. And sometimes we've already covered it. And that was the case this time. I ran across another reference to a tool called Cerberus, which is a JSON schema validation tool. Yeah, that's a cool one. Yeah, I love it. It comes from Nicola. He built that as part of the EVE framework. Okay. Well, that's a cool one. Yeah, I love it. It comes from Nicola. He built that as part of the EVE framework.

Okay, well, it's really pretty neat. And it has a lot of extensibility features that I haven't seen in other validation tools. But we covered it in episode 70. So, and I found that out through your search feature. Awesome. The other thing I wanted to bring up was this funny thing happened.

The other day, uh used data classes in uh some test files test modules because we've converted to python 3 7 at least i'm using we're slowly converting to python 3 8 but a colleague of mine looked at my code and said oh these data class things look cool how did you learn about them i'm like well kind of my job it's awesome i didn't say well you should listen to python bytes because it seems weird to encourage my co-workers to listen to it but send them my way i'll tell them to listen to him okay learn on my co-workers i can tell them how about you uh got anything extra for us just something super quick i ran across this article

it's not directly related to python so i didn't make a it's sort of main item but there's this project from google where they've been working on the upstream linux kernel using what they have called sanitizers and basically these are like c linter type things that go and find problems with the code so they had an address sanitizer for finding memory corruption and undefined behavior for certain code and other issues and then they've come up with this one called the kcsan i don't know the kernel concurrency sanitizer and they then turned it on the latest linux kernel and what they found is in a two-day period they found over 300 unique race conditions

and deadlocks and stuff within the mainline kernel of Linux. Wow. Anyway, there's some comments and stuff about this and links back to what they're doing. And it's kind of interesting. The code's on GitHub. Are they fixing them or just, you know, pointing out problems? Well, to point out a problem, like a concurrency problem like that is one thing. But to fix it, I think, is a whole entirely another without, without you know causing two more deadlocks somewhere else so i i don't know

okay maybe they're just making people nervous so making people nervous maybe this joke might a little bit probably not but after the one last week i don't know man we're pushing the boundaries so let me ask you a question when you talk about a link on the internet and it's HTTP this or that, you call it a URL or an URL? Well, I call it a URL. Yeah, some people call it URLs. What's the URL for that? Some people say URL.

Anyway, whatever. So there's this joke that comes from Aiden Berry. Brian, what's a web developer's favorite T? Well, it'd be Earl Gray or URL Gray. Of course it would. Of course it would. Awesome. I love that joke.

I laughed way too hard when I read that joke the first time. Yeah, me too. Me too. It's written. It's even better. So check out in the show notes. All right. Yeah.

Aiden, thank you for sending that in. That's great. Thank you. Yep. Thanks, Brian. Catch you later. See you. Bye.

Thank you for listening to Python Bytes. Follow the show on Twitter at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at pythonbytes.fm. If you have a news item you want featured, just visit pythonbytes.fm and send it our way. We're always on the lookout for sharing something cool. This is Brian Ocken, and on behalf of myself and Michael Kennedy,

thank you for listening and sharing this podcast with your friends and colleagues.