Ben and senior software engineer Kyle Mitofsky talk with Pablo Galindo Salgado, a Python core developer and Python Steering Council member, about how he infiltrated software development from the world of physics, the journey from fixing typos to updating core, and the time he broke GitHub (an important developer milestone!). This is part one of their two-part conversation.
Pablo is a Python core developer, Steering Council member, and release manager of Python 3.10 and 3.11. He splits this work 50/50 with his day job as a senior software engineer at Bloomberg.
An astrophysicist by training, he did his PhD on rotating black holes.
Whether you’re a new contributor or a seasoned veteran, the Python Developer’s Guide is a comprehensive guide to contributing to Python.
Pablo is on LinkedIn, Twitter, and GitHub.
Kyle is also on Linked, Twitter, and GitHub.
Shoutout to Inquisitive Badge winner trever for asking well-received questions on 30 separate days.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I'm your host, Ben Popper, Director of Content here at Stack Overflow, joined once again by my friend and colleague, Kyle Mitofsky. Hi, Kyle.
Kyle Mitofsky Hello, hello.
BP So Kyle, you came with me on a trip last year to the Next.js conference. I bring you when I feel like I need more technical firepower.
KM There you go.
BP Can't fake my way through this interview just with my journalistic chops. So today we have the privilege of chatting with someone who is an experienced software developer and also a member of the Python Steering Council, and we're excited to dig deep into some of what that means and what's going on with that language, which Kyle, you recently have been teaching yourself? Did I get that right?
KM Yeah. I've been picking it up and it's been a joy to work with so far, so super happy to talk to folks who are shaping it.
BP Yeah. It seems like one everybody wants in their arsenal these days, so it’s going to be a two-part episode, so we will publish the first part today– Friday, and the second part will come out Tuesday of next week. Hope you enjoy, and without further ado, Pablo Galindo Salgado, welcome to the Stack Overflow Podcast.
Pablo Galindo Hello. Thank you very much for having me.
BP So let's hear a little bit about you. What was your journey into the world of software engineering, and then more specifically, how did you end up focusing on Python and joining the Steering Council?
PG Yeah, absolutely. I think a lot of folks will be surprised to know that I'm actually not a software engineer, I'm a physicist. I mean, I work as a software engineer for sure, but I'm an infiltrated software engineer, let's say. So I actually started in the world of programming as part of my physics education. Interestingly, most physics, at least from my time, we teach Fortran as the first language, so that's an interesting introduction into the world of programming. Also not modern Fortran like a lot of people may be using today, it’s Fortran 77. But yes, that was interesting. And then after that when I was doing my PhD in rotating black holes, one of the things that we needed to do a lot when the equations become too complicated, which is most of the time, then you need to do some simulations just to have some pretty pictures, because that's what people like. People don't like equations, they like pretty pictures and for that you need to code. That's the only way apparently. And I used to code a lot in C, C++ and Coda, which four or five years ago nobody knew what it meant. But now with all the AI stuff, everybody knows what it is, so that’s kind of cool. After that, I switched from academia to computer science when I joined Bloomberg, and since then I've been at Bloomberg working in the Python infrastructure team, basically ensuring that our more than 8,000 developers in the company can have the best experience using Python. But for a long time I’ve been an extreme fan of open source, and since I switched from my PhD to Bloomberg I've been contributing a lot to open source, in particular I center on Python. So I started making the classic VR 2.0 documentation and there was a typo in the documentation. And that is true, that was my first PR into Python, some missing import in some docs. And there’s been a rise since then. I suppose people really like my type of corrections apparently. But yeah, out of the joke, I've been centering my efforts mainly on the Python parser and the Python compiler. Actually, I've been directing together with Widow and other core developers one of the major overhauls in Python when we switched the old parser for the new parser, which unblocks a bunch of the new features that you're seeing in the recent versions. And since then I've been trying to help a lot with the direction of the language, and I became part of the Python Steering Council three years ago. And I've been also having different other positions in the Python team. For instance, I've been the release manager of Python 3.10 and 3.11, which sounds very flashy, but it's just the person who pushes the buttons to get the binaries out, which is not the most fashionable job, but someone needs to do it and from time to time is good.
BP I mean, if you push the buttons and things don't work, then you're responsible. So obviously you have to have a lot of confidence to do that.
PG Right. One time we actually broke GitHub by the way. We renamed a master domain in one of the releases and GitHub gave us a 500 and it was down for quite a while. And it's recorded. We have that recorded, so they knew it was us.
KM I wonder if that's just because they do so many swaps behind the scenes. I want to follow up on one of the things you said, which was that you started just doing typo docs PRs, which I love. I tell people all the time that if you want to get into open source, that's the entry point for a lot of people. I've done tons of PRs to a lot of different repos and it's always just scratching my own itch. And those are always received so positively and warmly, so I think it's such a good entry point for folks especially who might not feel like they have the understanding of the whole codebase yet, but they can make an incremental improvement on things. What is the journey like going from doing a typo fix to updating core? Because I feel like that’s the ‘then you're drawing an owl’ part that I don't really understand. I’m still in typo-fix land.
PG It feels quite a lot like drawing the owl, and at some point you know how to do it and then you just forget how it was done. And actually let me add something regarding what you just said which I think is quite important for people that are listening to us and are thinking about doing open source. These typo fixes and these kinds of fixes to documentation not only is a very good opportunity to start, but also people that are starting are the best, because for us that have been working quite a lot with the project, we read the documentation in a different way. We already know these things and we don't notice if there is information missing or something is not clear or something is assuming that you also know some other part. So if you come to the docs and then you say, “I don't understand this,” you are the best person to tell us that we need to change it. And if you also do it, that's fantastic. But yes, answering your question, I think the key here is being very passionate, that’s one of the ingredients. As a physicist and mathematician, I would like to say that it's necessary but not sufficient. But the other thing, I think for me at least, that was fundamental as well, is having very good mentors. In my journey when I started contributing from that typo, I started to meet a lot of the people in the core dev team, and a lot of them actually have become not only very good friends, but very good mentors, and they have teached me almost everything I know in open source and they have always supported me and pointed me to resources and things. And that was very important for me as well, because coming in as a physicist, I knew how to code but a lot of the more computer science-y concepts were missing. But it is something that you can certainly do. I now maintain the parser of one of the biggest primary languages in the world, so it's certainly possible, even if you don't know anything about parsers, to become a parser expert in time if you put effort into it. So I suppose that drawing the owl involves passion, a lot of good people, and enjoying what you do, because at the end, nobody pays us for doing this thing, or at least in theory. So at the end of the day, we are doing this thing because we love what open source gives to the world and we like to contribute back, and that kind of is the fuel to keep going. So I think at least these three things are needed, then every person will have their own things that motivate them or why they are doing it. And most of them I would say are always valid. So you need to find also what makes you happy in open source, because otherwise it can be a bit challenging mentally. At the end of the day it's almost like a second job if you put yourself deep enough, and it's an unpaid one so it’s better if you have some fuel going on there. In my case it's learning things and friends, and this is also a very good opportunity for me to work with things that otherwise could be very difficult to work with. What is the last time you found a job that allows you to change something like the parser of the compiler of your programming language? That only happens mostly in open source these days.
BP So you mentioned a few times that it's kind of like having two jobs, one of which doesn't pay. Is there an overlap or a synergy between them? You mentioned that you feel like your role at Bloomberg is ensuring everybody there gets the most out of Python and is able to work with it. Are you taking feedback from them and then incorporating that into the open source work or vice versa– helping them understand the roadmap of where things are headed and therefore that it can kind of inform the direction that they're going to push their next set of technologies inside Bloomberg?
PG Right, that's an excellent question. With time this synergy has become deeper and deeper to the point that right now I'm quite happy to say that Bloomberg gives me 50% of my work time to also work in open source in CPython and some of the efforts that we are doing in collaboration, for instance, with Microsoft, and I collaborate with them and I have some time to do other things. So that's one of the sources of synergy. The reason that this is a deal that can be made involves a lot of trust from, obviously, my employer, so I have a good track that I know what I'm doing and it makes sense. But also it's interesting, because for a long time Bloomberg has been a C++ house. It was, as a finance company, very focused on high performance, and with the kind of data ingestion that we have, for a long time we have been using C++ almost exclusively. But right now, for instance, we have even more Python than C++ I would say, or at least have half. And we are very deeply involved in the Python world both as consumers and producers. So for instance, we not only give resources to the Python community, not only economic resources, but also time to work in CPython, for instance, in my case. But also we provide some of the tooling that now is used in the Python community, like some libraries that we have done like PyStack that are profilers and debuggers that right now are quite popular. I think the key point here is that I suppose you need to convince your employer that that is something that makes sense, which is the drawing an owl part of this deal.
BP Yeah. I think what you say is really interesting, and I've heard this before from other folks who were essentially recruited into a company, or because of their passion for something, their work in open source is super valuable to the company for a lot of reasons. As you say, you can then be sort of on top of the technology, not just what's coming down the pipe, but like you say, almost guiding where it's going. And then I think it's an incredible recruiting tool. People love to come to a place where they feel like they're contributing to something as part of their work that's part of the broader open source ecosystem, the same way it is with Facebook and React or Go. That is, I think, a big draw for technical talent, so it's a wise employer who gives the right employees that freedom to do that.
PG Absolutely. And we see it. For instance, one of the things I've been pushing quite a lot these last years is that we release new versions of Python on the day of the official release upstream. So when I, for instance, release upstream 3.11, I also release it inside and there is things that jump into the new version immediately. And because also Bloomberg is quite an old company and we used to have the fame of using old technologies and whatnot like Fortran and all these things, right now we have people that are interviewing with us that are super excited because they say, “Well, I'm choosing Bloomberg because I know that you're using the latest Python on day one when most of the tech giants are still in 3.8 or 3.10.” So that's, as you say, a very good point and becomes quite important for other parts of the company.
KM Do you have usage metrics for how many people are using Python 2? I'm sure it's not zero.
PG Yes, it is not zero. And something even worse, we used to have a fork of Python 2, but that's gone right now, or mostly gone. But I'm happy to say that it's very, very few. I think it's in the dozens, and it's just the kind of critical thing that nobody wants to touch and is just fine. But certainly those people need quite a lot of exceptions. But yes, right now I think the oldest version that we are dealing with right now is 3.5 in the sense that we allow people to use any version, but we give the same guarantees as upstream, so they are open to be on 3.5 until we just drop support. But 2.7 is almost gone. It's still certainly not gone, but we are close, so I'm quite happy.
KM As Ben mentioned at the top of the pod, last year I learned Python. When we interview folks, we allow them to use any language that they want. It's not important that you match that we’re kind of a .NET back end, JavaScript front end shop. It’s not important to us if you have a different background, as long as you can kind of relay programming concepts and idioms. And so I was conducting a lot of interviews at the time and I had a lot of people using Python, and so I talked to my manager and we made it one of my goals to kind of pick up Python last year just so I could be more comfortable in these interviews. It's kind of easy to read and grok things at a distance, but I want to know if you are using conventions that seem, I'll use that word, Pythonic. And learning that was just a joy. That was a really great experience. It was a great community and very welcoming. What I wanted to kick to you is, to what extent is that a very intentionally crafted designed experience, that this is a language that is available to beginners to pick up? Where do you put that intention into it– from the language perspective, from the framework, from the docs, from the community? What important pieces do you make to make it as beginner-friendly as possible? Because it does seem like it has that kind of tact to it, where not all languages carry that.
PG Right, right. I suppose one of the things I want to clarify is, depending on the person you ask from the Python community, they may give you a different answer and that is very important. For instance, being on the Steering Council, we need to take care that these different answers are taken into account. For instance, what people enjoy about it or find it easy to work with at a big company is different from someone that is using Python for education, and both answers will be valid. Regarding my opinion in particular, there are technical aspects of the language itself and from a language design point of view that make the language easy to read, or at least easy to reason about, and this is quite technical, I would say, although there is kind of a way to explain it. So for a lot of time, the way the language code evolved was quite restricted. This is because the language was using a kind of parser that is called an LL(1) parser. So this parser, I mean, we're not going into the details, but the idea here is that the parser is restricted to make sense of what is happening just by reading the next token. So if you're doing a for-loop, it can only know what you are doing just reading what is next. And this is not true in most languages. Actually, it's very rare to find a language that has this property. Python is not an LL(1) anymore since we changed the parser, but most of the language was shaped by an LL(1) parser, so what is very easy to read for one of these simple parsers is also very easy to read for a human, and that is quite important. When you're reading Python, not only is there this English-like feeling, people like to describe this as almost reading pseudo-code, but also there is this idea that when you're reading it, you know what is happening. You know the programming construct you're dealing with just by reading the next word, and that is fundamental.
KM So we had this early constraint that we needed to make it easy to read for a computer, and the corollary to that was that it became easy to read for humans. And now one of the things you've done is upgraded the parser so that the constraint is no longer there, but the language’s features are already baked. So you have that legacy of readability baked into it. That's cool.
PG Exactly. And there was a lot of discussion when we did that change to ensure that we didn't lose that, and that was always seen as a good thing. And right now, every time we change the language we have this kind of thinking about, “Okay, so how much are we deviating from this idea?” But you can still preserve that without the technical barrier. And the technical barrier also, as you can imagine, imposes some constraints that you don't really like, so it's not always good ones. And even if something feels very easy to read as a human maybe is not that easy to read for a machine. And you need to, as a language designer, know when is a good time to use the extra power that your parser has in particular. That's kind of the language properties, but on the other hand, there is this cultural idea for a long time that Python will be very easy to read and it should feel very straightforward. And that has been also incorporated in how people write Python itself. So when you read Python, there is this idea of if something is Pythonic or not, which has been abused quite a lot, I have to say. There is not a singular answer as to what is Pythonic, but different people have different ideas and that's fine. I want to say that that's fine. We think that there is not a single answer here. But in general people care about it and that's important. I don't want to imply that, let's say, C++ developers don't care about it. I'm sure they do. But the language then imposes some other things, and obviously it’s not going to be super easy to refer a beginner, but that’s more maybe on the language than on the person. It is very important that, for a long time, culturally we have this idea of, “No, no. Python has to still be a language for people learning and that's important for us.” And also culturally there was this idea of developing these programming concepts and idioms and how we do things in Python that has been always resonating with how we also develop the language in the core team just to maintain that feeling. But still, different people obviously will have different ideas of what is simple.
BP We can give the caveat that these are your opinions and not necessarily the views of the entire core team. I think the perspective is valuable. Certainly it doesn't mean it's all one size fits all.
[music plays]
BP All right, everyone. Thanks for listening, and of course, thanks to Pablo for coming on. It is that time of the show. We want to shout out someone who came on Stack Overflow and helped to spread a little knowledge or ask a great question. The Inquisitive Badge, awarded three hours ago to Trevor. Ask a well-received question on 30 separate days and maintain a positive question record. So Trevor, thanks for coming on Stack Overflow and being so curious. I see he's got a few points here for Python– Swift, iOS, JavaScript, and Python. He wants to learn about all of them.
KM Well done, Trevor.
BP Yeah, we'll link it in the show notes. As always, I'm Ben Popper, Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us with questions or suggestions for the pod, podcast@stackoverflow.com. And if you like the show, leave us a rating and a review. It really helps.
KM I am Kyle Mitofsky, a Senior Software Developer here at Stack Overflow. You can find me on Twitter @KyleMitBTV and you can also find me on Stack Overflow with User ID 1366033.
PG So I'm Pablo Galindo. I am a Python core developer, a Steering Council member and release manager. I work at Bloomberg in the Python infrastructure team, and you can find me online on Twitter mainly or GitHub, with the username pablogsal.
BP All right, everybody. Thanks for listening, and we'll talk to you soon.
[outro music plays]