The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try out a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode. With the launch of their managed Kubernetes   next generation of deployment and scaling, powered by the battle tested Linode platform, including simple pricing, node   balancers,   40 gigabit networking,   dedicated CPU and GPU instances, and worldwide data centers. Go to python podcast.com/linode   today. That's l   inode,   and get a $60 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show. You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis.  

For more opportunities to stay up to date, gain new skills, and learn from your peers, there are a growing number of virtual events that you can attend from the comfort and safety of your own home. Go to python podcast.com/conferences   to check out the upcoming events being offered by our partners and get registered today. Your host as usual is Tobias Macy. And today, I'm interviewing the fluffle, Barry Warsaw, about his role in the Python community past, present, and future. So, Barry, can you start by introducing yourself? Hello, everybody. I'm I'm Barry Warsaw.  

[00:01:28] Unknown:

I've been a core developer since,   1994.   So I've been involved in Python for quite a long time. Currently serve on the steering Python steering council, my second term,   and  

[00:01:42] Unknown:

I, I work at LinkedIn. Looking at the acronym for steering council or 1 letter off from the Python secret underground, which emphatically does not exist.   Exactly.  

[00:01:53] Unknown:

I'll just point out that, you know, Python, of course, is named after Monty Python. So humor has always been, you know, an integral part of, the Python community.  

[00:02:01] Unknown:

Absolutely.   So you shared this story a little bit in the interview that you were on a few years ago now talking about the overall Python enhancement proposal process.   But for anybody who hasn't listened to that, can you just give a bit of the background of how you got introduced to Python?  

[00:02:17] Unknown:

Sure.   So,   actually, it was interesting because,   I I I don't know how many people remember Usenet, but Usenet was a big thing. It was like a kind of a bulletin board form   system that people used.   And complang Python showed up 1 time, And I was kind of into programming languages, so I checked it out, and it was nothing but Monty Python jokes. So I thought, well, this is great, but, like, what is it doing in complang? Right? Like, what does it have to do with, you know, programming languages? So I kind of set it aside, and then a few months later, some friends of mine at the National Institute of Standards and Technology, which I had worked at, you know, up until about 1990,   sent me an email and said, hey. We've got this guy coming over, and he's gonna give a 3 day workshop.  

And would you like to attend? And it was, you know, local to where I was living. So I had just started at the Corporation For National Research Initiatives.   And so myself and 1 of my colleagues went up, and we attended the 1st Python workshop in November of 1994.   And I got to meet Guido, and I got to see   how the language was being developed, and I just kinda fell in love with both. I mean, Python, the language, I had sort of dabbled in it before the workshop and and gotten some initial impressions   and really loved the language. And once I met Guido, you know, he's still   a very close friend of mine. I think he's just a fantastic   person and technologist, and and, I think he's been an amazing leader for for the language. So I just fell in love with it, and we ended up using it at CNRI. And   we   you know, over the next few months, Guido   we hired Guido, and he moved to the States. And I worked with him, you know,   within throwing distance, you know, in the next cube, for about 8 years before he moved out to California. And then, 3 years ago, I followed him out here. So  

[00:04:06] Unknown:

And as somebody who has been involved with the language for so long,   what are your senses of how much of the core elements have stayed true all the way throughout, and how much has it really changed in terms of its character or capacity in that time? Yeah. That's a really interesting question.  

[00:04:23] Unknown:

Last year,   I gave a talk at   the local Bay Piggies, which is, you know, the, you know, Silicon Valley Bay Area Python Interest Group. And I went through and pulled down the tarballs for all the Python versions going back to, like, 093.   Grabbed all those, looked at the change logs. I couldn't compile any of them on any modern system   without significant amount of work, none of them built, none of the early Python zeros or Python ones built. But I went through and looked at the change log and kind of got a sense of what the you know, remembering what the language was like in the early days. And a modern Python developer   would look at Python   1.1   and say, it looks very familiar. You know, it it has not radically changed. In some ways, it has exactly the same feel that, you know, I fell in love with 25 years ago, but in a lot of ways, it's changed immensely.  

For example,   you know, there was 1 release early on where Guido just, you know, within 1 release, changed the equality operator.   You know? It used to be that assignment and equality were both a single equal sign. And in 1 release, Guido just said, I'm changing it to double equals. And there was no consideration of backwards compatibility.   There was no problem with, like, people just having to change their code. So, like, a lot of these little things   got introduced early on,   and the language was changing very quickly. And now it it still evolves, but much more slowly. And you see things crop up like keyword arguments. Everybody sort of takes, you know, thinks keyword arguments are   a standard part of Python. But there was a time before keyword arguments were a part of the language, and you can see the sort of revolution in the way people think about it. I remember 1 of the biggest impetuses for that was,   Tickle TK, you know, trying to do graphics   with Python. And the t the Tickle bindings, you had to   specify every single argument, and it just got completely unwieldy. And then once keyword arguments were added, you know, all the calls got much simpler.  

And  

[00:06:32] Unknown:

