#331: Meet the Python Developer in Residence: Lukasz Langa Transcript

00:00 Python is a technology and community built upon the goodwill and volunteer time of thousands of contributors from the core devs Inside CPython to the authors of hundreds of thousands of external packages over on PyPI.

00:12 Until recently, the only full time folks have been at the PSF doing very important work, but that work has been largely outside of CPython, the technology itself.

00:22 In July 2021, the PSF created the Python Developer in Residence position. The first person in that role is Łukasz Langa, and he's here to tell you how it's going and how it will benefit Python at large. This is Talk Python to Me episode 331 recorded August 25, 2021.

00:53 Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes at 'talkpython.fm' and follow the show on Twitter via @talkpython.

01:08 We've started streaming most of our episodes live on YouTube, subscribe to our YouTube channel over at 'talkpython.fm/youtube' to get notified about upcoming shows and be part of that episode. This episode is brought to you by us over at Talk Python Training, and the transcripts are brought to you by 'Assembly AI'.

01:25 Lukasz welcome back to Talk Python to me.

01:29 Very happy to be here. This is the first time you can see me as well. I guess so. It's kind of getting a new thing for me.

01:35 So first time, first time you've been on the show three times before. You talked about the very first one was gradual typing production applications, and that was applying type hints at mypy over on Instagram, which was fantastic work. And I love what you're doing there. Then we talked about the Python Language Summit. You gave us a wrap up on that run down on that for 2018 and then diving into CPython 3.8 and beyond. So here we are again.

02:05 Thanks for being back.

02:06 Yeah. Happy to be here. Like, 3.8 is now already on old release, right. It's already in security only fixes mode. So it was new at the time. Yeah.

02:14 I think when we're talking about, like, what are the new, exciting features, I guess while we're on that topic, just real quickly, what are the new features that you're excited about now? Either 3.9, 3.10 or 3.11. What's out now? It's just about out. And what's coming soon?

02:29 There's quite many.

02:30 The one that I'm kind of living with the most right now is actually kind of just better error messages.

02:36 So this is kind of like a trend that is still kind of happening. Right. So there's further changes for 3.11 later, which is already, like the main branch right now of development. Right. So 3.10 is ready. Release candidate mode. So we're gonna get the second release candidate pretty soon, and then the final ready. So all new features now go to 3.11 already, but the better error message is like, really, they're kind of this icing on the cake that make stuff much nicer for you. There's a bunch of typing changes that I was really looking forward to back in Pep 48 four times. Like when we first added string.

03:13 Well, annotations to Python, I always kind of wanted them to feel more native inside your code. And now with Python 3.10, you can use, I guess it's Pep 604, like, Union types that are not so verbose. They use the pipe operator instead of spelling out capital case Union of whatever, which is kind of more compact and also more readable through this. Right. Because now types that aren't super trivial don't look as scary anymore because you don't have to have the square brackets so much.

03:51 And whatnot for people who haven't explored deeply there previously was basically a parallel, a mirrored hierarchy of types that weren't actually the types, but they describe the type from typing import capital L list. That would say you returning a lower case 'l' list as your type. And then it got even more interesting when you have, like, optional. Right. I have an optional user that's returned from this query. Now you can just do things like user pipe none and things like that.

04:22 Yeah, absolutely. So this was fun. But also what they really kind of like to use is that the lower case types just feel more natural. So kind of just putting dicts and lists and whatever just straight out of built ins and just applying generics to them just kind of looks right. Feels right.

04:39 So it always felt weird. Like, why do I have to do an import just to talk about this thing I'm already using? Right.

04:44 Yeah. Because if you actually look at how the feature was enabled to allow lowercase list of string and whatnot this is now part of the interpreter, this was kind of changed deeply in the C Code of the interpreter back in 2014 when we first released a PEP 484 the value of typing. Wasn't it really so clear cut yet? It was a new idea. We wanted to have this out, see on to have people actually test it and say, you know, is this something that Python could actually value in? So it was a little too early to make drastic changes to the interpreter just because it would be handy to have for typing.

05:25 Like, it's kind of a key in the sense that between here and there, we clearly have this transition period where typing just becomes more natural to use and more ergonomic. And obviously the tooling, like mypy matures, but it's what you have to do if you're dealing with a language that is 30 years old. Right. So we didn't have this cleaner room experience because the language was already successful. It was already out there.

05:52 So, yeah, like, a bunch of new languages now have this comfort have this luxury of just being able to just a look at an empty page and just design from scratch. We have to evolve what we have for sure.

06:05 Python is 30 years old, right? Language that comes to mind when you say that is Swift. Right. So I took a bunch of these ideas, like, you have to explicitly say, here's a nullable reference type and whatnot. But, like, all of that stuff was done looking back at Python and C#, at C++, at all these languages that and then sort of put together the pieces. Right?

06:28 Yeah, absolutely. Like Swift in particular. I kind of like, you know, and if it fits my brain, I talk with Core Benefield every now and again about it. Like he's now working on it, actually at Apple. So, yeah, I do feel it's a good evolution of Objective C since it's where it all kind of started from.

06:47 It's definitely an improvement. I don't want to go too far down the rattle, but I wish it had something like a better standard library, like Python has. I feel like the language is good. But then when I want to do stuff, I'm like, there's so much missing from, like, the foundation of it in terms of functionality. Anyway, long story short, because it still depends on the whole Objective C sort of, like, really funky class library stuff. Yeah, I'm sure I'll get mailabout that.

07:12 All right. So sorry I super derailed you. What else is exciting that's coming in the near term?

07:18 Of course, the biggest kind of feature that was most controversial probably is the match statement.

07:24 So pattern matching in Python, it is a huge feature. It kind of changes how, you know, some of the code that you're dealing with looks. And also it kind of introduces for first time this concept of context specific keywords.

07:39 Right.

07:40 That's something that maybe not so many. What's new in three Python, a Python 310 posts kind of touch on, but just notice that you can still use match in case as regular variable names. You can still name or functions that you can still use this as argument names and whatnot and whatnot. But when the Python grammar discovers, when the parser sees at all, this is in a place where it fits a construct that looks like a match statement. I'll deal with that and all parse that successfully. That is what we could do, having this new peg parser that it started in Python 3.9. It was released then already, but without any new features, like in now in Python 3.10, we're getting the match statement.

