#350: Python Steering Council 2021 Retrospective Transcript

00:00 For 30 years. Python was overseen by Guido van Rossum since he created and released it back in 1990. When he retired in 2018, he left the creation of the new governing body up to the core developers. After a few stressful months, the concept of US Steering Council became the way forward on this episode. I welcome on the outgoing Steering Council to give us a look back on how this past year is gone. We have Barry Warsaw, Carol Willing, Brett Cannon, Pablo Galindo and Thomas Warders on the show. They're going to give us a rundown on the important decisions of 2021 for the Steering Council. This is Talk Python to Me episode 350, recorded December 14, 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 This episode is brought to you by Research Affiliate and Signal Wire. Please check out what they're offering during their segments. It really helps support the show. Hey, everyone, I just want to give a quick shout out to one of the videos I made in my 'Python Shorts' series since the last time we've spoken. I released one called 'Do You Even Need Loops in Python?' If that sounds interesting. Really? It's about less comprehensions, isn't it? Check it out. I'll put the link in the show notes. All right, let's talk to the Council.

01:35 Barry, Thomas, Carol, Brett and Pablo. Welcome all of you to Talk Python to Me.

01:40 Thanks, Michael.

01:40 Thanks, Michael.

01:41 Hey, thanks.

01:42 So good to have you on the show.

01:44 Some of you brand new, some of you know your faces, but nice to have you all together. You're all on the Python Steering Council. It takes a lot of people to replace Guido. Is that what I'm hearing?

01:56 Absolutely.

01:57 Not even replaced. Just parody.

02:00 Yeah, exactly.

02:01 There you go.

02:02 Fantastic. Well, I'm really looking forward to talking to you all about it.

02:08 Shine a little bit of a light on what the Steering Council does, what you don't do, what your challenges are and the role and so on. But before we do, maybe we can just go around the video version here and have you all introduce yourself.

02:21 Start at 12:00. Barry, you've been on the show before with Paul Everett talking about Python.

02:28 Was it.

02:31 The workshop in at NIST 1994?

02:34 That was the first time I got a chance to meet Guido.

02:37 Right on. Yeah. So quick background, though, for people who didn't listen to that episode.

02:41 Yeah.

02:42 So I've been working in Python since 94. Been on the Steering Council since the initial term, I guess. I currently work for LinkedIn and I guess that's all I really need to say.

02:56 Yeah.

02:56 What kind of stuff are you doing at LinkedIn?

02:57 I do work with the Python team over LinkedIn. Currently, I'm working on an interesting project that's trying to improve the access to technical documentation to our developers. This is kind of a fun project at times.

03:11 Yeah, I bet it is. That sounds awesome.

03:14 Oh, yeah.

03:15 Cool. Thomas, welcome.

03:16 Thank you. I'm from Amsterdam in the Netherlands. I've worked on Python since I think 2000 and became a core developer in 2001. So I've been around for quite a while. Ned Bachelor, who wrote coverage, likes to call me the most famous Python version you've never heard of because of the things that I implemented in Python that everyone uses that nobody realizes I implemented. But I'm happy being somewhat anonymous. I work at Google on Python itself, on how we deploy Python internally. And I have a lot of fun with very complex technical solutions that grows Pablo out.

03:54 And I'm also on the board of directors of the Python Software Foundation, which is a little bit of different work than the Python Steering Council. And right now, I'm also stepping in for Eva, who left us, decided to move on last week. So I'm currently the interim general manager while we're looking for the new executive director.

04:15 So you're basically four jobs. You're a busy person. Yes.

04:18 My dad made a lot of fun of me last week when I told him this.

04:22 He has two full time jobs, and he said I do more work than he does.

04:29 It sounds like you're busy being from Amsterdam. Are you happy the F1 Championship is now.

04:36 I heard the fireworks yesterday, but I wasn't actually paying attention because I haven't watched the Formula One for many, many years.

04:43 Yeah, right on. Well, it's another thing to celebrate over there. Carol, welcome.

04:48 It's Michael. It's always a pleasure to see you.

04:50 Yes, you as well. Happy to have you here.

04:52 Much better circumstances, I think the last time I was on, Brett and I were here right after Guido had resigned.

04:59 Yes.

05:00 To basically explain. What was that? To discuss the possibilities that were being considered for what has now become the steering Council.

05:07 Absolutely. So we're in a great place now. I think. I've been at the Steering Council since the start, and this was my last term. Right now, I'm not running for reelection. I feel really strongly, much like I did with the Python Software Foundation. That turnover is good. And so I am right now in the midst of working as a VP of Learning for a startup called Notable and based on the work that I've done in the Jupyter ecosystem and with Open Science. And so we're creating a collaborative data platform which helps everyone and teams work well together.

05:44 Yeah, that sounds really fun.

05:45 Yeah.

05:46 So you don't have any worry about reelection. You can just vote however you want. You're unencumbered.

05:52 I'm unencumbered, and it's a great flight of people. So I'm really pleased at how things have evolved over time. And obviously these buying folks would be wonderful to be reelected, but there's also great purposes on the slate as well, so I think we're in good shape.

06:10 Yeah. Fantastic. Brett, welcome back.

06:12 Thank you very much. Background. So I'm calling from Vancouver on the unceded traditional lands of the muscreen, squamous and sail tooth first nations. Very upfront on that. I have been on Steering Council since it started. And as for a day job, I'm constantly trying to convince Michael to try out VScode for Python as the way for the Python extension of VS Code.

06:38 Yeah, good work. I mean, I've not seen a tool take off with such broad support.

06:45 I always ask the question at the end of the show, what do you use to write Python these days? And nothing has a second derivative as high as VS Code. Like the rate of acceleration or adoption is really quite something. So you should be proud of that.

07:01 Oh, yes, I'm very proud of the team. They've done a great job.

07:04 Yeah. And you also now live on an island, right? Did those storms like, separate all the roads from the rest of Canada?

07:11 You guys doing all right?

07:12 Yeah, I'm fine. For those of you who don't know, we had a river of storms literally that came through the greater Metro Vancouver area and flooded out every single road in the greater area such that there was literally no land link to the rest of Canada through Canadian land. You either had to fly out or you had to go down through the States, which also was flooded out near us. And it took northwest. So it's a thing. No rail lines either. The Port is completely backed up and we're like the third largest in North America here in Vancouver. So I went to the grocery store yesterday. The shelves are pretty bare due to just logistical issues.

07:48 I'm in Vancouver. I'm fine. It was mainly out. The poor folks in the Fraser Valley completely flooded out. Like, we have no clue what it's going to do. Half of all the dairy and all the chickens for the province come through there. There's been a lot of unfortunate lot of animals that ran on. It's really bad. We'll get through it, unfortunately.

08:04 I'm glad you're okay. That was quite the thing.

08:08 Pablo?