you can just see how, like, that 1 little feature has changed the flavor, the feel of Python immensely, and it's something that somebody coming into the language today wouldn't even think about. Yeah. I can definitely see how that would be a pretty revolutionary change where all of a sudden you can have sane defaults for all of your functions while still allowing for all of the expressivity that you really want, which is 1 of the more useful aspects of the keyword arguments. But not having them and   defaults  

[00:07:03] Unknown:

so that you have some way of not having to rewrite them every single time. Exactly right. Exactly right. And there's just so many of those little things. And, you know, looking back at Python now, you can see how   Guido's   sense of aesthetics for programming   has really served, you know, both him and the language and the community really well. He just seems to get right at the heart of   of the matter.   And a great example   in modern days, I think, is PEP 572, which is the Walrus operator.   And when the first draft of that PEP came out, I was really against it. I was like, this is this is wrong for the language. You know? We don't need it, and the semantics are are tricky. But, you know, I had I really had faith in in Guido because   he really listened   carefully to a lot of the comments and feedback that was coming back. Some of   it not entirely kind, which is very unfortunate. But what ended up coming out, I actually turned the page, and I'm I'm a big 572 fan. I'm a big Walrus operator fan now. So, you know, you you see this this sense of   trying to do the the right thing and find the right balance between,   power, express   civility,   and Pythonicness,   which is a very sort of amorphous   quality to   wrap your hands around, but it's still happening today. And so, you know, I have a lot of faith that the language is   still, you know, still a coherent,  

[00:08:34] Unknown:

friendly, fun language to use. Yeah. It's definitely interesting seeing the evolutions. I have only been using it since around the 2.4   time range, which has still been enough of a change in terms of the capabilities, particularly with Python 3 adding in a bunch of new library capabilities and adding in a lot of the default numeric operations that people are using it for these days. And I'm on board with you in terms of the Walrus operator. I've used it in some of my code recently and definitely appreciate being able to have that assignment expression in line with the conditional. So it's interesting seeing some of the battles that are won and lost in the peps and sort of how that plays out. Yeah. At 1 point, I had the I was I was kinda proud of this. I had the most rejected peps of anybody. So, you know, I think you gotta just, you know, you put these ideas out sometimes. And in fact, I've had peps that were have been retroactively  

[00:09:27] Unknown:

accepted, believe it or not.  

[00:09:31] Unknown:

So yeah. Well, definitely lessons to be learned in failure. For sure. For sure. In line with   the work that you've done with the PEPs, for people who aren't familiar with you and your overall   have worked with the language and for the language and the overall community of the ecosystem that has grown up around it?  

[00:09:55] Unknown:

Yeah. That's it's hard to sort of succinctly   summarize 25 years. But, you know, I I did early stuff with,   I'm sure nobody remembers anymore something called the grand renaming, but anybody who's played with the c API for Python, you know, it looks very nice. It's it's all logical for the most part. A couple of words here and there, but the naming scheme makes sense. It's easy to find all the documentation.   It wasn't the case   early on, and 1 of the very first projects that I worked on when Guido had moved to the States was what we call the grand renaming. And that was taking all the c API stuff and putting all the pie,   you know, string this underscore this and that's and pie xe this and that's in front of all the public names because at the time, you couldn't embed Python in other c programs,   and you couldn't really extend it very well because there were lots of name clashes that were just sort of global c namespace stuff. And we made all that better, you know, with a lot of direction from pipe from Guido, of course, but, myself and and a few of the other early CRIers did that. So I've dabbled in the c code. I've dabbled in the library. I've dabbled in the build system. I've been a release manager   for for several releases. I I kind of came up with the whole idea of PEPs, and I named the PEPs. And I I really feel like the PEP process is 1 is something that I'm particularly proud of because I think it's really given us a way to evolve the language.  

We could talk about that, but I've really dabbled in a lot of things.   I would say that these days, I don't do as much programming   on Python   as I had in the past. I just sort of see my role as kinda changing, and, of course, my interests are are changing as well. But I've really dabbled in quite a bit of the the code. Yeah. I'll definitely second your notion that the PEPs have been integral to the overall evolution of the language, and it's something that a lot of different languages  

[00:11:53] Unknown:

and   development communities and library communities are leaning on of this notion of a public sort of RFC process   and a lot of the acronyms mirror the PEPs as far as the overall idea of enhancement proposals. And so I think that that's definitely been a great   reference point for other languages and communities who want to be very deliberate about the way that they work on the capabilities and functionalities and the ways that you use the technologies that they're building. I I I think you're absolutely right. And and, you know, the PEPs  

[00:12:25] Unknown:

kinda came out of our experience at CNRI because they were running the ITF   meetings. And so we saw firsthand the the RFC process for Internet standards. But we wanted something that was much more lightweight, and that was just enough bureaucracy   to   capture what we needed it to capture. And so that was really the the origin of the PEPs. Although,   the acronym PEP was definitely a backronym. You know? I just thought know, it was kind of a funny peppy word, you know, a happy word, and then I filled in   the   filled in the backronym,   afterwards. But, yeah,   it's it's that's been wildly successful. I've I've been at 1 time, I was heavily involved in the Debian community, and they used DEPS, Debian enhancement proposal. So it's been very cool to see that happen. Yeah. And as you mentioned, the Python community, because of its origin  