08:24 I'm still kind of, to be honest with you before this area where I can take tell you that I have a lot of experience writing match statements. It's super useful for me. And whatnot? Like, I've written a few of them where it actually made sense and made the code. Well, I couldn't really say shorter, because usually it actually doesn't, but much more readable because it's kind of flatter. It's easier to parse, like, visually, I mean, a person, but it's not something that I really use daily. So whenever somebody is really worried about. Hey, what is Python becoming? It's such a complex feature.

09:01 What about the kids? Think of the children. I always tell them like, hey, how many descriptors did you implement in your last week or month or year? Like, probably true.

09:11 And how many meta classes? Exactly how many meta classes have you worked with? That's a good point.

09:16 It's almost like another feature like this, where sometimes it'll make perfect sense, but most often just, like with assignment expressions, most often you won't see them. You won't be using those.

09:28 Yeah.

09:28 Okay. Well, fantastic. You know, you're talking about the foundational stuff, like the Peg parser.

09:36 That's not a feature that a bunch of people are saying. I can't wait for a better parser. Right. But it's one of these enabling things, and I feel like this whole role that you're is sort of in that same idea, right. The same vein, that it might not be super public or generating a bunch of new features, but it might be making things a lot smoother for everyone who wants to come along and do those things. What do you think?

10:05 The way I look at it is that there's a lot of us on the core team and even more people around the core team who are kind of. Well, we call them drive by contributors. Right. Like they would find an issue, just produce a bunch of pull requests, and maybe then kind of disappear. Or maybe they're around, but not producing more for us. And we are obviously very happy with any contribution.

10:27 And the sad reality is that we have more of those then we can realistically review. So the problem isn't even that you need more people to actually be able to actually produce value. We need people to evaluate the value that we're already getting from the community and from each other, to be able to actually merge them into mainline and to see how the language evolves. Obviously, every year this changes over the years how Python is developed. Like, we're going to have a bunch of people who are super invested, and they're going to be spending crazy amounts of time, including on weekends and whatnot to work on Python, even for free. I know I did that for a decade, so those contributions are super valued, but usually those people change. You cannot really do this in a consistent manner, day in, day out, for a long period of time. Your life situation changes, your job changes or whatnot, and you stop contributing and what happens to Python?

11:32 Well, we lose some value.

11:34 Currently, we have over 1400 open pull requests, and I've been on a mission to kind of bring that number down. Currently, as I'm looking at it, it's on 1421 I was looking at this morning here.

11:45 I put it up on the screen for people watching live. And.

11:48 Wow. Wow.

11:50 That's a lot of information coming in. And not just the sheer number of open ones. But the thing that struck me is I'm reading down in 26 minutes ago an hour ago, 2 hours ago, 3 hours ago, 3 hours ago, 4 hours ago five. That's hard to keep up no matter what. Right?

12:07 Yeah. Some of those are already reviewed. The faster implementation of 'gzip decompress' that you have somewhere in the screen a little lower than the first ones, like this on lowest one at the moment.

12:20 So the thing is, there's so many of those that kind of somebody actually has to come in and day in, day out bots and seats. Just review the value that we've already providing for you. This particular change, actually extracted from an older, rejected change, is actually providing clear value. Right now, we're gonna have 'gzip' compress and decompress be faster. Right. But it is actually not changed. That is obvious. Right. You have eight files that are changed. You really need to see that. Oh, there's a lot of code that changed. Some of it actually wasn't. It was just moved so that we could reuse it better. Some of it actually has subtle changes. So this isn't something that many volunteers will be willing to do on their free time, because it's mostly kind of. Well, it's work.

13:07 It's the janitorial type of. Just keep it clean, keep it going.

13:13 Yeah, exactly.

13:15 So let's go ahead and actually introduce this main topic here at the big announcement for you on your blog. Here you have. I am the new CPython developer in Residence. Congratulations.

13:26 Thank you. I'm still very excited about this back when we only had volunteers doing this. And maybe will Guido being kind of tolerated as the bdfl at dropbox, because obviously he was being paid to actually move mypyforward. Right. That was good team, but obviously he did a lot for Python as well. And that was kind of understood by Dropbox. That is fine. And many of us were in the same situation, like, I was tolerated as a CPython core developer at Facebook, and some others were at their own respective companies. So I was super frustrated by this because there's tremendous value that we're giving to the entire community, including multibillion dollar corporations. And we only thought like, hey, the expectations are high, and we want to provide the best tooling that we can for the industry.

14:16 But it is kind of a hard sell when your kid wants to go out and you're like, oh, now I'm fixing this bug, but at the same time, you're doing this for free. So you're thinking and all, like, where do they go wrong in life?

14:29 My values are somewhere not where they're supposed to be. So RedHat actually hired Victor stinner, like, full time to work on Python, but it was still RedHat. He's still an employee of a company that is for profit.

14:41 So now the CPython developer and residence is different. Right. It is sponsored by a PSF sponsor in this particular case, by Google in Google, as a company reached out to the PSF specifically to sponsor stuff like this. And that is amazing. I am very happy that they did, because I really believe that this is something that might kind of alter how we think about maintenance of community driven projects like Python.

15:07 Yeah. And thank you to Google for doing this. It's so easy for them to say. Well, maybe we could just hire some core developers and they could work on speeding up the Google cloud stuff for Python, and we'll let them also contribute back. Right. That would be the sort of natural, historical way of doing something like that.

15:24 Yes.

15:24 But here it's like, no, let's actually directly sort of effectively hire a person, but put them in an independent role. That just makes Python better. That's interesting. Right.

15:37 Yeah. The amazing thing about this is that while I do hope that some of the work that I already did was useful for Google as well, there is no job description written by them, and there are no tasks that they're directly giving me. Right. It's really independent in this sense. And this is what makes it super healthy. And I think, well, sustainable for for the future, that it is actually me being able to talk to the steering Council, which I do regularly and to the PSF about, like, hey, what do we actually need? And we don't have to take into consideration kind of direct value for our sponsors. We are providing indirect value, but we don't have a road map where there are certain milestones that we need to reach. It's not like that. So I'm very happy about this difference, because we did have sponsors before that did have either projects that they really wanted to move forward, and we still have those. So, for example, packaging and whatnot or events that happen. Right. So Facebook sponsored core development in Sprints. So we had those at the campus two years in a row, and then Microsoft took over and we had Bloomberg, and then we had covered.