08:11 Pablo Alindo. I've been on the Steering Council for only a year. This was the first time serving. I'm living in the exotic land of London and I work at Bloomberg, which is kind of a financial news company in the Python infrastructure team. So we do a very similar thing as Thomas team do, but slightly different because we need to support all these not those exciting old systems that banks like to use and whatnot. But we also do a lot of very cool tools like the buyers and providers that we plan to open source finish. And we also make sure that Python experience at the company is the better we can. So we are in the Vex Department after the 7th reorg or something. So now we are supposed to take care of that. People are happier one now. And people use out of VS Code apparently as well So.

09:01 I bet they do. Fantastic. I was just recommending the running MicroWSGI and production article from the Bloomberg Tech Engineering.

09:12 All right. That's Peter Sparrow, I think.

09:16 Yeah. Just last week or something. That's a really neat stuff you guys are doing there, right?

09:21 Yeah. And I think Python I mainly work on the parser and the garbage collector these days. I've been working as well recently on improving error messages all around and kind of user experience, if you may. Although that's a bit of misuse, I think.

09:38 Yeah. A lot of improvement on the error messages and trace backs and things like that.

09:43 Right.

09:44 People have been more excited than you would expect, really, when you describe it. I've heard people like, this is so exciting. I can't wait to start using this feature.

09:51 Yeah.

09:51 When we finish the new parser, it's like what we can do with this, that is not only like more syntax because people are like, oh, now we have all these syntax, right. That's not good. Okay, let's make something good so people don't demonizes the parser. So they say, oh, well, the managers are good. So let's leave the parser alone. Right.

10:12 Exactly.

10:13 You're also the release manager, Pablo.

10:15 All right.

10:18 It's a small thing.

10:23 For Python. 3.10 and 3.11, which is going to be released.

10:30 And yes, apparently it's been a very cool release three times.

10:34 Yes. I'm not noticing any problems. And it just rolled out nice.

10:37 Yeah. That's a good sign because it's not that there hasn't been any problems, but only on the release site. Once you release it's good and well. Right. I mean, I'm also be able to do because I have a good team of release managers, all release managers helping me. So thanks to all of them.

10:53 Yeah, fantastic. Well, let's just get started with some definitions.

10:58 Maybe.

10:59 Carol, you could also just tell us a little bit of history since you were on the show as well. What is the steering Council and then where did it come from? Yeah, this is a relatively new thing for Python.

11:09 It is a relatively new thing. When Guido retired, he left it in the hands of the core developers to come up with a new governance for the language. And so I'm really proud of the core development team for coming up with several different options for how to organize. And then we voted as a group after we discussed it all. And the steering Council level was the one that went out. It's five individuals from the Python community, not necessarily core developers, but could be beyond who are basically entrusted with by consensus building the direction and the future for Python, both the language as well as the core development community. And I think so far it's worked out really well through three terms.

11:59 I think we faced a number of different issues, and we've done our best to include many different voices and do our best to steward the whole entire ecosystem.

12:11 Well, I would say you all have done a great job because I haven't heard anything very much in the sense that Python is still being released, features are still being added to the language, maintenance is still being done.

12:24 And there wasn't a big disruption when Guido left and there was a lot of uncertainty because as you said, he said, all right, I need a break. I'm stepping back. I've been doing this for 30 years. That's a long time. But he didn't want to impose a structure as the person with no skin in the game.

12:41 Yeah.

12:42 The entire Python ecosystem yourself and others for really rallying around and trying to make everything work. And I can't underestimate EVAs and the Python Software Foundation's impact on that as well for their support. So I'm glad you haven't heard anything I can't say. We've seen the same.

13:03 Well, when you're in the eye of the Hurricane, it feels different.

13:06 Yeah, totally.

13:08 Yes. Or the middle of the Hurricane, rather. Anyone else want to add anything to that? Just sort of the historical bits before we get into mechanics.

13:14 I think I want to be fair to Guido. He said, I'm going to give the core developers a chance to self organize before I decide on a successor or something. So it wasn't really him saying you guys figured it out.

13:29 I think core developers need to figure out what they want. And he still is a core developer, and he was on the first steering Council as well. So there was a very deliberate transition of influence instead of power. But if the core developers hadn't figured something out, then I'm pretty sure he would have decided for us. And I think people would have been probably would have been happy with that at that point. But I am really glad that we got a working and very effective steering Council instead.

13:58 Yeah.

13:59 I think the thing I'll add is that over the years, like, there was a lot that was sort of under specified in the steering Council spec. And every year we sort of figure out what the right rhythm of business is, how often we're going to meet, what kinds of agenda we're going to take on. That's been really great. It's been great to work with everybody here and everybody in the community to kind of figure out how the steering Council is going to work. And I think we've gotten to a place where it's very effective.

14:26 Yeah. And there are other organizations sort of playing in that space. We have the core developers.

14:32 We've got the board of directors, Thomas, you've already mentioned, and then you've got the steering Council. So where does the steering Council fit in there? What's the responsibility of the steering Council? Are you overseeing the core developers? Do you work with them? How does it all fit together?

14:48 So I think Pep 13 does a reasonable job explaining this. The idea is that he was called the benevolent dictator, but he wasn't really dictating all that much. He was basically the final arbiter, and he let the core Dev community make its decisions.

15:04 The benevolent delegator.

15:06 Well, he did push his opinion through when he knew he was right, and I think history has shown that he was right more often than not. But the core developers are the people with commitment writes in the GitHub repo that's basically it the people who have contributed a lot to Python, various bits and pieces or overall, I think everyone there has earned the right to self organize. So that's what the steering Council is. But it is still consensus based. The mandate of the steering Council is to figure out what the core developers want. It's not for us to impose our opinion on the core developers unless there is no other way.

15:48 Yeah. Some organization or somebody has to decide if it's 40 60% plus and against some idea. Somebody's got to go. We're going to do it or not do it. That used to be Guido, and now it's you all right?

16:01 Yes. It's easy when there's a clear answer. It's easy when everyone's clearly in favor or against something. It is the 40 60 things, the difficult decisions where we also have to take our time to understand the problem and see how it affects people and carefully make that kind of decision.

16:20 Sure.

16:21 And I'll just point out that the PSF board of Directors is not specifically involved with the core developers. So the PSF is for community work. It's for fundraising, it's for the trademarks, it's the Copyright owner. So it's also for legal things. But the PSF doesn't dictate what direction Python should. The language should be going. It just talks about the community. So it's a completely separate concern there. But we did have the executive director, Eva, sit in on our weekly meetings and help us with administration. And we hired the developer residents. That is to say that the steering Council hired the PSF employee, that is Lucas, the developer in residence. So there is a lot of interaction as well. But it's mostly the steering console using the Python so Far Foundation.

17:14 I would say. This portion of Talk Python to me is sponsored by Research Affiliates.