[00:13:18] Unknown:

in humor, has a lot of inside jokes and Easter eggs, and the peps are no exception there where you have pep 401 where you were declared the fluffle accidentally when you were trying to nominate Tim Peters for the rule. Yep. Yep. Exactly. And, PEP 801, which was reserved for some enigmatic reason that nobody quite understands.  

[00:13:38] Unknown:

Yes. Excellent.   And there's also you know, we have PEP 666,   I think. And,   and, what there's another funny 1, I think.   4 of of course, 401. But, yeah, that that was kind of you know, we were I was 1 of the pep editors. So at 1 point, before we moved to GitHub, we had to sort of dole out the numbers, and I I was able to sort of reserve a few, you know, fun numbers. So,  

[00:14:03] Unknown:

yeah. Do you have any good plans in place for number 801?  

[00:14:06] Unknown:

I don't, but I you know, there was a band in the seventies called 801,   and that's kind of why I'm reserving it just because I you know, maybe something fun will come up at some point. Maybe you can auction it off at 1 of the Pie Ladies events. There you go.  

[00:14:21] Unknown:

That's a great idea. And so in terms of   outside of the language and your engagement with the community and some of the ways that you have worked to help promote the language and promote its use. What are some of the other ways that you've contributed in that regard and some of the contributions that you're most proud of either otherwise?  

[00:14:41] Unknown:

Well, that's, yeah, that's interesting. You know, I've said this before. This is this is a story I've told quite often, which is that at that first   workshop, you know, there were 20 of us in a little room in a government,   you know, research facility in Gaithersburg, Maryland. And a number of the people who were there came out and said, you know, you cannot tell anybody that I'm here because Python is a competitive advantage, and we don't want our competitors to know that we use Python. You know, fast forward now, and Python is everywhere. And it was something where I really believed   in Python quite strongly right from the get go. You know? I mean, I I've been a fan of programming languages. I've, you know, I've used dozens and dozens dozens of languages in my career, and I still continue to learn new languages. And I love that. But there's something   special about Python, and I really noticed that right on. And I really tried in every job that I was at or every side hacking project   to promote Python and really say, you know, Python is the right solution for this. And I think a number of us in those early days really believed very strongly in Python and just pushed it in into every   nook and cranny that we could get away with. And you see that now. Python is arguably   within the top 3, if not the second most popular language. The domains in which Python is relevant are so vast and broad   that I think that's a function of us really pushing Python, not just me, of course. I mean, everybody who who is a fan of Python, you know, pushing Python into new and better and more interesting   and,   challenging   domains. So you see, like, Python growing up into   the number 1 language in data sciences, you know, which nobody could have even thought about back then. So, yeah, Python's not appropriate for everything, but it is appropriate for so much   that just being an advocate for it and pushing for it and proving. That's the other thing is really building systems   and proving that Python is can build small scripts,   can build libraries, can build,   applications,   can build websites, can build Instagram, for example. You know? Like, Python is so versatile and so easy to get into. And I think that that is just something that we've always been promoting and pushing, and that that I'm particularly  

[00:17:07] Unknown:

happy about. So Yeah. 1 of my favorite ways to encapsulate that is I've heard it a few times that Python is not the best language at anything, but it's always the 2nd best language at everything. Yep. Although I'll argue it's the best language for a lot of stuff.   Yes. Absolutely.   And so looking back at the past 25 years of your involvement with Python, what are some of the things that in retrospect   have been the most interesting or surprising or exciting and some of the turning points in both the success of the language and in your own career and involvement with it? I think I think the thing that  

[00:17:42] Unknown:

never ceases to surprise me is being up on stage. Now, hopefully, we can do this again after, you know, after we get a handle on the the whole coronavirus thing. But being up on stage and looking out at 3, 000   Python fans,   and those are only the people you know, like like, a sellout crowd at PyCon.   And that just blows me away every single time I I look out into that to that crowd. And it's not just, you know, sort of grizzled veterans like myself. A lot of young people are coming into the language   and   very diverse,   you know, communities of of Python fans.  

I I that just you know, I always believed in the language, but I guess in your heart of hearts, you sort of think there's lots of competition in programming languages. Why should Python win? You know? And yet, in a large way, it it sort of has. You know? It it is   so pervasive   in industry   and in education.   And that to me has just been   completely surprising,   I guess,   and very exciting. And I and I think Python's got a very bright future. It's not going anywhere. And I think as as more young developers come in, and and I've really been encouraged to see,   you know, a lot of younger developers come in and and   also fall in love with Python and then take an active role in   evolving the language and the implementation. And that to me, that's a sign of of hell. Yeah. I definitely think that it's utility as a learning  

[00:19:12] Unknown:

language is really helping in bringing in that new generation of programmers. And I'm trying to do my part with teaching my children as well, but it's interesting too to see how the overall focus of the community has changed and grown since the early days where, as you said, started with a room full of 20 people in a government building. And now it's, you know, multiple conferences worldwide,   meetup groups,   online forums, everything that you can possibly imagine in terms of communication and community.   So what are some of the   main areas of focus that you  