16:49 So those things do happen. And I'm very happy for those.

16:54 But this is a kind of a game changer. We have not done this way of sponsor on a project before where we're actually thinking about the software word in Python Software Foundation, where we directly sponsor work on the code on the source code.

17:09 Yeah. The PSF has seven, eight, nine fulltime employees, but you're the first employee who is in a software developer role. I think the closest we had before was project management role for the new 'pip'. Is that right?

17:24 Yeah. So we have that there's also E who works on our infrastructure. So what is also important for Python, and this is dealt with by the PSF is to keep the website running and to keep PyPI running. Right. And so on. So obviously, all of this requires constant supervision. It's also something that you can spend your life working full time on. And this is what he is doing. However, that wasn't contributing to CPython the repository directly. And this is the entire change.

17:56 Yeah, that's fantastic. Quick shout out to just the two other visionary sponsors. We got Bloomberg and Microsoft through Azure. So I think that's awesome. I think this whole visionary sponsor, Google, was the first one in that category. Right?

18:09 Yes. That is a change in how the PSF was looking at sponsorship before. I'm very happy to see that this entire developer in Residence position was something that I was pretty stressed by when I first got to know that, oh, this is actually going to be happening because I do believe that my particular performance kind of will make or break future ideas on whether this should be extended to more people. Right. Or just close down altogether. So it's not only providing value to the project, it's literally providing kind of proof that this development model works. So, yeah, there's certain responsibility around it. I think I already caught a rhythm that I can sustain, and I think kind of split my own coding with actually reviewing and accepting other contributions, which are the bulk of what I'm doing, because otherwise, if I just focused on coding all week, I might maybe if I'm lucky and other people review my work, make maybe five, maybe six changes to CPython. Like, we're doing careful reviews, because even simple changes might have actual, far reaching consequences. But when I'm reviewing other changes, we sometimes have, like 50 or over 50 changes that I can actually merge into mainline. So I'm very happy about that. That is obviously a much better deal for everybody. Yeah.

19:32 It's one of these enabling roles, not just sort of heads down coding roles, which I think is the important thing. Absolutely. Yeah. Paul Evert out there in the livestream says you mentioned the stress from the responsibility.

19:43 Agreed.

19:43 Takes some bravery to do it. kudos.

19:45 Thank you. At the same time, I was literally giving talks before about, yeah, we should do this. So I kind of put myself out there even before this was a position. So at least applying, because obviously it wasn't at all obvious to anybody who is going to be chosen for this. This applying was sort of in the cards. I had to man up and do it.

20:09 Yeah, that's cool.

20:10 Let's sort of explore. bit your background, it's not just that you were a user of Python. I don't know. Even a really good Python developer themselves might not be a good fit for this role because it really is like closely working with people contributing to the code base and the core developers and all that you know, maybe give people a sense of some of the things that you did previously to this in the CPython space, for example, you create black. I think maybe people have heard of 'Black'.

20:39 Yeah. If anything, this was actually probably on something that made it harder for me to get this position, because obviously everybody is scared. Like, hey are getting the reformat all of this in library now. Like, you know, oh.

20:49 You're bringing the black guy. He's gonna totally format it different.

20:54 Yeah.

20:54 The biggest PR ever.

20:56 Like, joking aside, I'm not new in the project, and that was obviously important. It's kind of hard for me to kind of enumerate the reason why I was chosen. I can only tell you what I told the PSF when I applied, because that was actually the only time in my life where I actually had to write a proper cover letter and actually do some soul searching and say, like, hey, am I actually a good fit for this?

21:22 And I see my mission statement exactly.

21:25 Like, yeah, pretty much, you know, and I've been around for a while. I've done some changes big and small. There's a bunch of peps with my name on them. So I guess you kind of it's not just tiny typo fixes and introducing new bugs. It's also introducing PEPs. Some of them might be more clear cut wins than others. Yeah.

21:45 You appear in a lot of the peps. You were the release manager as well, right?

21:49 Yes, I still am. 43939 is now currently already pretty late in the game in the sense that we will be releasing Python 397 just next Monday. So probably not when the listeners of the podcasts that are going to.

22:05 Well, they're probably gonna see this already released, but not from now for the ones, like watching the live stream. Yeah. Next Monday is when we're gonna release 397. So that's already the 7th bug fixed release of Python 3.9. There's gonna be a bunch of more of those, and then it's going to graduate or retire into the mode where only security fixes are considered for inclusion. This is where Python 3.8 is already. I've been managing the releases of that.

22:33 How long do you remain the release manager until 3.9 is retired, or does it get handed off at some point?

22:40 No. No. So you become a release manager for the entirety of a lifecycle of two releases. This was true for a long time. I didn't dig up in prehistory, but since the Python 3 releases I looked at, that was the case.

23:00 Python 2.7, I think, was Benjamin and two six. I'm not sure that would it was him. Like, it was probably Barry Warsaw. But the thing is, like, 2.7 was the longest release managing job ever.

23:14 And if you could just burn yourself out on that one release, so that's fine for us. Currently we're managing two releases. So how long is that? Well, with the development of given Python version where 3.11 is already being developed right now, it takes around a year and a half for it to actually get out there as the final release. We do have a cadence where we release new versions every year, but that's only because once one release becomes beta, we can already switch the branches. And now new features go to a yet new version. So can I say it's a little weird?

23:51 I think that happened on your watch that happened on your watch was 18 months before.

23:56 Yeah. So 18 months of a cadence was never really a hard calendar event. Like, it was more like a guideline. We're like, yeah, we're going for 18 months sometimes it was 19, sometimes with 1020, but it was problematic for many reasons. So, yes, one of the PEPs that I offered was a Pep saying, hey, we should change the cadence of development to make it on annual release cadence, which helps with downstream distributors like Linux distributions, and for many other reasons.

24:27 For us, like that's in the Pep.

24:29 But, yeah, to just close on your original question, it takes around eight years from starting the job to actually saying, oh, now I'm a retired release manager, so it's a longterm contribution.

24:41 That's a big commitment, isn't it?

24:42 Yeah, it is.

24:43 Wow. That's amazing. Well, thank you for that. That's wild.

24:47 So when you touched on this a little bit, but on your original blog post announcing it, which I'll link to in the Share notes, of course, you talked about what can one person do is the developer and residents, and you called out a bunch of specific things here about how you can basically be a multiplier effect for people who want to contribute, who are not core developers. You want to maybe to give us a rundown on those things? Sure.