17:20 If you are a regular listener of the podcast, then you're passionate about Python and looking for ways to grow your skills. But are you twirling away with Java in your day job only to spend your nights and weekends exploring Python? Or maybe you are working in Python, but your management puts shipping features over testing and code quality. How does a full time software engineering job where writing excellent Python is an everyday requirement? Sound to you? That would be your job if you worked at Research Affiliates. Research Affiliates is a California based leader in investment products. You probably haven't heard of them, but their research and insight powers mutual funds and ETFs that may already be in your 401K. Their technology group is looking for software engineers with a deep understanding of Python. They are a team of expert Python coders who use Python to write production, financial systems, internal Python libraries, and business automation routines. What's more, their team provides ample opportunities for shared learning and professional development. Frequent team code reviews and community engagement through open source contributions and conference attendance are core parts of how their developers work. So if you're looking for a full time engineering job, writing professional Python with a team of friendly and congenial engineers come work for research affiliates. Apply today at 'Talkpython.FM/researchaffiliates' or just click the link in your podcast player show notes. Carol, it looks like you're going to add something.

18:43 Yeah.

18:43 I was just going to say in terms of the 60 40 decisions, there's been very few of those. And part of the reason is there isn't consensus. What we do is work. Like, for example, a pattern matching was when where we asked the path to be reworked several times so that we wound up with a better solution in the end than what we would have if we had just voted Yay or nay at the start.

19:10 Right.

19:10 I think that's an important thing to remember.

19:12 Yeah.

19:12 It helps that all of you are on the technical side of things. Right. As opposed to overseeing this or whatever. It really helps that you can get in there and say, no, this is going to have performance implications or this is going to have breaking changes or whatever.

19:28 And we come at it from different places, too. So that's also an interesting thing that's been, I think, really valuable for us.

19:36 Yeah.

19:37 Carol, you come at it from the data science, scientific side a little bit more. And Brett comes in from the editor side. No, just kidding, Brett.

19:47 Fantastic. When are the elections and then how long do you serve for? The elections are right now.

19:53 They close, I think on Wednesday, the 15 December, anywhere on Earth, or is it Tuesday anywhere on Earth? It's sometime around there.

20:01 I think it's Wednesday or something.

20:04 And they've been going for the last two weeks. The way it works is when the major Python version is released of 310. In this case, that triggers the elections of the new steering Council. Since we have releases every year, that means we have a new steering Council every year and we have a single one year term. So everyone gets reelected or not. At the end there there's a two week nomination period and then we have a two week sort of discussion period and then a two week vote period.

20:31 We're nearly at the end of the two week vote period. So by Wednesday, Thursday, we should have a new steering Council. And as Carol mentioned, Carol's not up for reelection decided not to go for reelection. The rest of us is we have no idea we're in the running or not.

20:50 The slate is just really great. So it could be just five new people entirely, which I would be more than happy with more than enough to do as it is.

20:59 Yeah. Do you think it would make sense to have one person stay around as sort of some continuity or probably is going to happen just statistically.

21:07 Right.

21:07 But I guess we've talked about it.

21:10 I mean, that's sort of the nice thing, right. It's like we adjust, like things aren't necessarily set in stone. So, for example, when the first Steering Council was elected, when Guido retired, we were actually on an 18 month release cycle. So there was a lot more time between elections. And now that we're on a yearly release cycle, we've decided to keep the Steering Council elections aligned with Python. Release seems to be working okay. And if it doesn't, then we'll have a discussion about that as a community and proposed changes. But so far so good, right?

21:44 Yeah, absolutely.

21:46 We used to have Eva as sort of the administrative memory of the steering Council, even though I think there was an overlap of four people at every single past election. So it didn't really matter. Even though I have taken over some of the duties, if I am not re elected on the Steering Council, I won't be attending as the PSF representative because it just doesn't feel right. But it might be that the next executive director does step up and take that position. So we might have the PSF executive director as the one person who's been in multiple Steering councils and can transfer over things.

22:24 Yeah. And that would give the PSF seat at the table as well.

22:28 It's more about information flowing from the PSF to the Steering Council than the other direction, because the Psf doesn't really involve itself in the Steering Council things. But there is the developer in residence, there's money, there's sponsorships, there's a sponsorship benefit to PSF sponsors that they get to have a little chat with the Steering Council, which each Steering Council has to ratify. It's not a done deal for the next Steering Council, but it's just a nice way to have some connection with the people who care a lot about Python companies that care a lot about Python. And we also do have a handover meeting for the next Steering Council where we'll have both the old Steering Council members and the new Steering Council members and make sure that discuss any running issues, anything that the new Steering Council needs to know. So even if five new people get elected, it's not that we're just throwing them out in the wild and let them figure it out on their own. We're still there. We're still part of the community. Even if we don't get to reelect.

23:25 Yes, true. You're all still core developers. They could still reach out to you and ask about something. I want to talk about two people really quick while you sort of touched on both of them, Thomas, one is just to say thanks to Eva, that she's done a lot of work and she's been at it for ten years or something like that.

23:45 Ten years as the Secretary or director of operations or executive director of the Psf. She was involved in organizing she was organizing PyCon before then. So she's involved in PyCon even longer than that.

23:59 Yeah.

23:59 And for those who are not watching the livestream, pretty much the whole Steering Council just did a little silent applause. So we all miss her dearly. And it's only been a week.

24:07 Yeah, absolutely.

24:09 Best of luck to whatever she's off to do next.

24:12 Also, Betsy Betsy did a lot as well and think she's also moved on.

24:17 Betsy was assistant Secretary, I think, of the Psf and also organizing sponsorships and all that. And so she was involved in a lot of community efforts.

24:26 We owe a lot, especially PyCon. It seemed like she did a lot.

24:29 And both of them, so much of what they did was behind the scenes. And I can't think enough their work ethic and how helpful they have been to me and the steering Council on so many different levels. So we certainly miss them. But we also wish them the best in their next adventures.

24:49 Yeah.

24:49 All right. With serious things. I do want to show something I think you all will be amused by.

24:56 Have you all seen this Twitter thread here? Yes.

24:59 There was a great mentioned by Patrick Mason saying, hey, the Psf at Psf on Twitter is searching for executive director here's the job announcement. Has this been filled yet?

25:11 We're still looking for well, I mean, the process isn't oh, we like someone. We're hiring them. There's a whole search committee and there's resumes to go through and then there's interviews to have. We're in the process of interviewing a whole bunch of people via the search company.

25:27 Okay. Is it still open for applicants or is it kind of you have tons and now you're going through them.

25:33 We have really good candidates, but I think more is always welcome. So right up until we decide, especially in December, I think more resumes.

25:42 Yeah.

25:43 Great. If people want to apply. Absolutely.

25:45 Okay. I'll put a link in the show notes for that. But of course, at Psf is the Pacific Salmon Foundation, and they kindly respond at the Psf is looking for an executive director at Psf is not currently. Good luck on your search. Sorry for the confusion. And then they responded. It happens. We're starting to feel like at the Psf family, it's not like at Java ever calls Broken heart. I thought that was a good way to respond to it there.