[00:19:45] Unknown:

have seen in the community as it's as it grows? And what are some of the areas that you think need greater attention or support? I guess there's there's 2 ways to look at it sort of, like, from the technology side and then from the community side. From a technology side,   1 of the things I think Python has done really well is it's sort of been a kind of a chameleon language.   So   what I mean by that is, you know, in the early days, you know, people were writing scripts to do system administration   or little   little applications and tools and things like that to solve their their problems of of the day. And as the web got very big, you saw things like Python   adapt and grow into   various web technologies, both crawling the web and providing,   you know, back in the day, CGI   bin scripts   and building sort of the back end of the web and adapting to   to the to the web as that as that's come up. And, you know, now its its role is is hugely important in the data sciences. So I think as technology   changes, Python is able in large part to adapt to that. And who knows what the next big thing is gonna be, but I I suspect that Python will be 1 of the first languages that embraces whatever that next big thing is. I do think Python has some technological   challenges   that I you know, as part of the steering council,   I hope that we can find ways to address. For For example, Python, I think, needs to be much better at multi core, and I would love to see Python in the browser, like support, you know, a a web assembly back end or something like that. So I think there are tech techno technological   challenges,   for Python as computing changes. I mean, you know, the the state of computers today is so different from 25 years ago, and you can't even imagine what it's gonna be like in the next 25 years or the next 5 years. But I have faith that Python will Python the language   as opposed to necessarily   c Python, the the reference implementation or the most popular   implementation,   will adapt to those changing computing environments   and new domains.  

So that's sort of the technology   side of things. And I and and there are people working on all that stuff. So I have I have a lot of confidence that those important domains, Python, will will adapt better to.   On the community side,   I think we have a lot of we have a lot of good,   structures in place, a lot of good, institutions in place. I think the PSF,   for example, has been a fantastic   development for Python. And,   you know, the sense that the community embraces   everybody. Right? Like, it doesn't matter. You don't even have to be a c programmer, for example, to become a core developer.   You don't even necessarily have to work on the standard library to become a core developer. Like, we like, there there is so much to do that people can contribute and make Python better. And   documentation,   build systems,   you know, CICD. There's just so many things. Education, building the community,   bringing in more,   widening the diversity   circle and bringing in more people from underrepresented communities   into Python,   those are all, like, really important things. And I and I I know that, you know, I I certainly support all those things, and, you know, everybody that I know of in in leadership positions in in the Python community   support that as well. I mean, that's where we, you know, I'm a big believer in diversity as our strength, you know, and that's along so many different different dimensions. But that's what you know, those new experiences and that enthusiasm   is what really keeps Python going. So, you know, we have challenges in the community and we're trying to address them, and I think anytime you have a programming language or or community that's as large and as diverse as we are. You're gonna have   challenges   to, you know, in any large society of human beings, that's a natural natural effect. But, you know, we really want to make this a welcoming,   friendly, happy programming language and  

[00:23:50] Unknown:

development community. And to your point about the size, when do you think Pythonia is going to become a sovereign nation?  

[00:23:57] Unknown:

Well, I'm hoping the PSF buys a sealand, and then we can just all move there. But  

[00:24:04] Unknown:

And so you alluded to your membership in the Python steering   council, and that is definitely 1 of the biggest shifts in recent memory for the language with Guido stepping down as the benevolent dictator and deferring to this new community structure that there was some period where there was no firm idea as to what that meant for the future of the language. Thankfully, it has become settled and we've come to what I think is a very good solution to that problem. And so in your role on the steering   council, what are some of the main areas that you're personally engaged with and focusing on? I think, you know, I I took very seriously  

[00:24:43] Unknown:

my first term, which I think the main thing that we had to do you know, even though we had, like, had this community vote and we came up with the current government   governance system, there was a lot of things that were sort of still kinda left up to the steering council to decide, you know, what the process was for various things, and and those things still come up. We we still are sort of like we're not quite sure what the right process is for x, y, or z. But I felt it was a responsibility   of mine as it was in the early days,   of Python to get the processes   and   mechanisms for functional governance   in place,   that could sustain. I mean, I'm not gonna be on the steering council forever and   there's gonna be lots and lots of people   serving on the steering council. And I and I feel like we've gotten it to a really good place where it's a it's a important,   stable,   functioning institution   for deciding how, you know, the language is gonna evolve. And I I took that responsibility pretty seriously in my first term.  

And we also had a lot of just housekeeping to do because as after Guido had stepped down, there was a long period of time where lots of peps needed to be decided on. And we just had to sort of slog through those and figure out, you know, are we gonna delegate   responsibility for accepting this 1, or are we gonna keep this 1 in our in our wheelhouse? And we just had to get through all those peps. In this second term, I think we've you know, we're in a pretty good steady state with things.   And so now we're really talking about   things like, what's the future of Python? Like, if we, for example, if we had a pot of money that we could go out and hire some developers,   what would we want them to do? Would would it be more important to   help triage bugs and   keep the PRs moving,   or would it be more important to do some venture   experimentation like a web assembly back end or more playing around with multi core support trying to get rid of the GIL and things like that. So I think those are some of the things that I I feel very strongly we want to be involved in,   in helping not decide what the future of Python is, but helping the community   as a whole   figure out the future direction for   the big ticket items in Python and how we're gonna fund them, you know, what the structure for that is gonna be, how would you still value and balance the contributions of volunteers,   understanding that volunteers   have a very difficult time   implementing and bring to fruition some of these really big changes. Right? Like, those are those are some of the issues that we're dealing with as well. And for some of those  