25:13 So the blog post, I'm still happy with it because it kind of shows that it wasn't just winging it. I actually thought it through. But if it lists a bunch of things that are ideas and then you actually start doing the job, and some things become clear.

25:26 So all of the things I wrote are true. But for example, they didn't quite word out in the blog post that I realized this important is that very many changes that I took, are kind of 90% there where I cannot just merge them as is. But really, what I need changing is the doctrine is just bad or the comment is misleading or whatever, like a bunch of simple things that kind of it feels just wrong to just will review the change and say, hey, like I request you do this small knit because I cannot merge it as it.

26:04 Yeah, you gotta do the line break because this code is 90 lines, 90 characters long. You could just break that line and then commit it, right?

26:11 Yeah. So this is what I do actually very often right now. I just kind of take the change locally, run the tests that are important for this particular case.

26:21 I do the change that I would ask for just myself without actually looping in the original author. Most people actually leave that tick on their GitHub requests, making my job easier. So, yeah, thanks for that. And then maybe they forgotten.

26:37 I just did a PR last night and I allow maintainer to edit the PR.

26:41 Yes.

26:41 Yes.

26:41 This is something I'm using very often right now, because if you forgot to, for example, put a news entry for this and you've never done this before.

26:50 Yes. There's a bot for this that Mariata wrote. So you just need to go and read how to do this, and you will be able to do this from now on. But when will you do that? Maybe tomorrow, maybe in a week. Or maybe I'll just going to leave the pull request to go stale. So instead I just go and do this for you. This kind of level of multiplication, really, I think, is kind of closing the gap because very many changes, and sometimes it's just sad to look at you have a change from 2017 that is clearly great, clearly valuable.

27:24 And then there was some knit that prevented it from being merged, and now it's 2021, and it no longer merges because there's conflicts with other unrelated things.

27:34 It's so out of date, it's no longer just a init. It's now like a big it's a rethink.

27:39 Now. It's hard to merge. And obviously not just that. Maybe that original person who created the change and worked hard on it now is discouraged or moved on to other projects because, you know, it wasn't merged for four years. So this is what we want to change, right? We want to make the not just the first time contributor, but any contributor. Well, life or experience, like much better, at least providing feedback. Not all feedback will be positive.

28:05 This is already a mature project then sometimes very good and easy ideas actually aren't. If you look close enough.

28:14 This is the frustrating part where even kind of clear cut advantages might be disadvantages for a different group of users or on a different platform that you're not a user of. But we have to actually look at the big picture, but at least you're going to know from somebody like me that, hey, like, this is good, but we cannot take it because of X Y.

28:35 It's super frustrating or disappointing to put work into doing a PR, submitting the PR, and then it's not that it was rejected. It gets no response. And that's I think really frustrating. Like I spent a whole day because I was thinking this would make this thing almost works for me, make it perfect for me. And here's the thing. And the answer could be no, it's not the right direction, but no answer at all. It's just like, I'm not sure I want to do this again. Yeah.

29:02 Related to that sort of Rodrigo out live stream has a pretty good question, I think. Let me throw that out to you. And what are some of the advice to potential future drive by contributors? How could they make your life easier?

29:13 Well, in the future, we'll move to GitHub issues, so a bunch of this will become easier for the contributors themselves. But currently that we still have bugs Python.org, there is a required step pretty much for anything that isn't a trivial typo, which is you need to have a bugspython.org account where we know that you signed the CLA.

29:36 So the Contributor License Agreement saying I release my code under Apache, for example, so that we can actually use it and merge it, and it's fine. So this is something that is the important original step. And once you're already on 'bugspython.org' and your change is not trivial, please click that Open New issue button and write what you're doing and why. Maybe it's already there. Maybe you already know that you're fixing a particular thing that was already reported by somebody else. But if not, like, spend this five to ten minutes describing what is happening and why you want the change applied. Very many changes simply do the thing that they want to do.

30:17 Many of them don't even write in the Pull request name. Like what they're doing. It's simply the original GitHub update file, which really is a puzzle now for anybody else because we don't really know why this thing was touched in the first place. So essentially just describe, like, where you're coming from. Like, what is this change doing? That is already great. That already. And give context to us.

30:42 Would you suggest that people create an issue and get a little bit of buy in from you all before actually doing the change? And the PR?

30:51 Like, would it make sense to see considering this, I'm happy to do a PR. Here's the plan. Would you accept this if I did it?

30:58 Depends, right.

31:00 Because that is the worst centrist bleak answer that anybody can give. Depends, right. When you're doing bug fixes, you should just go ahead and do your best and make the bug fix.

31:12 Here's the failing test. Here's the fix.

31:14 Yeah, but if you are saying, hey, this library should have this new function that I am using in my own project, so I just want to put it in, say, func tools or whatever. So before actually going ahead and creating a Pull request, it probably might sense to discuss it with us because a growing standing library well, isn't so clear cut a value as you think, because maintenance burden.

31:39 Yeah, absolutely.

31:39 And more importantly, now it has to consider all the usage groups that the original author might not care about, but we have to. We necessarily have to. So, yeah, for features, definitely file an issue, describe your problem. You might actually, if that makes it easier for everybody to discuss, just submit a pull request saying, hey, this is the feature if you want to talk about it. So we actually talk about something concrete instead of an idea.

32:05 But if you, for example, say that hey, we need to rewrite multiprocessing, so it does this other thing instead of creating a multifile, gigantic pull request like, let's discuss first.

32:16 Talk Python to Me is partially supported by our training courses at Talk Python. We run a bunch of web apps and web APIs. These power the training courses as well as the mobile apps on iOS and Android. If I had to build these from scratch again today, there's no doubt which framework I would use it's FastAPI to me, FastAPI is the embodiment of Modern Python and Modern APIs. You have beautiful usage of type annotations. You have model binding and validation with Pydantic and you have first class async and await support. If you're building or rebuilding a web app, you owe it to yourself to check out our course. Modern APIs with FastAPI over at Talk Python training, it'll take you from curious to production with FastAPI. To learn more and get started today, just visit 'talkpython.fm/fastapi' or email us at 'sales@talkpython.fm'.

33:06 Another question out there I think is good from Paul, is your PR review velocity?

33:13 Do you expect it to go up as you get better and maybe automate or go down as you hit the harder PR's?

