For 30 years, Python was overseen by Guido von 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 has gone.
We have Barry Warsaw, Kara Willing, Brett Cannon, Pablo Galindo, and Thomas Waters 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 14th, 2021.
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 at Talk Python.
This episode is brought to you by Research Affiliates 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 list comprehensions, isn't it?
Check it out.
I'll put the link in the show notes.
All right.
Let's talk to the council.
Barry, Thomas, Carol, Brett, and Pablo, welcome all of you to Talk Python to Me.
Thanks, Michael.
Hey.
Thanks.
It's so good to have you on the show.
Some of you brand new.
Some of you familiar 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?
Absolutely.
Not even replace.
Just parody.
Yeah, exactly.
There you go.
Fantastic.
Well, I'm really looking forward to talking to you all about it.
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 yourselves.
You know, start at 12 o'clock.
Barry, you've been on the show before with Paul Everett talking about Python 1984.
Was it 94?
Yeah.
PyCon 9.
The workshop at NIST in 1994.
Yeah, that was the first time I got a chance to meet Guido.
Right on.
Yeah, so quick background, though, for people who didn't listen to that episode.
Yeah, 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.
Yeah, what kind of stuff are you doing on LinkedIn?
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, which is kind of a fun project at times.
Yeah.
I bet it is.
That sounds awesome.
Yeah.
Cool.
Thomas, welcome.
Thank you.
I'm from Amsterdam in the Netherlands.
I've worked on Python since, I think, 2000.
I became a core developer in 2001, so I've been around for quite a while.
Ned Batchelder, who wrote coverage, likes to call me the most famous Python person 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.
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.
So you have basically four jobs.
You're a busy person.
Yes.
My dad made a lot of fun of me last week when I told him this.
He has two full-time jobs, and he said I do more work than he does.
Sounds like you're busy.
Being from Amsterdam, are you happy the F1 championship is now on there?
I heard fireworks yesterday, but I wasn't actually paying attention because I haven't watched the Formula One for many, many years.
Yeah, right on.
Well, it's another thing to celebrate over there.
Carol, welcome.
Thanks, Michael.
It's always a pleasure to see you.
Yes, you as well.
Happy to have you here.
Much better circumstances.
I think the last time I was on, Brett and I were here right after Guido had resigned.
Yeah, to basically explain, what was that, to discuss the possibilities that were being considered for what has now become the Steering Council?
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 re-election.
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.
Yeah, that sounds really fun.
Awesome.
So you don't have any worry about re-election.
You can just vote however you want.
You're unencumbered.
I'm unencumbered, and it's a great slate of people, so I'm really, really pleased at how things have evolved over time.
And obviously, these fine folks would be wonderful to be re-elected, but there's also a great group of folks on the slate as well.
So I think we're in good shape.
Yeah, fantastic.
Brett, welcome back.
Thank you very much.
Background.
So I'm calling from Vancouver on the unceded traditional lands of the Musqueam, Squamish, and Sailor Truth First Nations.
I'll be right up front on that.
I have been on the steering council since it started.
And as for a day job, I am constantly trying to convince Michael to try out VS Code for Python as the manager for the Python extension of VS Code.
Yeah, yeah.
No, good work.
I mean, I've not seen a tool take off with such broad support.
You know, I always ask the question at the end of the show, like, 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.
It's awesome.
Oh, yes.
I'm very proud of the team.
They've done a great job.
Yeah.
And you also now live on an island, right?
Didn't those storms, like, separate all the roads from the rest of Canada?
Yeah.
You guys doing all right?
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 in the Pacific Northwest.
So it's a thing.
No rail lines either.
The port's completely backed up and we're, like, the third largest in North America here in Vancouver.
So, like, I went to the grocery store yesterday.
The shelves were pretty bare due to just logistical issues.
I mean, 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.
And, like, half of all the dairy and all the chickens for the province come through there.
There's been a lot of, unfortunately, a lot of animals that drowned.
It's really bad.
We'll get through it, unfortunately.
I'm glad you're okay.
That was quite the thing.
Pablo's on a higher note.
Hello.
Hopefully.
Welcome.
I'm Pablo Galindo.
I've been on the steering council for only this 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 slash news company in the Python infrastructure team.
So, we do a very similar thing, as Thomas' team do, but slightly different, I will say, because we need to support all these, not as exciting old systems that banks like to use and whatnot.
But we also, like, do a lot of, like, very cool tools, like, you know, the baggers and profilers that we plan to open source soonish.
And we also make sure that Python experience at the company is the better we can.
So, we are in the VEX kind of department after the seventh reorg or something.
So, now we are supposed, like, to take care of that people are happy and whatnot.
And, yeah, people use a lot of VS Code, apparently, as well.
So, I bet they do.
Fantastic.
I was just recommending the running Microwizgi in production article from the Bloomberg tech engineering.
Oh, right, right.
That's Peter Sperl, I think, is the author.
Like, he, yeah.
Yeah, just last week or something.
That's a really, really neat stuff you guys are doing there.
Right, right, right.
And, yeah, and I think the only, in Cpython, 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.
Yeah, a lot of improvement on the error messages and tracebacks and things like that, right?
Yeah.
People have been more excited than you would expect.
Really?
When you described that.
I've heard people are like, this is so exciting.
I can't wait to start using this feature.
Yeah, well, we finished the new parser and it's like, well, we can do it this.
That is not only, like, more syntax because, like, you know, like, people are like, oh, now we have, like, all this syntax, right?
Like, that's not good.
So, I said, okay, let's make something good so people don't demonize the parser.
So, you know, like, they say, oh, well, the messages are good.
So, let's leave the parser alone, right?
Exactly.
Yeah, well, nice work.
You're also the release manager, Pablo.
Right, right.
Sorry.
Thanks, thanks.
It's a small thing.
Thanks, buddy.
Yeah.
Yeah, and also the release manager for Python 3.10 and 3.11, which is going to be released this year, late this year.
And, yeah, apparently it's been a very cool release, three times.
So, let's hope that.
Yeah.
I've not noticed any problems and it just rolled out nice and smooth.
Yeah, that's a good sign because it's not that there hasn't been any problems.
But only on the release side.
Once it's released, it's good and well, right?
I mean, I'm also able to do because I have a good team of release managers, all release managers helping me.
So, thanks.
Thanks to all of them.
Yeah, fantastic.
Well, let's just get started with some definitions.
Maybe, Carol, you could also just tell us a little bit of history since you were on the show as well.
Like, what is the steering council and then, you know, where did it come from?
Yeah.
This is a relatively new thing for Python.
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 model was the one that won 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.
You know, 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.
Well, I would say you all have done a great job because I haven't heard anything very much.
You know, it's in the sense that Python is still being released.
Features are still being added to the language.
Maintenance is still being done.
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.
Yeah, the entire Python ecosystem, yourself and others, for really rallying around and trying to make everything work.
And I can't underestimate Eva's 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 that we've seen the same.
Well, when you're, you know, in the eye of the hurricane, it feels different.
Yeah, totally.
Yeah, 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?
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.
It was, 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, I will say, 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.
Yeah.
I think the thing I'll add is that, you know, over the years, like there was a lot that was sort of underspecified in the steering council spec.
And every year we sort of figure out like what the right rhythm of business is, you know, how often we're going to meet, what kinds of agenda we're going to, you know, take on.
That's been really great.
You know, 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.
Yeah. And there are other organizations sort of playing in that space.
We have the core developers, right?
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 this all fit together?
So I think PEP 13 does a reasonable job explaining this.
The idea is that Hito wasn't, 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.
The benevolent delegator?
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.
So the core developers are the people with commit bit rights in the GitHub repo.
That's basically it.
It's the people who've contributed a lot to Python of 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.
It's still 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.
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?
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, you know, 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.
Sure.
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 in residence.
That is to say that the steering council hired the PSF employee that is Lukash, the developer in residence.
So there is a lot of interaction as well.
But it's mostly the steering council using the Python software foundation, I would say.
This portion of Talk Python to me is sponsored by Research Affiliates.
If you're a regular listener to the podcast, then you're passionate about Python and looking for ways to grow your skills.
But are you toiling 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/research affiliates or just click the link in your podcast player show notes.
Carol, it looked like you were going to add something.
Yeah, I was just going to say in terms of like the 60-40 decisions, there's been very few of those.
Part of the reason is there isn't consensus.
What we do is work like, for example, pattern matching was one where we asked the PEP 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.
Right.
I think that's an important thing to remember.
Yeah, it helps that all of you are on the technical side of things, right?
As opposed to overseeing this or whatever, right?
It really helps that you can get in there and say, no, no, no, this is going to have performance implications or this is going to have break and changes or whatever.
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.
Yeah.
Carol, you come at it from the science, the data science, scientific side a little bit more.
And Brett comes at it from the editor side.
No, just kidding, Brett.
Fantastic.
When are the elections and then how long do you serve for?
The elections are right now.
They close, I think, on Wednesday, the 15th of December, anywhere on earth.
Or is it Tuesday, anywhere on earth?
It's sometime around there.
I think it's Wednesday or something.
Yeah.
And they've been going for the last two weeks.
The way it works is when the major Python version is released, so 3.10 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 re-elected 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.
And so 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 re-election, decided not to go for re-election.
The rest of us is.
We have no idea if we're in the running or not.
I mean, 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.
Yeah.
Do you think it would make sense to have one person stay around as sort of some continuity?
Or it probably is going to happen just statistically, right?
I guess we've talked about it.
I mean, that's sort of the nice thing, right?
It's like we adjust.
Things aren't necessarily set in stone.
So for example, when the first steering council was elected, right?
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 releases.
It seems to be working okay.
And if it doesn't, then we'll have a discussion about that as a community and propose changes.
But so far, so good, right?
Yeah.
Yeah, absolutely.
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 Eva's 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 has been in multiple steering
councils and can transfer over things.
Yeah.
And that would give the PSF a seat at the table as well.
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, we 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,
you know, discuss any running issues, anything that the new steering council needs to know.
So it's not, even if five new people get elected, it's not that we're just throwing them out,
you know, 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.
Yeah, true.
You're all still core developers.
They could still reach out to you and ask how about something.
I want to talk about two people really quick while we're, 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 10 years or
something like that, right?
10 years as the secretary or director of operations or executive director of the PSF.
She was involved in organizing, or she was organizing PyCon before then.
So she's involved in PyCon even longer than that.
Yeah.
And for those who are not watching the live stream, pretty much the whole story cancel
just did a little silent applause.
So we all miss her dearly.
It's only been a week.
Yeah, absolutely.
Best of luck to whatever she's off to do next.
Also, Betsy.
Betsy did a lot as well.
And, you know, thanks.
She's also moved on.
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.
We owe her a lot.
Especially PyCon.
It seemed like she did a lot there.
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.
Yeah.
All right.
With serious thanks.
I do want to show something I think you all will be amused by.
I don't know if you have you all seen this, this Twitter thread here?
Yes.
There was a great mention by Patrick Mason saying, hey, the PSF, the at, you know, thus,
basic, at PSF on Twitter is searching for an executive director.
Here's the job announcement.
Has this been filled yet?
We're still looking for it.
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, you know, interviews to have.
We're in the process of interviewing a whole bunch of people via the search committee.
Okay.
Is it still open for applicants or is it kind of, you have tons and now you're going through
them?
I think 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.
Yeah.
Great.
If people want to apply.
Absolutely.
Cool.
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, that was a good way to respond to it there.
Yeah.
That was a lot of, but yeah, 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 PSF.
So I thought that was extra funny.
Yeah, that is really funny.
Nice and lighthearted.
Now, I also want to ask about the developer in residence and how has Lucas's 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?
Yeah, I think, I mean, 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, you know, 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 on a lot of work.
is extremely difficult because, you know, like we have a lot of peers and I think he
has already been on the show before, right?
Yeah, we actually, I interviewed him about specifically about that role.
We probably defer listeners to that particular episode.
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 to say in
some good way.
Is it harder to do a major release, like a 3.9 to 3.10?
Like 3.10.0?
Is that harder than 3.10?
Oh yeah, absolutely.
Yeah.
There is two moments that are especially bad.
One of them is the first beta release because what happens is that on the first beta release
kind of is the point when no new features can be added.
And technically from that point until the final release, it's only back fixes and things like
that.
Although people try to stretch the definition of a bug fix quite a lot because there has
always been the strategy of like, I can push maybe this feature like half-baked and then
call it a bug.
And then it's like, oh, I'm doing a bug fix, right?
So, you know, that's when the role of the release manager, you know, is quite important because
you need to, I mean, you need to be human.
So sometimes it's like, you know, like people have, you know, they are contributing on their
free time.
So, you know, maybe they tell you, I don't really have time for this, but like, you know,
blah, blah.
So, you know, there is always time for discussions.
But also like you need to be careful with that.
And the other problem that happens is actually, you know, because it's a deadline, everybody
pushes everything on the last day.
Like, it's like incredible amount of activity.
And some of the, you know, 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, five
hours and I will have to run every unit test for the entire CPython suite and things.
It's kind of, we have like a big CI that tests us on like my Windows, macOS and Linux.
But then we have like this thing called bill bots that basically machines that are donated
or that we run that test us on like flavors of these platforms or different distributions
and different versions of macOS, but also like it runs like heavier checks, like sanitizers,
checks for reference leaks.
So it's these things like that take, like if you put that thing on the CI, everybody will
help you, like in the sense that it would be ridiculous.
So we have these things and they only, they not don't run on a single commit, they run on
batches.
So basically all commits of the day.
And then if it fails, you know, you need to do some manual bisection.
But anyway, what happens is that, you know, because everybody pushes that and then you
need to do the 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 like extremely, extremely broken.
So normally up to this point, it was kind of, it was a bit weird because like technically
people are, you know, responsible for the things that they break or they push broken.
But at the end of the day, it's kind of like, it's the release manager that finds people to
fix it.
I fixed myself a lot of these things.
And it's very stressful because, you know, like people are waiting for your release and
it's a quite important release to start testing.
And, you know, like the redistributors are waiting for you because they, they have their
calendars.
And those nights have been extremely stressful for sure.
I mean, and then three times has been as well, but like the, with the help of Guk, exactly.
We've been coordinating with this.
And if not, like for instance, last time we've been like fixing between the two of us, all
these little things.
Sometimes you need to revert the thing because, you know, it's like, it's so broken that we
don't have the time to like find out what's going on or like too risky to think like, you
know, maybe it's fixed, but who knows?
So, you know, sometimes we just revert.
That would be a bummer if your PR failed through CI and you got to wait a year.
Before it was two years.
And, you know, like people don't get happy when, when you push them back your feature.
It was a year and a half.
Yeah, actually.
Almost.
Right.
But still, it's quite a long time.
Like, especially if you miss the line because, you know, like.
Well, don't put things off until the last day.
Come on.
Yeah.
People don't understand that thing as well as you would think.
Thomas.
Yeah.
Thomas, you can say this.
And then there's the reality of human behavior.
Yeah.
I know.
You know, like people get quite angry.
But it's good advice.
But in a good way.
I mean, it's not like, you know, they, they, we are all friends here in the court.
And, you know, like it's, it's important to have, I think one of the important parts of
being a release manager is that you need to have a good kind of communication skills because
it's not only about like the technical part.
It's also like communicating.
And I think like Lucas in this case has been also doing a very good job.
He, he communicates quite well and especially in tricky situations.
And I think that that is an asset of the, of the position.
Like, you know, you need to interact with a lot of different people in the team.
Like people, sometimes they say, oh, you're paid for this.
So here's all my land release.
And, you know, like you need to also tell them like, no, I mean, we have these priorities
and whatnot.
But yeah.
So, so this has been an area where he has been helping a lot doing releases.
He's still doing releases himself, right?
Because three nine dot whatever we are now still have it.
So release manager is kind of a long, it's a long serving.
This portion of Talk Python to Me is brought to you by SignalWire.
Let's kick this off with a question.
Do you need to add multi-party 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 SDKs 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 browser-based 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.
SignalWire comes from the team behind FreeSwitch, 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 to receive an extra 5,000 video minutes.
That's talkpython.fm/signalwire.
And mention Talk Python to me for all those credits.
We need to actually find the next release manager for...
It's a big commitment.
Right.
This is about the time that we try to find...
How do you do that, Barry?
We have a group of former release managers.
We throw around some names and then we find somebody to, I guess, convince.
They look for someone to volunteer.
Yeah, volunteer.
Yeah, exactly.
Exactly.
So we have like a long chain with a big ball at the end.
It's just a finance amount.
We got this present for you.
This is going to be real company.
No one will ever approach Benjamin Peterson's tour duty.
Man, that was a bad deal.
That was a bad deal.
Yeah, yeah, yeah.
Yeah, he was the two-sector release manager.
Yeah, yeah.
He did not sign up for 10 years of bug fix releases.
It's also like people underestimate the work of releasing an operative system.
Sorry, that is a primary language.
Yeah, I cannot imagine releasing a Linux kernel version.
But like it's a multi-hour process.
It's quite a lot.
And, you know, like there is always when people say,
oh, can't you automate this thing with GitHub actions?
And it's like, oh, come on.
I mean, good luck.
We have already like a huge amount of automation,
but there is a lot of processes that are manual.
Like it's ridiculous.
Or there is so many ways it can fail and you need manual intervention.
The automating is, I mean, I have something already that for minor release,
like sort of alpha releases and whatnot,
which are a bit like, you know, you don't need to build documentation or whatnot.
It's almost automatic, even waiting for humans to do things.
But for big ones like betas and final releases,
it's like five hours of you sitting down.
Yeah, and, you know, there's a lot of problems that happen on the go,
so it's impossible to do it.
Pablo has also live streamed all this.
So if you really want to see all the effort that goes into it,
you can, including watching him.
If you go back, watch the ones where he breaks GitHub.
So there's a lot that goes on in those rooms.
Yeah, that's right.
I think I saw you guys all sitting down and live streaming on YouTube.
Yeah, that was a 3.10.
It was just Pablo and Rukas and the other managers.
Not the steering council, just to make sure the rest of the steering council stays away with him from all that.
We know too well.
You know too well.
Fantastic.
I did want to bring it a little bit back to Lukas's 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, you know, 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 Lukas.
You know, 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.
Lukas has been focusing a little bit on selling the position as well because he was very aware from the start that, you know, 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, is to showcase the work and all that.
Yeah, he's very much out in the open about that, right?
He does his sort of weekly blog and summary of almost the report you would give to a manager, but his managers are the community.
And so it just published that, right?
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.
Yeah.
And it's also the context switching, right?
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, you know, going through the issues and going through stuff.
And he can do that full time, right?
Yeah.
Well, he has a full time to spend on all of those things.
So he's still context switching a lot.
Sure.
But the context is more tightly grouped.
Yeah.
Yes.
Yeah.
And I think it gives you, it gives the language a continuity and sustainability.
You know, people are going to have to onboard and offboard.
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.
Yeah, absolutely.
How involved or if at all were you, was the steering council in getting a move to GitHub?
Like the repo or the issues?
Yeah, the repo, not the issues.
I know the issues are still coming, right?
They're not there yet, are they?
Yeah.
Working on that still.
Yeah.
But the initial get the code over there, get the merging.
I think the steering council didn't exist.
Yeah.
I was trying to think about the time.
It just preceded that, didn't it?
Yeah.
I mean, Brett actually was very involved into that, if I recall correctly.
But I think what that was.
Yeah.
Brett's been involved in every change to our version control system, probably since the
CVS days.
I was going to make a joke about CVS.
Come on.
Yeah.
I don't think I was not involved with CVS to subversion, but everything subsequently I've
somehow been involved with.
Yeah.
So how are you happy to see it on GitHub now, Brett?
Since I'm the one that made that happen, yes.
Well, I mean, you could regret it.
No, I would think so.
No, it seems like it's gone well.
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.
Yeah.
You completely changed their workflow, right?
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 dev guard of how to Git for
Mercurial 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'll be a bit more of a connection between the PRs and the issues.
Yeah, that'd be great.
And we don't want to maintain our own infrastructure anymore, which has always been somewhat of a
burden.
4E has been having to keep bugs.python.org running this whole time.
He's got everything else on his plate that always has 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's donations to make sure that
this happens and coordinating all that money and all that hiring.
And so we're able to have, let's say, it was a core dev work on this.
And we've been kind of project managing it towards the end on this to get over the fish
line, but looking good.
And the goal now is hopefully January sometime we'll be flipping the switch and moving over.
Yeah.
Well, that's coming up quick.
Yep.
Yeah.
I think that's sort of like, you know, an underappreciated perhaps contribution to Python,
right?
It's like Marietta has done an amazing amount of work and Brett's done a lot of this as well
as to make those kind of like GitHub 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.
It's not more important for making the whole experience of developing Python really smooth
and easy to do.
Yeah.
I think also kind of nowadays there is more and more people are conscious of this, but
I think there is also like a special emphasis on like when you contribute this code, right?
Like, like, and then even like people feel that or they have been like doing documentation
contributions or even like CI contributions or whatever.
like, and they say like, Oh, I didn't continue to see Python.
I mean, come on.
Like, you know, it's important for, for us to highlight this.
And, you know, there is a lot of, even code developers, there is a lot of code developers
that don't continue code.
Like even just, you know, try adding and all those things that those are as important or
even more.
Like, you know, code is, is not a small part, but it's also by far not the full picture.
Right.
Like, even if you take Guka's work, right?
Like he's not coding that much as the developer in racing.
I mean, he does some coding, right?
But like, and that you see the impact that he's having, right?
Like literally we are, we are searching for someone who, who does that kind of work because
he's needed.
No, we are not searching for an excellent coder, right?
Like we already have a lot of those.
So, you know, like, I think it's important to highlight and I would like to take the time
to say here that, that when, when people think about contributing, you know, you don't
need to think about code.
Right.
You don't have to master pointers to pointers, you know, void pointers.
You know, there is a lot of, there's a lot of ways to contribute.
Yeah.
And you know, there is a lot of people that go and it's always the same thing, right?
I mentor, I'm spending a lot of time mentoring new core developers, like the last four core
developers were people that I helped mentoring myself or partially.
And, you know, it always happens.
I mean, I've been also very lucky and like the last core developers that I've been mentoring
has been like 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.
It's like, how do I find issues that I can work on, right?
Or PRs, which is the most difficult thing to solve because it's not only like, what do you
like?
And, you know, what are your skills or interests?
But, you know, it's also like C-Python is a fairly mature code.
So it's not that easy as like, oh, there is this thing, you know, I pick it up.
But the key here is that a lot of people don't think about the fact that, you know, you don't
need to think out like, because they think bugs, like what is the bug or what is the feature,
you know, like that I cannot.
A lot of the time what happens is that the easier parts are actually for even for them,
right?
I mean, maybe there is a programmer that really likes coding and, you know, it's very easy
to say.
It's like work on this or do I packaging work on that.
But like a lot of people actually, you know, 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.
It's because we are already, we are thinking like core developers.
So we are like, okay, yeah, I think I know how, I know the system.
So I'm documenting this as I think, you know, and for someone who is new to the system.
Yeah.
It's hard to see with new eyes.
Yeah.
Or like from the user perspective, like maybe we put a lot
of detail that is not that important and, you know, makes the more difficult, or maybe
we are missing some things that we think is implementation detail, but there's other is
not.
So, you know, that is quite important.
And I mean, happy to see that more and more people are like working on this kind of things
and those contributions are super important, right?
Maybe, maybe that's where you can have a huge amount of impact, right?
Like instead of fixing bugs, I mean, fixing bugs is also important, but I think my first
PR in the, in CPython was in the documentation.
I'm super proud of it.
Like this actually Marietta was the person who merged it.
Interesting.
Yeah.
That's fantastic.
I think it's important to mention that.
And, you know, more and more people now are helping with things like CI because like, you
know, they, they are super knowledgeable about like GitHub actions and they say, oh, actually,
you know, like this is very inefficient.
Maybe you can do this and blah, blah, blah.
Or like, maybe you do this, you can have in the PRs kind of comments from the compiler
warnings.
That's something that someone could do.
And I mean, that is fantastic.
It's like how many bugs are going to be solved just because, you know, like for us, for even
for Google as I myself, like helps a lot because we don't need to, when we see the warnings,
we don't need to fix it ourselves because like, it's there.
Right.
So, so those changes are actually more long lasting or even documentation.
Like, yeah.
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?
Like we put in more details into the string as part of the error.
That's, that's way more doable.
Right.
That kind of stuff as well.
And I will, and that's the last thing I want to say.
Yeah.
And I would example as well is, you think, oh, is the last, the, the better errors thing.
I mean, there is a lot of like technical stuff there, but like one thing that happened is
that now a lot of contributors are actually contributing the errors themselves.
Like not, not, I mean, there's some part of the government would not, but like, it's not
focused on code or like fixing or adding infrastructure is because like, they like, you know, to have
better errors and they're, they are very passionate about it.
And that is fantastic because you know, it's not, it's, it's also a different area when
it can have a, but you were saying that apparently like people are super happy about that.
And, you know, I've been contributing in very core parts of CPython and I would never have
thought that this was something that is going to be so, so much accepted.
Yeah.
But if, 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, that helps a lot of things, you know, go more smoothly.
So Brett, I'll, I'll throw this question out to you first here.
What are some of the big during the tenure of this group?
So this year, basically, what were some of the big or hard things that you had to decide
upon?
Oh, wow.
Right.
Hard things to decide about.
Well, honestly, if we're going to be honest, anything conduct related is always hard.
Stuff comes up and as the final deciders, as it were, or the great deciders for the core
team, sometimes conduct stuff comes up.
Out in the audience, PyLink refers to you all as the dream team.
So.
Thanks for that.
But yeah, conduct is always the hardest.
We don't like it.
No one likes it.
It's tough.
We were very lucky that the PSF conduct working group backs us.
I'll disclaimer, I'm on it as well.
But I also recuse myself whenever Python core stuff comes up.
But it's, we're really going to have them to help us give guidance because that's what
the kind of work groups there for is actually to provide guidance that 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.
I mean, we've been on this team long enough that we pretty much know everybody.
Right.
And 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 the conduct work group to help kind of act as the independent body that doesn't
have all that baggage as it were with people.
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 that's hard every time.
It's not fun.
It's stressful as heck.
If it's ever reached that point, it's not great.
Yeah.
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, you know,
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?
Like we enjoy that even though it's hard, it's still a fun part of the job.
So hopefully there'll be more days and fewer of the fun and not or not fun and hard.
Yeah.
Probably the closest I can think of off the top of my head was deciding for 310 not to make
from Dunderfuture import annotations.
That was a really tough one because...
That 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, 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.
Yeah.
Pydantic and FastAPI were two of the most popular.
Exactly.
And stuff has just changed since that PEP got accepted way back when.
I think even that was...
I don't think that was even steering council decision.
I think that was a Guido decision.
No, no, no.
It was a Guido delegated to Ukash decision.
Right.
So that was a bit stressful because it all happened right before beta, right?
And it was a lot of...
It was people reaching out to people.
There was a bit of panic in some corners of the community.
There was...
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 of the type...
All sides of the typing 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 work.
Because that was a messy back...
Next time I can dump that on Ukash.
There you go.
Exactly.
Yeah.
Because this was pre-Dev in Residence, right?
Yeah.
Deal with this.
But it was tough.
It was...
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 Strength Council has 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've asked the community to see if anyone wanted to step forward to actually talk with
all areas of the typing world to see like the PEP 649, which Larry Hastings has proposed
as a solution to the problem of runtime types and binding and all this lot of stuff.
We've asked the community, can someone step forward and kind of act as almost a champion
of a shepherd or an expert to come talk to us to explain like, have we hit all of the
potential issues with the Gender Futures import annotations or PEP 649's proposal or something
else?
And honestly, no one stepped forward.
So this is actually one of those things where the Strength Council might actually in 2022
have to come forward and 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'll take time.
But that's what we're here for is if we ask the community to do something and no one
wants to do it, we're the backstop to make sure stuff still happens and works.
Yeah, 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?
Yeah.
So the from Gender Futures import annotations, what it did was is it made all type annotation
strings, which for performance reasons and forward reference problems is really handy, right?
Like there's no overhead in 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.
Right.
A class method that returns its own self.
So you would just put that in quotes instead of say it's not me.
Yeah.
Or class A has an attribute of class B and class B has got reference A and it takes care of all that.
Cause it's just strings.
There's, there's nothing to really do there.
And then the type checkers just handle the, like the references.
It's not a problem.
The problem is, is projects like Pydantic, which various other projects like Pydantic depend on that messes them up because they need to actually convert those strings back to the original objects that they represent.
Right.
Cause they want the rich type information out of that.
They need to see the real type.
They want the actual object that that type annotation defines, right?
When you do like list bracket int, right?
They want that actual object that that represents so they can get at that information.
Oh, okay.
This is type to a list events, not just, oh, it's a string.
I don't know what the heck that is.
And there's a function in the standard library that you can call in the inspect and typing module that will, 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, is you still have this reference problem and a couple other things and it's not worked perfectly.
And that's why the dynamic typing side, the live typing side, as it were, the typing community got really worried when they realized this was about to become the permanent thing.
And why we stopped now there is a PEP 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 and 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, 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 send to future import annotations 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 this is potentially messy.
And it doesn't have to fix everything, but anything that it doesn't fix probably will never get fixed.
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.
I think the second aspect is the key.
I think it's probably what is making this so difficult that we already have future input.
And we don't want three of them or a combination of them or whatnot.
So I think it's important.
And this is the most difficult thing for us because, you know, as a student council, we like reviewing peps is extremely time consuming and whatnot because you need to not only be aware of the change itself, but also like what the documents are written by the authors, right?
And then you need to, I mean, it's not like that is ill intention or anything, but there is a lot of things that maybe are left out or like, so you need to make, make sense of the void that is behind these things.
Right.
Or like what is the far reaching effects.
And in this case, the problem is that how many other things don't we know that is not going to work?
Because, you know, like now we, like you see, we knew all these use cases days before beta, but like what else about all the people that are not contacting?
Yeah.
Right.
And one thing I want to say as well is because this is important.
Like we, we care about like, you know, the antique and FastAPI, but we care about everything else.
Right.
It's not, you don't need to be the author of a big framework to have the steam council attention.
And that's quite important.
Yeah.
I think it's important to remind, right.
Because, you know, it's important because there is a lot of people using this use case and therefore, you know, it has more weight.
That's true.
Just because, you know, if we mess up, it's going to affect more people than some random library.
So the random library is also as important as long as it's using, you know, the, the interfaces that we provide in its own right.
Right.
And this is important to know because like maybe there is a community of people that use type annotations for, I don't know, database tables or who knows.
Yeah.
And then they didn't follow out contacting the steam council or the Python dev or whatever.
So, you know, it's important if you're listening to this and then you're an author of libraries that use type annotations or even a user that uses type annotations in non-standard ways.
It's very important to reach to us and maybe in the future to this person, we're going to lead this effort because we absolutely need to know what these peps are not going to fix.
So we say as a steam council, okay, we take the, or the next steam council, right.
We take the informed decision to accept this pep, 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 lifting it out because what we cannot have is now, you know, this situation again, because just we miss.
You only get so many readers.
Carol?
Right.
Yeah.
I mean, there's so many different communication levels on this whole thing.
I mean, as you know, Michael, from doing all your courses, a 30 year old language that has many different use cases.
It's hard to sort of one size fits all.
Oh, yeah.
Yeah.
And I think, you know, I reached out to Sebastian and Samuel because we had been using FastAPI with great success and our engineers really loved it.
And I think it is something that, you know, is re-energizing the whole web-based side of Python.
So you don't want to sort of cut that off at its knees.
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.
Right. But by the same token, you know, it also, as a library writer, you know, with JupyterHub 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 Lukash's proactive, you know, 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, you know, 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.
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?
We can give a really, really quick answer.
No, had nothing to do whatsoever with Pydantic.
All right, cool.
Ethan's been working on a bunch of changes to the enum module and making the repper and stir of enums make more sense.
Oh, that's great.
And there were some changes that we weren't sure if they were going to impact users in a negative way.
But 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.
Propose 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, but it's just not something that we were.
Someone's trying to parse the repper and it doesn't work anymore or something.
Well, logging it and that kind of thing.
You never know where those things end up.
Yeah.
Brett, it looks like you were going to add one more thing.
And then I think we're getting short on time.
Maybe I'll ask you one more question then.
It was just an aside, but just to share how much of a fan I am.
Last week on Python Bytes, you and Brian were asking whether 3.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.
All right, super.
Because if I go and check the Apple release notes for some OS updates, it's like, oh, it contains this little thing and other possible security.
You never, sometimes you don't know, right?
If it's just...
No, we are very thorough with those notes.
And when we release, actually, it's possible that we release extra versions when there is something very important.
I think I have actually a bunch of those.
For that, I mean, I have not been forced to do any of this, but sometimes, you know, there is CVs and whatnot.
We are very into that.
So, yeah.
Unless we say it, it's kind of okay.
Well, I just want to thank everyone in the entire Python community for not writing a sub language inside of logging for Python.
It's funny because the logging module was definitely inspired by the Java logging module, but...
Yeah, you can tell why the names.
You know, I didn't decide to include, you know, that particular load of class path thing.
Remote pickles or whatever the equivalent would be.
Right, right.
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.
Like, 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, 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 Guido and his team is working on over at Microsoft.
And I think the other really interesting thing is Sam Grace's no-kill work.
From a technical standpoint, I think, you know, 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.
It's easy to make everything faster, better, stronger.
But if there's compromises, all of a sudden it becomes a challenge.
Yeah.
Thomas, you want to go next?
Well, I'm just going to say finding a new executive director for the Python Self-Ware Foundation is right up there for me.
Yeah.
Because that may have significant impact on the long-term goals of the PSF and the direction of the community and all that.
And even though the PSF is very much driven by the community, it's still, you know, 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.
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.
And we just need to be very deliberate and shiver that correctly and make sure that there's a migration path for users and as little impact as we can manage.
Yeah, absolutely.
That's a good one.
Carol?
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 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, right?
Exactly.
And then from a standpoint of being a truly global language,
where you're seeing innovation in Africa, Asia, South America, you know, all over the world.
And I think that's exciting.
You know, 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.
Yeah, fantastic.
Brett?
Yeah, this is a tough one.
I feel like I've been around too long.
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 that may not be.
We've gone a while, PyCon less.
Yeah, well, and even if this year is a little tricky for like someone from Canada, right?
Like traveling down to 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're at least seemingly going that direction.
But I mean, kudos to the community for keeping things going and continuing to make this community feel welcoming and open, even if it's been fully virtual for everything.
So yeah, absolutely.
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.
Yeah.
We'll pull through it.
We will.
Pablo?
I think, I mean, I share a lot of the things that have been said, but I think my, I think with the biggest challenges that we are going to face as a community, as a language is that we are like, we have so many big groups of users that are using the language that have, you know, are very passionate.
I 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.
And we have seen this express a lot, right?
You know, educators don't like big new things because, you know, it makes more difficult and language is bigger and whatnot.
Well, you know, enterprise Python, let's call that a lot.
But like, you know, 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 and like, you know, digging for it and picking it and, you know, this was a good decision.
Not anymore.
Right.
But now you need to take decisions that are going to affect a group positively and another group negatively.
And that is a quite important position to be into.
It's hard to know because the community is so diverse in terms of technical and application of the code and stuff.
Exactly.
And in action is some possibility in some cases.
And maybe we need to be more, you know, more conservative.
But in some others, it's impossible because, you know, the language needs to evolve.
Like the GIL work that was mentioned, we cannot say, I mean, we could say, yeah, we are not going to do it because, you know, it's going to break a lot.
And, you know, everyone is going to be doing part of the C extensions or whatever.
I mean, the language needs to evolve, right?
Like even grammar and, you know, implementations and, you know, community-wise.
And, you know, it's very hard.
It's very hard and it's impossible to make everyone happy.
Like, it's not difficult.
It's impossible.
And I think that's the biggest.
As a community, I will hope that, you know, more than we make everyone happy,
we understand each other and, you know, 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 is.
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 we'll just super quick.
What editor used, Barry?
Emacs, still.
Thomas?
Joe, which no one will have heard of.
I have not heard of.
My brother's name is Joe, but I'm sure he doesn't help you.
I know Joe.
Joe is Joe's own editor and it's from like the 80s.
And it has WordStar key bindings, if you know what WordStar is, which is why I use it.
Right on.
Carol?
I have to say, truthfully, Vim, VS Code, PyCharm.
Right.
The gamut.
Brett, I could predict yours, but go ahead and let us know.
Visual Studio.
Right on.
Pablo?
Vim.
Okay.
Well, I will join Pylang in saying thank you for all the work.
And it's great to be all keeping Python going strong.
Thank you very much.
Thank you, Michael.
Thank you.
Yeah.
Thanks so much.
Yeah.
Thanks for being here.
Thanks, Michael.
Thanks to you.
Bye.
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/research affiliates.
Add high-performance, multi-party video calls to any app or website with SignalWire.
Visit talkpython.fm/signalwire and mention that you came from Talk Python to me to get started
and grab those free credits.
Want to 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 sight.
Check it out for yourself at training.talkpython.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 Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
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.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Bye.
you
Thank you.