[00:27:23] Unknown:

far reaching and impactful   areas of improvement for the language, Russell Keith Magee did an excellent keynote at the last PyCon, which I'll link to in the show notes, and we did a follow-up conversation on that. And to your point of funding, I know that that's a conversation   that is ongoing. But at the last icon, I saw a few different   ideas in terms of how to pursue that and some of the existing challenges in terms of how   the organizational structure of the PSF   limits in some ways corporate donations and just some of the overall ideas about how to bring in more money to allow for those more far reaching and forward looking projects. And I'm wondering what your overall thoughts are on that or any of the current developments or current efforts that are going on to help ensure that those projects are able to happen and be sustainable? 1 thing that I I'm especially happy about is the way the  

[00:28:17] Unknown:

steering council as the technical leaders and the PSF as the community leaders work together. So, you know, I I feel very strongly that those divisions   of expertise and responsibility   are important for Python because   the community nurturing the community is not a technical not necessarily a technical side of things. And while there's lots of community in the steering council that we think about, we're really sort of focused on the technical side of of Python's evolution, but the 2 organizations work really well together. So   we talked to the PSF   on a regular basis. In fact, Eva attends our steering council meetings, and that's been   fantastic. I can't I cannot speak highly enough of of Eva. She's absolutely fantastic.  

So, you know, they look to us to to sort of what are the technical directions that we want to pursue.   And then the PSF   kind of thinks about, you know, how can we build   the structure and the organization to make that happen. And so those are ongoing talks that we we have   all the time about how to how to do the things that we wanna do that we think that it's difficult for the volunteer community to do, but not   devaluing   or taking away   any of the fun and responsibility and focus that the that the volunteers   bring to Python. It's a it's it's a it's ongoing discussions about how all that stuff works. You know, and nothing that we're doing you know, we try to communicate to the community when we have something that's of value to communicate,   and we and, you know, the the community's input is is absolutely important. You know, it's it's vital. You know? Python has always evolved   from a sort of more grassroots   movement.  

You know, if you like Guido has said this before. There are few initiatives where he he said we should do it this way or this way. It's all it's a lot of it has been things that percolate up from the the community, and then, you know, Guido finds the right way to   to make that happen, you know, to put that together. So I don't feel like the steering council's   role is to   come up with great ideas. It's more to look at the ideas that are coming up from, the the community and from the grassroots and that people are challenged with or or thinking about and trying to decide what the focus is. You know, what what the right focuses are.  

[00:30:38] Unknown:

This portion of podcast dot in it is brought to you by Datadog.   Do you have an app in production that is slower than you like? Is its performance all over the place, sometimes fast and sometimes slow? Do you know   why? With Datadog, you will. You can troubleshoot your app's performance with Datadog's end to end tracing and, in 1 click, correlate those Python traces with related logs and metrics. Use their detailed flame graphs to identify bottlenecks and latency in that app of yours.   Start tracking the performance of your apps with a free trial at pythonpodcast.com/datadog.   If you sign up for a trial and install the agent, Datadog will send you a free t shirt to keep you comfortable while you keep track of your apps.  

And so moving now into your professional engagement with Python, As you mentioned, you worked very closely with the Debian community for a number of years and were with Canonical for quite a while. Currently, your work at LinkedIn as part of their Python tools team and helping to facilitate the use of Python at that company. And so I'm wondering   what you have seen as being the main use cases for Python, both at LinkedIn and canonical, and just some of the challenges   that crop up at some of these larger organizations   or more distributed communities?  



[00:31:53] Unknown:

Yeah. So that that's really interesting. So I think,   you know, within Debian and Ubuntu, Python is used all over the place. You know, Launchpad was our big code hosting and Ubuntu development portal. That's all Python or at least it was until, you know, while I was there. At LinkedIn, we use a ton of Python,   mostly in the back end, in the tools and foundation   areas. So if you walk up to linkedin.com   on your browser or, you know, the iOS devices or the Android devices, you know, a lot of that's gonna be, you know, mobile technologies.   You're gonna be talking to Java   back ends, but tons and tons of stuff on the internal   operational side of LinkedIn is written in Python, And it's just a great language. I mean, you know, you look at look at, like, Instagram or so many other big companies. You know, they the 1 of the reasons why Python is so   pervasive, I think, is because it's very easy to bring a diverse   experience of developers. So almost any team is gonna have, you know, senior people and and more junior people. You're gonna have lots of churn. Right? So you're gonna have new people coming into a code base, and you wanna get them ramped up to speed quickly. And Python just, like, ticks all those boxes. You know, it just really makes it easy to maintain   relatively.  