33:18 Hard to say.

33:18 It's like clear now your inbox a little bit. Some of them are using like, oh, that's the whole day. Oh, no.

33:23 Essentially, it is not very easy to kind of foresee what's gonna happen a given week. But one thing for now has been constant. I need to get the number of pull requests down below the number that we have right now because there's gonna be some that are on page, like 35 of the open pull request page, so I will probably never get to them otherwise. So I need to bring the number down.

33:49 And so far, just by myself, I was unable to do it. I cannot do it. I had one week where I really said like, hey, just a 40 hours work week be damned. I need to see if I can really bring this number down.

34:05 And I almost merged 100. So that was not something I can do every week.

34:11 And I still didn't meet the goal because I did leave the account below 1400 when I went to sleep and I woke up the next day and it was already over, you know?

34:23 Yeah, we saw the rate of incoming ones. That's a lot.

34:26 Yes. So I'm doing around 50 ish a week right now, and it sounds super high, but some of them are backboards to branches that we maintain. I list those because some of those backboards aren't Riggle, right? They will conflict because the files changed in between, or they require some push from a person because the bot didn't do what it's supposed to do. So it's also work.

34:51 But 50 isn't really kind of kind flexing a lot high. I can do so many changes. It's really the rate of change that you can see. So there are enough new changes, right. But I guess I can always forever just stay on page one and just deal with those. But that would feel unfair, right?

35:10 That is some reversal of priorities. Where the last that comes in?

35:15 Yeah, you must need to be the last page and work your way.

35:17 Exactly. So sometimes I would look at the older ones, basically just asking interesting query to the pull request search on GitHub and see what's there, for example, this file or what's already approved, and that I can kind of maybe push over the line and so on. So there's gonna be some balance there. I don't expect to go any faster than I currently am, because I kind of re automate much there.

35:45 There might be some instances where if we analyze the Pull request better, we find that out. There's an entire genre of request that we can just bulk close, but I can't really, you know, put this on the report. It's like I closed 1500 pull requests. I'm so great. Now, the ones that I put on the Weekly Report are all that I like with my own eyes. Look at and review. So I don't see how automation can really help me do that faster. We need to be careful. It's still a language used for some important stuff in our industry and beyond, so kind of a higher rate of change. Sounds nice, but it also is risky, right? If you don't do it responsibly. So I think that the 50 is number that I'm currently at, like is enough that I don't feel like I could be doing more. It's around what I can reasonably with a clear mind, like review day in, day out. And I still have some time to actually code, which is also fun because now you're contributing something of your own. But, yeah, I don't think I can get to 100 every week. Like, regardless of the automation I can come up with, yeah.

36:57 And maybe they get harder.

36:59 Yeah, they might, because you could.

37:00 All right. This is when I can quickly close this. I can quickly close this. But as you sort of cycle iterate over that list, like, you get stuck more with the hard ones. So you mentioned the Weekly Report, you're doing a weekly report that's just out in public. So, for example, I'll link in the show notes to your weekly report for July 26 to August 1. Or is this, like, your second or third week something like, yeah, so, if people want to keep up with what you're doing, it's right out there, isn't it?

37:27 It would be out there anyway.

37:29 Right.

37:29 Because even if you don't look at the reports of them writing, you can still go to my profile on GitHub and just see what the streams is there. And if it doesn't say anything like that's kind of working, I was like, hey, is this guy even working?

37:41 What is he doing to check your Instagram, see if you're on the beach? It's just hanging.

37:46 Exactly. And I was actually just last week, so the week 20 reports are kind of thought of buy me personally.

37:53 Like, the PSF wants me to blog about what I'm doing, but not at this cadence, but I personally just want to kind of tell you what I'm working on, because ultimately, what I'm doing is work on an open source project for the community, like Lily hired by the Python Social Foundation.

38:12 So there is no agenda that is personal to me or driven by some Corporation. I'm literally maintaining this for you. So why not just let you in on what I've spent my time on?

38:24 Most of those, I expect are gonna be pretty boring after a while, because a big part of it at the bottom is always just a list of PR, so we can actually click through and see what did I do there? But I always try to keep it interesting by the and finding some highlights that I found particularly interesting or given a week.

38:42 Yeah. I think this is really valuable to help people a lot to sort of see what the role is doing.

38:49 So originally, this role was based on Django's fellowship program. Right? Yes.

38:54 Yeah.

38:54 That's really cool. So you're able to Django had this idea of bringing on people to help deal with the lower level, the more maintenance oriented stuff. Right. Like, exactly what we've been talking about. And I know one of the things you talked about somewhere in one of your articles I can't remember, which was basically you're very excited about this role, but you're also a little nervous because you want to make sure that you're the first one doing it, and you want to make sure that it is going strong for the next year and the year after. And whoever comes along, this is a good thing, and you want to keep going. Right. So that's a little bit.

39:28 Yeah.

39:28 You're kind of like in the ground there, right?

39:30 Yes.

39:31 So this is important for many reasons, obviously. Right. Because we can go ahead and talk about how this can transform Python if there's enough people doing this full time and whatnot. And this is all true. But there are also kind of more, like down to earth reasons why I would like more people to be able to experience work as I am right now, because it's just a wonderful way to work. Not only am I working on something that was my hobby for, like, a decade now, so I can just day in, day out, just kind of I feel like I'm just kind of just doing the hobby right now. So it's amazing.

40:06 But also and this is something that I kudos to Google.

40:11 The sponsorship level for this is Bay Area level of salary for a software developer. So it doesn't really matter that I am here in Poland where very many companies would apply some location specific salaries to a position. Now this is Literally kind of like, well, I don't want to say premium grade, but like, industry strong salary here.

40:36 It's not like you had to go and say, I'm really going to take a hit, but I really want to do this. So let's just do it right.

40:42 So it's a proper job at all, not at all. Which is exactly why I think it's both important to the project, but also important to all those people who are already contributing. They're already providing value.

40:54 And now if they got paid, like, actual industry strong rates for their work, like, this has the all kind of opportunity, or this has this enough value that it can change a person's life. Right. Like, some of our contributors are not in the US or in countries that already, I don't know, Eastern Europe or East Asia or wherever else.

41:18 And there, like, this kind of amount of money I might actually actually make or break somebody's well, entire livelihood. So it's amazing that this opportunity exist.