26:12 Yeah, there was a lot of. But I think Dustin Ingram, one of the PSF board directors and also a Googler got a follow from the Pacific Salmon Foundation even though he's never had a follow from the PSS. So I thought that was extra funny.

26:27 Yeah, that is really funny.

26:29 Nice and lighthearted. Now I also want to ask about the developer in residence and how has Lucas work helped you all out? I mean, I'm sure Pablo, he was the prior release manager and is also dedicated to helping this be smooth. So maybe had an even bigger effect on you. But what's the developer in residence role interaction with you all?

26:52 Yeah, I think this is one of the things that we are more proud of. Bootstrapping I took a lot of time because we have excellent candidates, all of them. And it was not an easy decision. But I think so far also like Lucas has made an excellent job. So I think one of the things he was working on a lot is trying to help with the review kind of queue. That's one of the things he's been putting a lot of work. It's extremely difficult because we have a lot of PR.

27:21 I think he has already been on the show before, right?

27:25 Yeah. Actually I interviewed him about specifically listening to that particular episode.

27:32 But I think that has a lot of impact. But there has been a lot of other places that maybe are a bit less known when he has been helping a lot. Like for instance on the releases. Like doing Python releases is quite involved in some good way.

27:47 Is it harder to do a major release like a 3.9 to 3.10? Is that harder than.

27:56 Two moments that are special event. One of them is the first beta release because what happens is that on the first bit of release is the point where no new features can be added. And technically from that point until the final release, it's only about fixes and things like that. Although people try to stretch the definition of a fixed square a lot because there is always been the strategy of like I can push maybe this feature like half baked and then call it a bag and then it's like, oh, I'm doing a back fix.

28:27 That's when the role of the release manager it's quite important because you need to be human. So sometimes it's like people have, they are computing on the free time. So maybe they tell you I don't really have time for this but there is always time for discussions but also you need to be careful with that. And the other problem that happens is actually because it's a deadline, everybody pushes everything on the last day. It's like incredible amount of activity. And some of the systems that we have to check everything, they take a lot of time to do their checks because they are quite slow checks that take like three, four, 5 hours.

29:07 And I will have to run every unit test for the entire CPython suite and things we have like a big CI that Windows.

29:18 macOS and Linux. But then we have this thing called billboards that basically machines that are donated or that we run that test on flavors of these platforms, different distributions and different version macOS. But also it runs heavier checks like sanitizers checks for reference leaks.

29:38 If you putup here on the CI, everybody will have it would be ridiculous. So we have these things and they don't run on a single commit, they run on batches. So basically all commits of the day and then if it fails, you need to do some manual bisection. But anyway, what happens is that because everybody pushes that and then you need to do release. At the end of the day you need to kind of wait for these machines to run and then what happens is that everything is extremely broken.

30:05 Normally up to this point it was a bit weird because technically people are responsible to break or they put broken. But the other day it's kind of like it's the release manager that finds people to fix it or I fix it myself a lot of these things. And it's very stressful because people are waiting for the release and it's a quite important release to start testing and the distributors are working for you because they have their calendars and those nights have been extremely stressful for sure. I mean, three times has been as well. But with the help of Google, actually, we've been coordinating with this. And if not, for instance, the last time we've been fixing between the two of us, all these little things, sometimes you need to revert the thing because it's so broken that we don't have the time to find out what's going on or it's too risky to think, like maybe it's fixed, but who knows?

31:00 Sometimes we just that would be a bummer if your PR failed through CI only was two years.

31:09 And people don't get happy when you push them back in your feature.

31:13 It was a year and a half.

31:14 Yeah, actually, almost.

31:16 But it still is quite all time, especially if you miss the line because.

31:21 Well, don't put things off until the last day. Come on.

31:24 Yeah.

31:25 People don't understand us as well as you would think.

31:29 Thomas. Yeah, Thomas, you can say.

31:32 And then there's the reality of human behavior.

31:39 In a wood way. I mean, it's not like we are all friends here in the court.

31:45 It's important to have, I think one of the important parts of being a you need to have the kind of communication skills because it's not only about the technical part, it's also like communicating. I think this case has been also doing a really good job. He communicates quite well and especially in tricky situations. And I think that there is an asset of the position, like you need to interact with a lot of different people in the team. People sometimes they say you'll pay for this. So here's all my land release.

32:12 You need to also tell them no, we have these priorities and whatnot, but yeah. So this has been an area where he has been helping a lot, doing releases. He's still doing releases himself, because whatever now is kind of a long serving.

32:29 This portion of Talk Python to me is brought to you by Signal Wire. Let's kick this off with a question. Do you need to add multiparty video calls to your website or app? I'm talking about live video conference rooms that host 500 active participants, run in the browser, and work within your existing stack, and even support 1080p without devouring the bandwidth and CPU on your users devices. Signalwire offers the APIs, the SDK and Edge networks around the world for building the realest of real time voice and video communication apps with less than 50 milliseconds of latency. Their core products use WebSockets to deliver 300% lower latency than APIs built on rest, making them ideal for apps where every millisecond of responsiveness makes a difference. Now you may wonder how they get 500 active participants in a browserbased app. Most current approaches use a limited but more economical approach called SFU, or Selective Forwarding Units, which leaves the work of mixing and decoding all those video and audio streams of every participant to each user's device. Browser based apps built on SFU struggle to support more than 20 interactive participants, so SignalWire mixes all the video and audio feeds on the server and distributes a single, unified stream back to every participant so you can build things like live streaming fitness Studios, where instructors demonstrate every move from multiple angles, or even live shopping apps that highlight the charisma of the presenter and the charisma of the products they're pitching at the same time. Signal Wire comes from the team behind Free Switch, the open source telecom infrastructure toolkit used by Amazon, Zoom, and tens of thousands of more to build mass scale telecom products. So sign up for your Free account at 'Talkpython.Fm/SignalWire' and be sure to mention Talk Python to me. Receive an extra 5000 video minutes that's 'Talk Python.FM/Signal Wire', and mention Talk Python to Me for all those credits.

34:20 We need to actually find the next commitment manager for.

34:24 This is about the time that we try to find you.

34:27 How do you do that, Barry?

34:29 We have a group of former release managers, kind of. We throw around some names and then we find somebody to.

34:37 I guess, convince someone to volunteer.

34:43 Exactly.

34:44 We have like a long chain with a big ball at the end.

34:53 No one will ever approach Benjamin Peterson's duty.

34:58 That was a bad deal.

35:04 Yeah.

35:05 He did not sign up for ten years of about six releases.

35:16 I cannot imagine releasing a Linux kernel version, but it's a multi hour process quite a lot. And there is always when people say, oh, can I do automation with these actions that come on.

35:29 Good luck. We have already like a huge amount of automation, but there is a lot of processes.

35:35 It's ridiculous.