And so I think that's why you've seen, you know, certainly why LinkedIn, for example, has adopted Python so pervasively.   We have some fairly big systems on the internal side that that are built in Python, and,   I think we're pretty happy about that. Java, of course, is the other big language that we use. Lots of command line scripts   and libraries   and tools are written in Python.   So Python's a pretty important language at LinkedIn, and and I think that's true in a lot of big organizations.   Surprisingly,   1 of the developments that I think makes that   feasible   is type annotations. And I and I've been real that's another feature that I was, like, really against when it got added because I I didn't want Python   to turn into Java. And I there was a a sprint at Instagram, I think, or Facebook. I I don't remember exactly the details. Couple of years ago.  

And, you know, the my Py team had come to us and said, the reason why we're investing so heavily in My Py and type annotations   is because we can bring in a new junior programmer into a team, and those type hints make it so that they can be productive much more quickly. And so in my own code, I started to say, well, let's   adopt type hinting and see what it does to the code base. And it just is, again, it's just the right mix of   not too much   bureaucracy,   but just enough to make it so much more productive. It's just the right balance. You know? And so, like, now even in my own code, I'm going through some of my open source libraries, and I'm type annotating everything, and I'm, you know, I'm feeling great about it, you know, adding my pie checkers, and it just gives you a better sense of confidence and and   self documentation.  

So that's another feature that I was against, and now I'm totally on board with. You know? So those those kinds of things really make it, much more palatable in a corporate environment. Yeah. I've had the opportunity recently to start a couple of greenfield projects in Python and have been using the type hints and annotations,  

[00:35:16] Unknown:

which I hadn't previously really had much experience with. And I'm completely on board with you and the rest of the community that they make everything much easier to reason about where you can be working in 1 module   and have intelligent auto completion as to what it is that you need to have in there and some error checks to keep yourself from doing something stupid without having to flip back and forth between 15 different files to make sure that you have all of the arguments correct. Yep. Exactly. Exactly. It's it's a it's a it's a great feature. You know?   Yeah. And in terms of some of the Python projects coming out of LinkedIn, there are a couple I saw a while ago that where it's being used for managing your on call   and alerting, which is  

[00:35:55] Unknown:

absolutely mission critical. And so the fact that LinkedIn is trusting Python with that definitely is a huge vote of confidence. Yeah. Yeah. And 1 of our engineers, you know, we at LinkedIn, all of our command line tools or many of our command line tools are written in Python, and so we wanted to have sort of a single file   executable format, and we had adopted PEX. I don't know if people are familiar with PEX, but it basically is a way to build a zip file an executable zip file. But we found that there was a lot of problems with the PEX format because mostly because it had been around a long time and it had a lot of backwards   compatibility hacks that affected performance and things like that. And so 1 of our engineers   built and from the start open sourced, a tool called Shiv, which is just all modernized. It's it's set the same basic idea, but much more modernized. It adopts only Python 3. You know, it has all the modern conveniences of Python 3, and it's just it's a great tool. So that and so we've completely shifted to to using that, but that was 1 of the things that we were like, we should open source this and and get, you know, give it to the community and engage with them, and that's been super successful.  



[00:37:02] Unknown:

So LinkedIn is is is pretty open source friendly. Yeah. Shiv is another tool that's on my list of things to try out for these projects that I'm working on now to simplify the distribution of the projects. Another interesting 1 that I'm keeping an eye on is pyoxidizer   for being able to build stand alone binaries. I'm I'm a big fan of pyoxidizer.  

[00:37:20] Unknown:

I ran an experiment last year to try to convert to using PyOxidizer,   and I ran into some problems. Some of them were related to LinkedIn's   own,   you know, weirdnesses   because every every corporation has its own weirdnesses.   And some of them were things that I I would have wanted to adopt,   or change in,   in PyOxidizer.   But but it's a really cool project, and I really like Rust, you know, and I like that melding of Rust and Python quite a bit. So I'm hoping that PyOxidizer,   you know, is something that, you know, evolves and and,   and can, you know, solve LinkedIn's use cases, for example. And what are some of the other  

[00:37:58] Unknown:

projects or categories   of work that you're doing to help support the other engineers at LinkedIn and their use of Python and just some of the interesting challenges that you're tackling there?  

[00:38:10] Unknown:

So 1 of the things that I'm my latest kick really is on   things like getting   widespread adoption of, like, QA tools is what is is sort of how I'm putting putting that together.   So these are things like flake 8,   for doing static analysis   and the and the specific set of flake8 rules that we want to adopt. Do use adopting things like isort and   mypy,   pervasively within the within our code bases. I would say black is kind of a controversial   tool, which we haven't quite adopted yet. I won't go into a lot of detail about that, but, you know, there we have we have some   discussions about about black, but that's that's along the same lines.  