41:28 It exists at the same time. For now, let's not get ahead of ourselves. This is a contract for one person for twelve months. It might not get renewed. We might not get sponsorship for next year.

41:42 So the PSF might actually have to be on the lookout for more sponsors later, or maybe for a new developer, if they just don't feel like the current one is doing the job well enough. So all those things might still be in motion. So I myself don't really. I already put this in the bag. They're like, hey, I'll be doing this now for however long. No. Now I'm really spending this first year of really producing the most a reasonably can, because it might just be a twelve month gig that I will be having fond memories of in a decade, or maybe a start of something much bigger. So why not take the chance and try your best?

42:24 Yeah, absolutely.

42:26 So let's dream just a little bit, and then maybe I'll put a call out to it. Would it make sense? Would you want could you do more with, like, a team of people? If there were five developers in residents, so would the PR look like 20 open ones, the oldest one a month open things like that? Would that be good?

42:43 Would you want to see that having five people available for work like this would entirely change how I'm approaching this? Because currently I don't really have much in terms of coordination with others. I just look at whatever current work is happening and try to help out there. But if you had five people, you could actually hit this problem head on.

43:06 We have 1400 open pull requests.

43:09 It's not a question now if we get them down to zero, but when? Now we actually can plan to do this methodically and a lot of bigger style things that we always wanted to have in Python. We could now just plan to implement ourselves.

43:25 Now, if I'm just the only person doing this, it feels irresponsible to just hide somewhere in a basement in Pole and then start turning out my favorite feature. That's not what this world is about. But if you have five people, you can reasonably expect that some of them might actually work full time providing new features or finishing unfinished ones, which there are plenty of for inclusion in a future version of Python.

43:49 Maybe somebody says, I'm the one who just goes to all the bug PRS and just check those. And there could be somebody working on performance.

43:57 You could specialize in things like that, even.

43:59 Well, it specialized, but I really kind of think that if all of them are developers in residents, it would be great if they kind of had this on call rotation for doing things as I'm doing now. So just responding to the external community, right. Because the important thing that I wrote in the original post and I still believe in is the drive by contributor experience is extremely important. So we would always have to have somebody doing this. But at the same time, nobody really wants to do only that. Everybody has to provide well, once to provide value of their own so that they can touch it and said, yeah, I did this. This is good. Yeah. So, yeah, I already have a bit of this, like, not as clear cut, not sponsored by the Psf directly, but Pablo, the release manager of Python 310 and 311 is both sponsored by Bloomberg to work half time on Python performance and also by him doing the release managing job for Python 310 and 311. He coordinates with me very often right now, especially that now we are in the release candidate stage of Python 3.10.0. And the greatest thing about this is that he's in London. Right. So, yeah, maybe far if I were to walk to him. But in terms of time zones, that's amazing. Like he's just 1 hour away. So we mostly have very synchronized workdays.

45:19 So I would talk to him essentially every day.

45:22 And that is also something that I missed doing remote work before, because if you are working for a company that is in the Bay Area and you're the only one in your time zone, it kind of gets lonely having more people around that. Now I have like, Pablo, I have Victor, Sergi his or strochaka, and most of our communication is async. Right. So it's not like everybody's talking when I'm not around, everything is happening on the mailing list anyway.

45:51 So it feels like I'm much more more integrated into the team compared to my previous stint at doing Ringwood work. So I enjoy this a lot.

46:01 So it sounds like it would make a big effect. That's fantastic. We look at that list of the sponsors, the visionary sponsors, and there's three companies doing really good stuff. But you gave a implicit sort of call out to this, and I said it plenty of times. There are many companies out there. Their entire core of their business is built upon Python, and they make billions of dollars.

46:23 Shouldn't they consider contributing something to build that foundation a little bit stronger? Right. Like, maybe make it their developers go a little more efficient or whatever?

46:34 Yes. So the good thing about this is that we always can use more money. So obviously we need more sponsors. Many of the companies are trying simply the thing that they need is some sort of, like, plan or not, like a legal contract, but at least some sort of understanding what the money is going to go. Right.

46:54 When will they get out of it? Right.

46:55 Because yes, exactly.

46:56 Their balance sheets, they have expenses and they have revenue. They don't usually have charity. Right. It's tricky for that for them to make it better.

47:07 I think it's kind of. Now with the developer in residence position, this kind of changes the game because you're no longer just sponsoring the Python Social Foundation and kind of you might have expectations, but maybe that will go for PyCon, maybe they'll go for sponsoring of events or minority groups or whatever else. Like, if your company really is interested in providing support to the core development now, you can. And I think, like, well, hopefully that is my hope. We're going to see more sponsors of that kind of.

47:38 Yeah. Absolutely. People who are actually interested in go to 'Python.org/sponsor/application', and it shows you what the tiers are, what they cost, what you get, you get a lot of inside access and a lot of visibility into Python at the visionary level that otherwise you wouldn't get. So there's something to be said for that. People should check that out. Right. You got to meet with the PSF board, a lot of cool stuff. There workshops, job fairs. I think there's a lot of things on here that could go down as this is a legit value. You get to meet with the Python Steering Council recognition and so on. So I just want to encourage companies out there. We don't need tons of them. If we had four others.

48:17 Right.

48:18 You said that would make a huge difference. Right.

48:20 Absolutely. And also kind of like, let's be clear, like, kind of a sponsor of a developer in the residence job.

48:28 I came in with a laundry list of, like, this is the things that I want you to do.

48:33 We'd probably have to kind of come to an understanding that this is not what this is about.

48:38 But if people who happen to be employees of a company come in with changes that make sense and actually provide value for us, and now we have people to do fulltime code review and inclusion of those changes, it's more likely that things that you care about are going to be included. So you can be ethical and impartial to kind of, well, forces of money flowing into your account and also provide value to the sponsor. It's not a zero sum game. You let that be clear and explicitly said, because I feel like this is also important to know that if, for example, there is a company that really, really focuses on an operating system, like, I don't know, maybe they're running everything on Windows or macOS, and now they're like, hey, we really need somebody to make async i/o work better on Windows, or we need to fix this fork problem MacOS once and for all. Or whatnot? Like, if they provide some changes and now there's people to do the review. More likely than not, we're going to have better support for Windows and macOS. Like, everybody wins.