35:38 There is so many ways you can fail and you need manual intervention that automatically needs I have something already that for minor release or Alpha releases and whatnot which are a bit like you don't need to build documentation or not. It's almost automatic, even waiting for humans to do things. But for big ones like betas and final releases, it's 5 hours of usage. Now there's a lot of problems that happen on the go, so it's impossible to do it.

36:07 Pablo has also live streamed all this. So if you really want to see all the effort that goes into it, you can include watching him. If you go back, watch where he breaks GitHub. So there's a lot that goes on in those.

36:18 Yeah, that's right. I think I saw you guys all sitting down and live streaming on YouTube.

36:25 It was just Pablo and Lucas and the other managers, not the steering Council, just to make sure the rest of the steering Council stays away with them from all that we know too. Well, I did want to bring it a little bit back to Lucas work and the developer in residence position because it was funded for one year so far by Google because of some money that was lying around and they wanted a good place to donate it. Eva sold it to them or Dustin sold it to them. I'm not sure what happened there. I wasn't actually involved myself, but it is something that we need to fundraise for in the future to continue it or maybe expand it. We've already talked amongst ourselves saying we would love to have three developers in residence instead of just the one. We've had some really good candidates when we hired Lucas other candidates, I don't know if they'd be in the running, but there's clearly enough interest there's clearly enough work as well. Now, Lucas has been focusing a little bit on selling the position as well because he was very aware from the start that for it to continue we need more funding. So he's been trying to make the case with his work, make the case that this is a good thing to have and something that people should invest money in, which is why we have the weekly developer in residence reports that he does, for instance, to showcase the work and all that.

37:52 Yeah, he's very much out in the open about that, right. He does a sort of weekly blog and summary of almost the report you would give to a manager, but his managers are the community. And so I just published that.

38:03 Right.

38:03 In a very real sense, that is the case. I mean, it's not a manager who prioritizes the work because that's us sort of. I mean, he does it on his own mostly, but we're there. But it is the people he is accountable to the way he feels it. And I think we all feel it that way. It's the community work, and he's supposed to be doing the things that need to be done, but that you can't really demand of volunteers that they do. So I think that's working out fairly well.

38:33 Yeah.

38:33 And it's also the context of switching.

38:35 Right.

38:36 Like every one of you has something you've got to work on for your day job and then to come back and work on a PR or a bug or triage something or help somebody get CPython to compile on their machine so they can contribute. All of those things are better done if you just stay in the flow of going through the issues and going through stuff. And he can do that full time, right?

38:59 Yeah.

38:59 He has a full time to spend on all of those things. So he's still context switching a lot.

39:04 Sure.

39:05 But the context is more tightly grouped.

39:09 Yeah. And I think it gives you the language, a continuity and sustainability.

39:16 People are going to have to on board and off board. We've seen that very much within the Pandemic, and it kind of gives us a baseline that things are running as it should be. And also he's made a lot of automation improvements as well. So there's an incremental like, let's make it better each year.

39:34 Yeah, absolutely. How involved or at all was the steering Council and getting moved to GitHub.

39:42 Like the repo or the issues?

39:44 Not the issues. I know the issues are still coming, right. They're not there yet, are they?

39:48 Yeah.

39:49 Working on those two. Yes.

39:50 But the initial get the code over there.

39:53 Get the thing canceled.

39:56 Yeah. I was trying to think about the time. It just preceded that, didn't it?

39:59 Yeah. I mean, Brad actually was.

40:04 Yeah.

40:05 Brad in every change to our version control system, probably since the CVS days.

40:12 I was going to make a joke about CVS. Come on. Yeah.

40:18 I was involved with CVS to subversion, but everything subsequently I've somehow been involved with.

40:25 Yeah. So are you happy to see it on GitHub now.

40:27 Brett, since I'm the one that made that happen. Yes.

40:31 Well, I mean, you could regret it.

40:33 No, I would think so.

40:34 It seems like it's gone well.

40:35 Yeah, it's worked out pretty well. I think there were some bumps way back. Like, for instance, I wasn't expecting quite so many core devs who don't contribute to any other open source except Python, and thus they didn't know GitHub and they didn't know Git at all.

40:49 Yeah. You completely changed their workflow, right?

40:52 Yeah. So it was one of these things. It was a learning experience for some people, and we just had to help them along. There's a whole Doc, I think might still be there in the dubgard of how to get for material users. Yeah, all that. So it's definitely been great. And I'm really appreciative that one of the things we've been able to do this year, the steering Council is we're very close to moving our issue tracker over to GitHub as well. So there will be a bit more of a connection between the PRS and the issues maintain our own infrastructure anymore, which has always been somewhat of a burden for ease and having to keep bugs up or grain this whole time, he's got everything else on his plate. They always have to keep up and running. So. Yeah, but I mean, Marietta, for instance, deserves a lot of the credit for pushing this because she wrote the original Pep and has always been poking people like, hey, can we still do this because it's still happening, what's going on? And thanks to the Psf for getting the money together through GitHub donations to make sure that this happens and coordinate all that money and all that hiring. So we're able to have it as a Cordev work on this. And we've been kind of project managing it towards the end on this to get over the finish line, but looking good. And the goal now is hopefully January sometime we'll be flipping the switch and moving over.

41:59 Yeah, well, that's coming up quick.

42:01 I think that's sort of like an underappreciated, perhaps, contribution to Python.

42:06 Right.

42:07 It's like Mariana has done an amazing amount of work. Brett's done a lot of this as well to make those kind of like get a workflows really natural and easy to use. So there's lots of people who contribute to Python in ways that are maybe not quite as obvious as what the steering Council does, but are just as important.

42:24 If not more important.

42:25 For making the whole experience of developing Python really smooth and easy to do.

42:31 Yeah. I think also kind of nowadays more and more people are conscious of this, but I think there is also a special emphasis on like when you contribute this code, then even people feel that or they have doing documentation contributions or even like CI contributions or whatever they say, come on, it's important for us to highlight this. And there is a lot of even code developers. There is a lot of code developers that don't continue code, even just tryaging and all those things that those are as important or even more like call is not a small part, but it's also by far not the full picture. Right. Even if you take goods work. Right. He's not calling that much as the developer.

43:20 And you see the impact that he's having, literally. We are searching for someone who does that kind of work because it's needed. No, we are not searching for excellent calls. Right. We already have a lot of those. So I think it's important to highlight and I would like to take the time to say here that when people think of contributing, you don't need to think out code.

43:41 Right.

43:41 You don't have to master pointers to pointers.

43:45 There's a lot of ways to contribute.

43:48 There is a lot of people that go and it's always the same thing.

43:52 I'm spending a lot of time mentoring new code developers. Like the last four core developers were people that I helped mentoring myself for partially. And it always happens. I mean I've been also very lacking. Like the last core developers that I've been mentoring has been extremely smart people and super competent. So it's not been a problem. But from the people that are starting to contribute for the first time, it's always the first question how do I find issues that I can work on PR, which is the most difficult thing to solve? Because it's not only like what do you like and what are your skills or interest? But it's also like Python is a firm The mature code base. It's not that easy as like there is this thing.