So I think a lot of these tools are really important. And then on top of that,   adopting   standard documentation   tools. So, like, for example, you know, syncs for for you know, and and and, we have an internal read the docs implementation,   so we wanna be able to have all of our documentation   easily available,   both API documentation and then, you know, pros,   usage, examples, tutorials, and things like that. I've recently started playing with Sybil, which is   an outgrowth of Manuel,   and it's the doctests. I'm a big fan of doctests,   and I'm I've been adopting that. I've been using doctests for a long time, but like Pytest   in my own open source stuff,   I have been using   nose too, but I think Pytest, you know, clearly has won the the day, and it's a great system. So finding ways to integrate   document doc tests into the testing stuff. So that's that's really where I'm I'm sort of focusing my attentions on inside LinkedIn these days is what's the right set of tools   that we can deploy   and   get adopted in a widespread way so that we just have greater confidence and discoverability   and and documentation for all of our all of our internal Python code basis. Yeah. Those are definitely  

[00:40:11] Unknown:

important endeavors, and it's remarkable   the amount of   impact that they can have on the overall productivity of a group of developers by just adopting those standards and saying, here's your boiler plate. Here's all the configuration.   Here are the tools that are going to provide guardrails to you so that you can just focus on writing the things that we actually care about and everything else is taken care of. Exactly.  

[00:40:32] Unknown:

That's exactly right. It just gives everybody greater confidence   about all the code. You know, like, coverage is a great example. Right? The tools that I am responsible for within LinkedIn, I try to get them to a 100% code coverage,   and I try to fail the builds if if they don't you know, if they fall below that. Now a 100% code coverage doesn't mean you're not gonna have any bugs, but it just increases the confidence level that you have in that code base. So that's another   important tool in the,   in the tool toolbox, I guess. Yeah. It helps prevent projects from  

[00:41:06] Unknown:

descending into legacy where it's the the big ball of mud paradigm where you have to keep it running because it's critical to so many things, but nobody knows how it works and nobody wants to touch it because they're afraid that it's going to fall over and break. Exactly. Exactly. And it's especially you know, for us, we got rid of Python 2 August of last year. So we took about a year  

[00:41:27] Unknown:

to convert all of our Python 2 stuff to Python 3 and stop allowing Python 2 to build. So it took us about a year, maybe 6 months of planning and 6 months of execution, which really wasn't that bad. But that kind of, like, code coverage,   those numbers   when you're converting to Python 3   are critical.   Right? Because if you don't know what you're actually testing, you don't know if that change is gonna break something or not, especially in a big migration like that. So I I'm a big proponent of boosting your your your coverage and just being able to know what your coverage is. Right? Like, if I walk up to a random code base and I say, how much of your code is is covered by your tests? A lot, you know, a lot of code bases don't even know because they don't collect that information. And I think you have to at least know so that you can then   ratchet that up and and put and and invest in your own you basically, you're investing in your own future. Right?  



[00:42:22] Unknown:

So Absolutely.   What's the adage that, write your code as if somebody in the future is going to read it who is a sociopath and knows where you live? Right. Right. I always say I always say be kind to your future self, you know.  

[00:42:34] Unknown:

Exactly. I've looked at enough of my code that I've written, you know, years prior in whatever language, and I've said, oh, this is terrible.   You know, what was I thinking back then?   So yeah.   So be kind to your future self.  

[00:42:48] Unknown:

Absolutely. Yeah. I think we've all had that experience of looking back at their projects and saying, I don't understand why I did it that way because that makes absolutely no sense.  

[00:42:57] Unknown:

Well Or how did this ever work? You're you're you're so right. And that is another thing that I try to promote is, like, how do you comment code? Right? Like, I don't need you to say, oh, I'm adding 1, you know, to this, value over here. When I'm reading code, I wanna know why did you pick this algorithm as opposed to that algorithm. Right?   I'll go through that code and I'll say, well, I thought about doing it this way and I tried to do it that way and that that was worse performance and blah blah blah. And I'll put that in a comment so that when somebody comes by in a couple of years, whether that's me or somebody else, and they'll say, no. Why why did they do it that way and not a, b, or c? That comment will explain,   you know, the thought process   to come up with that particular approach or that particular algorithm. And and that's a that again, that's an educational   that's an educational role. The proper way to do comments, the proper way to do documentation.  



[00:43:50] Unknown:

Yes. All important things for software. It's not just about making the bits fly about. It's making sure that the humans who read it are able to figure out why they're being flown about in the first place. Right. Exactly.   Outside of Python, what are some of the other languages or communities that you look to for inspiration in your own work and for potential future directions for the language or new capabilities?  

[00:44:12] Unknown:

I'd like to think that I'm I'm I'm sort of very on the in the background learning,   Rust. You know, I'm I'm a big fan of Rust. I think Rust is a very interesting language. You know, c and c plus plus have been around forever.   I think my own feeling is you know, I'm I'm very comfortable in c. I've always loved c and objective c and c plus plus and those kind of those kind of languages, but I don't think that they're   sustainable enough today. And I think Rust   can serve the role that c and c plus plus,   serves, but in a much more structured and safe way. And I love the fact, for example, that Rust can produce c API ABI compatible binaries.   So you can build extension modules   in Rust, and Python doesn't care. You know? Right? So that's that's 1 particular and I think they for example, like cargo and the whole,   dependency management system of Rust is something that we can learn a lot from. Python's dependency management   is problematic in some some cases, but a lot of that is because Python was the trailblazer,   you know, in a lot of ways. And so,   you know, we can learn from these newer systems that take a fresh look at at some of these problems. So Rust is, I guess, 1 community and and language that I'm I'm following   somewhat. I I have a pretty diverse set of interests, like, totally outside of software engineering and things like that. So finding time for all the things I wanna do, it's really difficult.  