49:45 Yeah, absolutely. Another benefit I'll throw out there just thinking about this is a lot of companies have continuing education programs and credits like, hey, you have a bachelor's degree. You want a master's degree. If you're willing to go to school outside of work, we'll provide that for you. And the reason is now you have people who work for you that have master's degrees and not Bachelor degrees. Right.

50:07 So this could be a similar thing. Like, hey, we want to provide a position for people to come work as the Dir or part of the Dir, and then maybe they come back and work for us afterwards. But they would be so much more knowledgeable about Python. Having spent a year in this role, there's a lot of benefits like this.

50:24 You know, you won't believe this, but obviously the project is a million lines of code. Half of it is C, half of it is in Python.

50:32 So I don't know about most of it. I've seen much of it, but I probably don't have expertise in most of it, but nobody cares when they submit pull requests. So then I look at them. So for many of them, it's my first actual stint touching a part of Python that I might know a user what we're going to be at.

50:54 Right. Yeah. But then looking at how does Dunder main actually work in Python? Is this special module that your execution starts with.

51:04 How does this actually work? So you go and see and actually kind of dig and you understand, like, okay, I understand this because you have to take into account starting your Python interpreter with, I don't know, code from the standard input. Or maybe somebody is starting a REPL, or maybe you're from a file, or maybe it's a zip file or whatever. So now I know more than I just knew, like, two weeks back about Dan remain so very true. You bring somebody in who is motivated and maybe know a bit about what CPython already is built on, but necessarily you're gonna get experience in parts that you would otherwise not touch, because now you're reviewing the bulk of pull requests that are coming in, not the ones that you would write yourself.

51:47 Yeah, absolutely. I remember when listener sent me a message and said I was really surprised to hear you say there is, like, this whole section of the Standard library you didn't know about that describes a lot of there's a lot of stuff out there, right? You might just barely touch it. You might have no use for it. There's a lot this would force you to just get that depth is big. Absolutely.

52:07 So Rodrigo asked previously about what drive by contributors can do to help you.

52:13 This is speaking to a smaller audience, of course, but still, I think it's relevant. What can the core developers and the steering Council and the people on the inside do to help you be more successful and efficient?

52:25 Most of them know me. So the most important thing for them, and I really mean, it is like, just tell me what I should be rather doing. If you feel like there's something else I should be touching on, or if I did something that you don't like for any reason, just write me. Just tell me because it's different from the external contributors.

52:44 Most of the Core Devs I know one way or another so we can be direct with one another. And I think the make or break of this position is for me to provide value for both groups.

52:56 So if there's anything that a particular person needs or wants or even feels like, okay, you're focusing too much on this thing. Have you looked at this? This is not something you've touched yet, but this is extremely important. Just let me know. So communication is key for us right now. And another thing that I kind of still don't quite know how to tackle is that I don't feel comfortable just now, like, assigning a bunch of things to volunteers. You know what I mean? It's like now there are a bunch of full requests where they're fixing something that actually broke because of a change that some core developer did five years back.

53:33 So of course, they have the best context on this change, but I feel kind of icky just going and doing this ten times a day. You know, it really feels like now you're being this manager of Python, telling people, hey, go fix your shit. No, that is not what I mean. Like, as I said, this project is huge, and very often it is really a bunch of people, like a low number of people who have the best context on giving been part of Python. So if I do this too much again, tell me if I'm not doing this. And instead of going ahead and doing changes that you don't like in your particular favorite piece of Python, also, let me know this is still something I'm pretty new at. I'm just going to issue my second invoice next week. I'm pretty excited about that, but it's still a new thing for me.

54:26 So I guess for the core devs. Yeah. Let's talk whenever something is clearly, well, improvable, if that's a word like let me know.

54:36 Yeah, absolutely. How much input into this role did the steering Council have and how much did Guido have? Or was this a PSF plus Google sort of thing?

54:45 So I actually spoke with nobody from Google so directly. I don't know the people behind this position on their side. I know a bunch of Core devs who happen to work at Google, and they're very supportive of the position, so that's the extent of it. The student Council meets with me every second week, so it's mostly kind of me talking. Hey, this is what I spend my time on. They ask me, how can we improve your output or whatever? Or just I would just tell me about things that, you know, they find interesting or important that I might look at, but it doesn't feel like they're really kind of going and telling me what I should be doing. Like, you know, point blank. They're just having, like, suggestions on and how this role should be moving. So this is kind of this is a short, well, 2030 minutes meeting every two weeks, so kind of high level.

55:36 I do have one just like it with Eva from the Psf and E.

55:41 So it's really kind of the Python Social Foundation internally also needs to communicate because they have all the keys to, say, being able to restart a bot or to make changes on a given server, or maybe change some workflow on GitHub that affects everybody and so on and so on. So we just also meet every second week to make sure everybody's on the same page, and also just some very low level of stuff, like, for example, figuring out, like, hey, what calendar am I working on? Like, is Labor Day out day off for me? Or is some other holiday that is here in Poland but not in the US they offer me or don't I get any day of at all? And I work on Christmas Day. I don't know.

56:25 All of those things have to be actually discussed with the PSG directly.

56:30 Yeah.

56:31 Like, we do talk a lot, and Guido in particular was very supportive of me starting this role. So I'm very grateful for this because it's kind of, like, kind of just getting a little bit of an email, just a bunch of sentences, just actually kind of saying, like, hey, I believe this is a great decision. You're gonna do great. Like, I don't know. I I still feel like I'm a beginner in a lot of this. It's really reassuring and kind of lift your spirits. So, yeah, like, I guess we are in constant contact using super old ways, like email and discord to an extent. And now, like VCS. So, yeah, we're doing Google Meets and Zooms with others.

57:13 Actually, we have too many well, communication methods right now. So like, me talking with Cordes. I'm on IRC right now so that others can actually reach me as well.

57:22 Others would talk to me through WhatsApp and whatnot. Like, I have like, ten chat message apps right now open just to be able to talk to everybody I need to talk to. So that is fixing, but I don't know who is supposed to do that.

57:35 Yeah, I don't either. It's a growing problem, not a shrinking one. But it sounds like you're doing a good job. Even Rodrigo out there in the livestream says, listen to this. Hypes me up to go and contribute to Python. So hopefully that sentiment is multiplied across all the people who are contributing work that it'll get more attention sooner. So. Well done.

57:55 Absolutely. I'm happy to hear that.