44:30 But the key here is that a lot of people don't think about the fact that you don't need to think out because they think backs like what is the back or what is the feature?

44:39 A lot of the time what happens is that the easier parts are actually for them. Right? I mean, maybe there is a program that really likes coding and it's basically to say work on this or do I packaging work on that? But a lot of people actually are very passionate precisely about other things. They come from a point that core developers don't have, like for instance, documentation. We are quite bad at writing documentation, not because we don't have the skills that we do is because we are thinking like core developers. So we are like, okay, yeah, I think I know the system, so I'm documenting this as I think, unfortunately, who is new to the system.

45:15 Yes, it's hard to see with new eyes.

45:17 Yeah. From the user perspective, maybe we put a lot of detail that's not important and makes it more difficult. Or maybe we are missing some things that we think is implementation in detail, but there's not that it's not that's very important and I'm happy to see that more and more people are like working on these kind of things and those contributions are super important. Maybe that's where you can have a huge amount of impact.

45:40 Right?

45:40 Like instead of fixing back, I mean fixing back is so important. But I think my first PR in CPython was in documentation. I'm super proud of it, actually. Marieta was the person who merged it. Interesting.

45:53 Yes, it's fantastic.

45:54 I think it's important to mention that and more and more people now are helping with CI because they are super knowledgeable about GitHub actions and they say, actually this is very efficient, maybe you can do this, blah, blah, blah. Or maybe you can have in the PR kind of comments from the compiler warnings that's something that someone could do it and that is fantastic. How many backs are going to be sold just because for us, for even for Lucas and myself, it helps a lot because when we see the warnings, we don't need to fix it ourselves because it's there. So those changes are actually more long lasting or even documentation.

46:30 Yes. And that's the kind of thing that's a little orthogonal to the main CPython code that you can go and say, I'm going to just try to make the error message more descriptive and that's less likely to cause some sort of butterfly effect. Like, well, I changed the speed of the C Eval C loop, and that has all these knock on effects. Right. We put in more details into the string as part of the error. That's way more doable. Right. That kind of stuff as well.

46:59 As well, if you think of the better errors thing. I mean, there is a lot of technical stuff there. But one thing that happened is that now a lot of computers are actually computing the errors themselves. Like, no, but it's not focused on call or fixing or other infrastructure because they like to have better errors and they are very passionate about it. It's fantastic because it's also a different area where it can have. But you were saying that apparently people are super happy with that. And I've been contributing in very core parts of the Python, and I will never thought that this was something that is going to be so much acceptable.

47:38 But if you are in the training business, like if you were going and doing an in person event or a workshop and the students are stuck and now they have a message that gives them more info that helps a lot of things go more smoothly. So, Brett, I'll throw this question out to you first here. What are some of the big during the tenure of this group this year, basically, what were some of the big or hard things that you had to decide upon?

48:06 Oh, wow. Right. Hard things to decide. Well, honestly, if we're going to be honest, anything conduct related is always hard comes up. And as the final deciders, as it were, or the great deciders for the core team, sometimes contact stuff comes up in the audience.

48:22 Piling refers to all as the dream team.

48:26 Makes sense. But yeah, contact is always the hardest. We don't like it. No one likes it. It's tough. We're very lucky that the Psf conduct working group access. I'll Disclaimer. I'm on it as well. But I also recuse myself whenever some core stuff comes up. But we're really going to have them to help us give guidance, because that's what kind of groups, therefore, is actually to provide guidance to actually can't enforce anything. But we lean on them to kind of act as independent arbiters of everything. Because for a lot of us, we've been here, we've been on this team long enough that we pretty much know everybody. Right. A lot of us are friends. That's hard to be impartial. There's a lot of history as well with people. So we lean on a group to help kind of act as the independent body that doesn't have all that baggage that we're with each other. But then it comes back to us and we have to make a final decision of what are we going to do about this. And it's hard every time. It's not fun.

49:19 If it's ever reached that point.

49:21 It's not great.

49:22 Yes.

49:22 I would put those in the Quadrant of hard and not fun. There are other ones that are in sort of a hard but fun kind of Quadrant where some of the technical peps and things like that. Pattern matching was probably one of the most recent ones where you really have to think through some difficult technical problems. But that's kind of the fun part of doing this. Right. We enjoy that.

49:47 Even though it's hard.

49:49 It's still on part of the job. So hopefully it will be more days and fewer of the fun and not or not fun and hard.

49:57 Yeah, yeah.

49:58 Probably the closest I can think of off the top of my head was deciding for 310 not to make from under future employment.

50:09 That was a really tough one because there was a lot of stuff happening in the community, people. Certain framework authors are like, you're going to break our framework because we depend upon this and whatnot.

50:18 Right, right, yeah. I mean, it was one of these things where that Pep was written, accepted. I think like two months after Pydantic was even created, it went public or something.

50:27 Yeah.

50:28 Pydantic and FastAPI were two of the most popular.

50:31 Exactly.

50:32 Changed since that PEP got accepted way back when, I think.

50:35 I don't think that was even steering complicated. I think that was a Guido decision.

50:39 No, it was Guido delegated to Lucas decision.

50:43 Right. So that was a bit stressful because it all happened right before Beta. Right. And it was people reach out to people.

50:52 There was a bit of panic in some corners of the community, but we did the best we could to reach out to everyone and say, no, let's have a discussion. We can figure this out. And we just discussed it with everyone involved on both sides, both sides of the type of community, both dynamic and static, and just chatted with people. I was like, look, we can't rush this. And it's looking like this decision is going to feel rushed based on the feedback we're getting very near beta. So we're just going to rip the code out, which thank you, Pablo, for reverting that worth, because that was a messy back.

51:22 Next time, I can dump that on Lucas.

51:25 Exactly. Yeah. Because this is pretty Devon residence, right.

51:29 Yeah.

51:29 Deal with this. But it was tough. But I think everyone involved was happy with the decision that was made. In the end, I have no regrets. I don't think anyone else in the street has always regrets. I think everyone involved feels like it was the right decision not to rush that. We still have to make a decision, which is tough. We asked the community to see if anyone wanted to step forward, to actually talk with all areas of cycling world to see like the Pep 649, which Larry Hastings is proposed as a solution to the problem of runtime types and binding and all this, a lot of stuff. We've asked the community, can someone support and kind of act as almost a champion of a shepherd or expert to come talk to us to explain that? Have we hit all of the potential issues with the gender futures important annotations or Pep64 variants proposal or something else? And honestly, no one step forward. So this is actually one of those things with Strange Council may actually in 2022 have to come forward. We'll have to chat with this ourselves. We'll have to do the legwork and we'll just have to do it. And it will take time. But that's what we're here for is if we ask the community to do something, no one wants to do it. We're the backstop to make sure stuff still happens and works.