[00:45:38] Unknown:

Absolutely. Yeah. I know that you are,   outside of your accomplishments in the software realm, you are also   somewhat accomplished bass player. So what are some of the other areas outside of programming that you lean on to help maintain your sanity and, sort of free yourself from the, drudgery of technology.  

[00:45:56] Unknown:

Well, music is is the the big 1. I you know, I'm in a couple of bands.   I do have my own home studio, which I like to do,   you know,   occasionally come in. For me, playing music and playing bass is is, like, you know, chicken soup for the soul. Right? Like, that's for me, that's that's what lifts my spirits, and and,   and that's been difficult during coronavirus because, like, all of that public   gigs and things like that have just, you know, dried up overnight. So that's that's been tough, but I'm doing music as much as I can these days. And   and then the other thing that keeps me sane is I I've been practicing Tai Chi for for 20 years, and that is a hugely important part of my   especially   coronavirus,   sanity.  



[00:46:45] Unknown:

Yeah. I can see how that would definitely be beneficial. Yeah. And,   how much of the overall success of Python is due to the invisible hand of the Python secret underground? Which emphatically does not exist.  

[00:46:57] Unknown:

Of course.   Yeah. That's funny. That that that's a really funny 1.  

[00:47:03] Unknown:

Who's responsible for that meme? Because that's been kicking around for quite a long time, I understand. I think it was me.  

[00:47:09] Unknown:

I'll take the blame for that 1 too.  

[00:47:12] Unknown:

Fair enough.   So are there any other aspects of your work in Python or in technology as a whole or your engagement with the Python community or its impact on your life and career that we didn't discuss that you'd like to cover before we close out the show? No. I think we've we've covered a lot. I mean, I just I I I'm still  

[00:47:30] Unknown:

as big a fan of Python today as I was 25 years ago. You know? And I just   encourage,   like, I mentor a couple of people inside LinkedIn, and I've really seen my role these days, both   within Python and as   a   senior developer   engineer in much more of that mentoring and educational role than in just like hacking code. Right? And I really wanna encourage people,   especially young people who look at Python and say, this is a cool language, this is a cool community, and I wanna get involved, to please reach out   to the steering council, to there's a mentorship,   list.  

Don't feel like you can't be a core developer. If you love Python,   you can be a core developer. Don't feel like you have to be a c programmer to be a core developer. Don't feel like you have to write tons and tons of Python   to be a core developer. There's so many opportunities   to engage with the community side through the PSF or the technical side. And I just really wanna encourage people to think broadly and have faith and confidence in themselves and that there are people in the more senior positions and the leadership positions who will help you in your journey  

[00:48:46] Unknown:

to shape Python's next 25 years. And also if you're considering other communities, how many of them have their own friendly language on goal? Exactly. Right?   Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks. And this week, I'm going to choose the series Hannah, which I just watched the 2nd season of. And it's just a really well put together show, great storyline,   really good acting.  

Highly recommend that for somebody who's looking for something to watch and be distracted for a few hours. And so with that, I'll pass it to you, Barry. Do you have any picks this week? I I have 2 actually that I'm really into these days.  

[00:49:27] Unknown:

1 is a show on Netflix called Midnight Gospels.   And it is it hits all my buttons. You know, it's trippy and weird and animated   and just bizarre,   but underneath all of the weird animation, it just gets into some really deep,   philosophical topics. So I've been loving that 1. I've been savoring those episodes.   And the other thing I'm absolutely obsessed with these days, I I love this show called The Expanse, which I think was on Amazon Prime. And I think the 5th season is coming out at some point, probably next year, but my brother turned me on to the Audible books. You know, the the books on they're not on tape anymore, but, you know, the the,   through Audible, you know, I I listen I put them on my phone, and I listen to them in the car, and it's just absolutely fantastic.  



[00:50:16] Unknown:

I'm I'm, like, looking for excuses to drive places now so that I can, listen to it listen to those books. It's really good. Yeah. I've I've been enjoying The Expanse series. I haven't taken the time yet to read or listen to the books, but, I'll put that back on my list. So definitely appreciate you taking the time today to join me and share your experiences with the community and with the language. It's always great to talk to you. So thank you again for all the time and energy that you've put in to help make Python become what it is today, and I hope you enjoy the rest of your day. Well, thank you, Tobias. I've really enjoyed this as always, and and I hope I get it we get a chance to see each other again in person someday soon.   Absolutely.  

Well, thank you. Take care.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at data engineering podcast dotcom for the latest on modern data management.   And visit the site of python podcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcastinit.com   with your story.   To help other people find the show, please leave a review on iTunes and tell your friends and coworkers.