57:57 Yeah, absolutely. All right. Well, we're about out of time to talk about the new role. So let me ask you the two final questions, which I've asked you before, but it's been a while since you were on the show. So time for an update. If you're do some Python, you always read across different external packages, things on PyPI and what not have you found? One that you're just like, wow, this thing is amazing. We should talk about it, get more awareness of it.

58:19 It's already growing. So I'm not going to tell anything that is now extremely novel, but I'm extremely digging. Rich, like, the kind of text formatting library for CLI.

58:31 Anything that we write would use their progress bars and a bunch of other stuff that's there for column formatting and whatnot I find it very approachable. And the results are like, yeah, this is a console. This is a text console. Just to be clear, it just looks fantastic.

58:48 The code point is very nice. It's very declarative.

58:52 Rich, I like a lot. And Will, the author of it is now working on a text UI library that is much more Pythonic than the previous propositions that we had to say, like a curses or you're with. So, yeah, I'm hyped for that as well. It's called textual. Yeah.

59:09 Textua; looks really interesting.

59:11 Yeah, exactly. So those would be my easy propositions for the day in terms of third party packages.

59:17 Cool.

59:17 The one actually thought of Rich earlier when you talked about the better error messages. There's a cool article called FastAPI, Enrich, Trace, Backs and Development that talks about how to take Rich and then plug it in.

59:29 So whenever there's a stack trace, you get like super colorized error messages and all sorts of cool stuff. Yeah, pretty neat thing.

59:39 This changes a lot actually because I find that, for example, between using GCC, the C compiler and using Clang, like, just the fact that it colors my errors in anything. But it makes Clang just feel nicer to me because it just values my time. It just makes it easier for me to read the relevant parts of the message. So this sort of thing might just feel like this is not really that important in my app, but it might save you a lot of time later on when you're actually debugging stack traces that you're looking at, like at 02:00 a.m. Or whatnot. So I think this is extremely important not just because it's aesthetically pleasing, which is important in itself, but also functionally. This is the reason we are using syntax highlighting because it actually lets you see more information at the same time. So absolutely rich provides this in a very smart way to your application. So not just your Python stack traces, but whatever you're displaying might be like this. It will automatically format numbers, it will automatically highlight dates and files and will file pass and whatnot and whatnot a tremendous volume.

01:00:53 Added tables, all kinds of cool stuff. It's definitely getting a lot of love out there. And then if you're going to write some Python code, what editor are you in these days?

01:01:02 I am deeply invested in VS Code right now because it is in a very, very peculiar position where it's actually very good for CPython development. Core development because it's both a good C editor with support for just jumping through definitions and whatnot, and also has a great Python plugin like Pylens. So it's both a type checker and this language server that does a lot of help for you specifically.

01:01:28 So it's just a good package all around.

01:01:31 Just do CPython core development is it my perfect editor?

01:01:35 Well, almost like if the Vim plugin for it was official, officially maintained and a little more study, I would be the happiest person there, but well, clearly this is super low key feature. It's not a very popular thing. Must not be because otherwise, looking at what Microsoft is now doing with GitHub and whatnot that would have been implemented if more people ask for it. So I might be of a dying breed of time. I don't know. Still gets the job done with the current vim plugin and system with Windows place and whatnot I'm very happy with it. And now seeing that my development environment can actually be run in a browser, like what else could you ask for? It's pretty amazing.

01:02:18 Yeah, exactly. You're doing your podcast live stream recording from a browser and you're editing a browser.

01:02:25 Alright, it's been great to have you here.

01:02:29 Final call to action. People want to learn more about the Dir, maybe want to help you out or consider sponsoring it's in the future or more people. What do you say?

01:02:38 First of all, if you are a Python user, you are very, very welcome to bring issues to us when they happen or whether this is on bugs. python.org obviously a very good place so that your report will historically maintain there. And we can have a discussion that is open and actually work towards a solution, but also in informal ways.

01:03:01 If you reach to us via RSC or ask stuff on the mailing list or discord like we're very happy to hear your feedback. So you don't have to write code like on day one. Don't worry. You might never write code for us to fix your problems. Just report them is great. If you have stuff that works very well for you, you might also spend a minute know telling us because this is something that nobody gets enough in this industry. We only get bug reports, you know.

01:03:28 And yeah, if you do want to contribute, there's many ways to do this. If you want to code.

01:03:34 Absolutely.

01:03:35 Just don't think it's Super Super trivial to get large changes into a 30 year old programming language. I could make an entire talk just about that.

01:03:43 Every little change has huge implications for some small percentage of people, but there's millions.

01:03:50 And so that's a lot sometimes very surprising ones. Yes. But yes, absolutely. We need more people doing the work and there's plenty of it. So you might still have tremendous impact for the world. Maybe your account is going to run on Mars. You never know.

01:04:04 Even if you're just reviewing PR's and making the little tiny fixes or stuff like that, that could be a big contribution total.

01:04:11 And finally, for the current sponsors, thank you. You make this possible. So I really thank you. And for people and companies considering sponsorship for next year. If there's anything that you're not seeing that you would like to see, that would convince you that it's worth it. Also, let the PSF know we might adjust what we're doing so that you're more comfortable with sponsoring, because really, this is a very unique programming language in the sense that it is community driven and community owned.

01:04:43 So yeah, please talk to us. Yeah.

01:04:45 Awesome. Well, thanks so much for being here. Catch you next time.

01:04:48 Thank you. Bye.

01:04:49 This has been another episode of Talk Python to me.

01:04:53 Our guest on this episode was Łukasz Langa and has been brought to you by us over at Talk Python Training. And the transcripts were brought to you by 'Assembly AI'.

01:05:02 Do you need a great automatic speech-to-text API?

01:05:05 Get human level accuracy in just a few lines of code.

01:05:07 Visit 'talkpython.fm/assemblyai'. Want you level up your Python, we have one of the largest catalogues of Python video courses over at Talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all.

01:05:22 There's not a subscription in site. Check it out for yourself at 'training.talkpython.fm'.

01:05:27 Be sure to subscribe to the show, open your favorite podcast app, and search for Python.

01:05:31 We should be right at the top. You can also find the itunes feed at /itunes, the Google Play feed at /Play.

01:05:38 And the direct RSS feed at /rss on Talk Python, we're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at 'talkpython.fm/youtube'.

01:05:54 This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it.

01:05:58 Now get out there and write some Python code.