52:36 Yes, sure. Maybe give people who have been tracking that super closely. Just a quick summary of what was that feature and why did it cause a problem?

52:45 Yeah. So from the future, import annotations. What it did was it made all type annotations strings, which for performance reasons and forward reference problems is really handy. Right. Like there's no overhead on import. Everything is just a string. It's in the code object. It's nice and fast. And if you need to reference something in the same module before you've actually gotten to define it. Right. Like if you have circular references.

53:07 Right.

53:07 A class method that returns its own self. So you would yeah, exactly.

53:12 Or class A has an attribute of class B, and class B's got reference A. It takes care of all that because it's just strings. There's nothing to really do there. And then the type checkers just handle the references. It's not a problem. The problem is projects like Pydantic, which various other projects like APA depend on, that messes them up because they need to actually convert those strings back to the original objects that they represent. Right.

53:37 Because they want the rich type information out of that.

53:39 They need to see that they want the actual object that that type annotation defines. Right. When you do like list bracket Int, they want that actual object that that represents so they can get at that information. Okay. This is Typed to a list of events, not just, oh, it's a string. I don't know what the heck that is. And there's a function in the center library that you can call in the inspection module, which is now in the inspect module, but a better version of the inspect module that will give you the actual objects. But the problem is you still have this reference problem and a couple of other things, and it's not worked perfectly. And that's why the dynamic typing side, the live typing side is the type of community got really worried when they realized this was about to become the permanent thing and why we stopped. Now there is a Pep 649 which tries to use closures instead to kind of capture all the variables and everything but not execute anything. Right. It's very much like a function closure you'd use today where you had a function in a function, the inner function refers to something in the outer function. Nothing's actually happened yet, but at least that reference is still there so it knows where to look for stuff. Problem is, we don't know if 649 fixes enough things for that to be the solution we want to go with because we don't think we're going to get another chance to tweak this. Right. If we're going to try to come up with a solution that fixes all the problems that from the future of Anticipation fixes. We also have to make sure it fixes as many of the other problems that also exist at the same time, so that we only do this once because it's potentially messy and it doesn't have to fix everything.

55:10 But anything that it doesn't fix probably will never get fixed.

55:14 So we have to be prepared to live with that and be very aware of what those non fixed situations are. So everyone knows that's something to be careful.

55:21 I think the second aspect is the key. I think it's probably what is making this so difficult.

55:27 We already have future import and we don't want three of them or combination of them or whatnot. So I think it's important and it is the most difficult thing for us because as a team PEP is extremely time consuming. And whatnot because you need to not only be aware of the change itself, but also because the documents are written by the author.

55:49 It's not like there is ill intention or anything, but there is a lot of things that maybe are left out. So you need to make sense of the void that is behind this thing or what is the far reaching effects. And in this case, the problem is that how many other things we know that is not going to work. Because now, like you see, we knew all these Use cases days before Beta. What else about all the people that are not contacted?

56:15 One thing I want to say as well is because this is important. Like we care about like Antique and FastAPI, but we care about everything else. Right. You don't need to be the author of a big framework to have the thing counsel attention. And that's quite important. Yeah. I think it's important to remind.

56:30 Right.

56:30 Because it's important because there's a lot of people using this Use case and therefore it has more weight. That's true. Just because if we mess up, it's going to affect more people than some random library. But the Random library is also as important as long as it's using the interface that we provide in its own right. And this is important to know because maybe there is a community of people that use type annotations for database tables or who knows?

56:57 Yeah.

56:57 They didn't follow contacting the team Council, Python Dev or whatever. It's important if you're listening to this and then you're an author of libraries that use type notations or even a user that uses type notations in nonstandard ways. It's very important to reach to us and maybe in the future to this person who is going to lead this effort, because we absolutely need to know what these PEPs are not going to fix. So we say, as a team can say, okay, we take the next thing. We take the informed decision to accept this, even if these use cases are going to be sacrificed, because, as Thomas says, we cannot fix everything. Right. But we must know where we're listed, because what we cannot have is now the situation again.

57:37 Because we missed you only get so many reviews, Carol, right.

57:41 Yeah. I mean, there's so many different communication levels on this whole thing.

57:49 As you know, Michael, from Doing All Your Horses, a 30 year old language that has many different use cases, it's hard to sort of one size fits all. And I think I reached out to Sebastian and Samuel because we have been using FastAPI with great success, and our engineers really loved it. And I think it is something that is reenergizing the whole web based side of Python. So you don't want that sort of cut that off at its knees.

58:25 Exactly. It's one of the things taking advantage of so many of the cool new features, the typing, the async and all those things and whatnot.

58:33 Right. But by the same token, it also, as a library writer with Jupyter, and Binder, it's really hard to keep up with everything. And we tried to always test ahead, but not everybody will and can do that. And then also what you do is you understand your library well, but you don't necessarily understand the Python internals at the same level or the same depth. And so I think Lucas Proactive reports out, as well as Pablo's amazing release notes in the last couple of years, helps to communicate out what's going on. And this was an unfortunate last minute revert. And the whole community working together is really what's needed to be successful over time. And I'm glad we although it was tough in the moment, I'm glad we sort of weathered through that because we've seen growth all around as a result of it.

59:34 Yeah, absolutely. Really quickly because we're getting short on time. Alvaro out in the audience asked, was Enum stir enum delay related to breaking Pydantic?

59:44 We can give a really quick answer. No, nothing to do whatsoever with Pydantic.

59:48 All right, cool.

59:49 Ethan has been working on a bunch of changes to the enamel module and making the REPL and stir of enums make more sense.

59:57 Oh, that's great.

59:57 And there were some changes that we weren't sure if they were going to impact users in a negative way. So we just wanted to make sure that we understood the decision and why it was made. So we asked him to revert it for 310 and then write a Pep to propose the changes just because of the scale and the impact of the changes proposed a Pep for 311, and we ended up rejecting that Pep. So that was just purely based on the change that was made and the rationale for the change. And we don't know of any actual breakage that would have happened.

01:00:31 But it's just not something that we were as simple as trying to parse the REPL and it doesn't work anymore.

01:00:37 Well, logging it and that kind of thing, you never know where those things end up.

01:00:42 Yeah, it looks like you're going to add one more thing and then I think we're getting short on time. Maybe ask you one more question.

01:00:47 Then it was just an aside. But just to show how much of a fan I am, last week on Python Bytes, you and Brian were asking with whether three point 10.1 was a security concern or not, and I was just going to say call out Pablo's. Great. Release notes. If they don't screen security, it's not a security problem.

01:01:02 All right, super. Because if I go and check like the Apple release notes for some OS updates like, oh, it contains this little thing and other possible security. You know, sometimes you don't know, right? If it's just.

01:01:14 No, we are very thorough with those guys. And when we release actually it's possible that we release extra versions when there is something very important has actually a bunch of those for the diamond. I have not been forced to do any of it, but sometimes there is CV.

01:01:33 We are very into that unless we say it's kind of okay.

01:01:38 I just want to thank everyone in the entire Python community for not writing a sub language inside of logging for Python.

01:01:48 It's funny because the logging module was definitely inspired by the Java logging module.

01:01:54 But.

01:01:56 I didn't decide to include that particular load of class thing.

01:02:02 Remote pickles, or whatever the equivalent would be.

01:02:05 Right.

01:02:06 Fantastic. All right, let's close out our conversation here, which has been great with maybe the challenges or the opportunities, whichever side of the glass fullness you want to take for the Python community that you all see. What do you see as like a big opportunity or maybe as a big thing we need to be aware of and try to work to avoid. Barry, go with you first. I guess since you're top of the video oh.

01:02:30 I'm going to steal probably the Thunder, I guess. I think the two really interesting things that are happening in Python land these days are the faster CPython work that we know this team is working on over at Microsoft. And I think the other really interesting thing is Sam Grace is no Gil work from a technical standpoint. I think we have a lot of smart people in the community. We can work through the technical parts of it. I think the really interesting thing will be the sort of the social aspects and how we make all that work and get people comfortable with those changes.

01:03:02 It's easy to make everything faster, better, stronger. But if there's compromises, all of a sudden it becomes a challenge. Yes. Thomas, you want to go next?

01:03:09 Well, I'm just going to say finding a new executive director for the Python Software Foundation is right up there for me because that may have significant impact on the long term goals of the Psf in the direction of the community and all that. At even though the Psf is very much driven by the community, it's still a big deal. However, I do realize most of the community probably doesn't care, and it's all happening behind the scenes. So I'm just going to say the Sam Gross thing is the thing that I think is the great opportunity.

01:03:39 It's going to take years to land an interpreter that doesn't have a Gil, and it's going to break a bunch of things.

01:03:45 We just need to be very deliberate and Chevrolet correctly and make sure that there's a migration path for users and as little impact as we can manage.

01:03:55 Yeah, absolutely. That's a good one, Carol.

01:03:58 Yeah. I mean, I see a really, really bright future for Python for a couple of reasons. One, our community has always embraced education and continual learning, and I think that is part of having a vibrant language.

01:04:13 After 30 years, the kids coming out of school are excited. They still get to use this. Not oh, no. Do I have to learn this now?

01:04:20 Right, exactly. And then from a standpoint of being a truly global language, where you're seeing innovation in Africa, Asia, South America, all over the world, and I think that's exciting. I'm excited to see what comes next. And I have full confidence the next steering Council will help guide us in the right direction.

01:04:44 Yes. Fantastic. Brett?

01:04:45 Yeah, this is a tough one. I feel like I've been around too long.

01:04:49 I'm just curious to see how the community continues to be the community that it is in the face of whatever this pandemic throws at us in 2022, which is hopefully nothing. But we all know that may not be we've gone a while.

01:05:01 PyCon less.

01:05:02 Yeah. Well, and even if this year is a little tricky for someone from Canada. Right. Like traveling down in the States is not quite as simple. So even if PyCon US is more US folk because it's easier for them to travel. And some of us international folk can't make it this year. It's at least good that we seem to be going that direction. But I mean, kudos to the community for keeping things going and continue to make this community feel welcome and open, even if it's been fully virtual for everything.

01:05:25 Yeah, absolutely.

01:05:26 My hope is we'll just be able to continue to find ways for the community to do that for itself and continue to feel welcoming and open and inviting regardless of the situation. And yeah, whatever that brings.

01:05:37 Yes, we'll pull through it. We will.

01:05:39 Pablo I share a lot of things that have been said. I think with the biggest challenge that we are going to face as a community as a language is that we have so many big groups of users using the language that are very passionate and have different priorities that now it was not true before, but now it's especially not true. It's not possible to make everyone happy. And decisions that make some people happy are directly hurting others. We have seen this express a lot. Like educators don't like big new things because it makes more difficult languages bigger and enterprise price a lot, but they are pushing for features that make more sense in that scale or not exclusive. So I think it's quite hard because now it's not a matter anymore of like deciding where the actual good decision is, digging for it and picking it. And it was a good decision. Not anymore.

01:06:32 Right.

01:06:32 But now you need to take decisions that are going to affect a group positively and another group negatively.

01:06:38 And that is quite important position to it's hard to know because the community is so diverse in terms of technical and application of the code and stuff.

01:06:48 And inaction is some possibility in some cases. And maybe we need to be more conservative, but some others is impossible because the language needs to evolve. Like the work that was mentioned. We cannot say.

01:07:02 We could say, yeah, we are not going to do it because it's going to break a lot and everyone is going to be doing extensions or whatever. Language needs to evolve, even grammar and implementation and community wise. It's very hard. It's impossible to make everyone happy. It's not difficult. It's impossible. And I think that's the biggest as a community. I would hope that more than we make everyone happy, we understand each other and we come to a place when there is some good vibes about these problems. I think that's going to be the biggest challenge given how big our use base.

01:07:37 Yeah, that is important. All right, everyone, we are definitely out of time. Thank you for taking all this really quickly. Finish it up with just one of the final questions. And just super quick, what editor you use?

01:07:48 Barry Emacs still Thomas Joe, which no one will have heard of.

01:07:54 I've not heard of my brother's name is Joe but I'm sure he doesn't help you.

01:07:57 I know Joe.

01:07:58 Joe is Joe's own editor and it's from the 80s and it has WordStar key bindings. If you know what words star is, which is why I use it.

01:08:06 Right on. Carol.

01:08:08 I have to say truthfully Bin VS Code PyCharm, right?

01:08:12 The gamut Brett, I could predict yours but go ahead and let us know.

01:08:16 Visual Studio right on.

01:08:18 Pablo Vim.

01:08:19 Okay, well I will join Piling and saying thank you for all the work and it's great that you all keep in Python going strong.

01:08:29 Thank you very much, Michael.

01:08:30 Yeah, thanks so much.

01:08:32 Thanks for being here.

01:08:33 Thanks, Michael. Thanks to you.

01:08:34 Bye bye.

01:08:37 This has been another episode of Talk Python to me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show. Get a job writing modern Python with a team that values software development. Apply to Research Affiliates today. Visit 'Talkpython.Fm/researchaffiliates'. Add high performance multiparty video calls to any app or website with SignalWire. Visit 'talkpython.Fm/SignalWire' and mention that you came from Talk Python me to get started and grab those free credits. Want you level up your Python. We have one of the largest catalogs 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, there's not a subscription in site. Check it out for yourself at Training. Python.Fm. Be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the itunes feed at /itunes, the GooglePlay feed at /play and the Direct rss feed at /rss on 'talkpython.fm'.

01:09:40 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.com/Youtube'. This is your host, Michael Kennedy. Thanks so much for listening, I really appreciate it. Now get out there and write some Python code.