Brett is a Python Core Contributor and leads the Python/VS Code team at Microsoft. We discuss his twenty years of open-source Python work, how to get involved today, the future of packaging, virtual environments, the standard library, VSCode, and more.
This podcast does not have any ads or sponsors. To support the show, please consider purchasing a book, signing up for Button, or reading the Django News newsletter.
Carlton Gibson 0:05
Hi, welcome to another episode of Django Chat, a podcast on the Django web framework. I'm Carlton Gibson joined by Will Vincent. Hello, Will.
Will Vincent 0:12
Hi, Carlton.
Carlton Gibson 0:13
Hello. And today we've got a special guest, Brett cannon with us who serve Python core contributor and works on Python VS code at Microsoft. Brad, thank you for joining us really excited to have you on?
Brett Cannon 0:22
Thank you for having me.
Carlton Gibson 0:23
Oh, no, no. We people who don't know you tell it tell us about you. Because you're kind of your longtime fixture in the Python community. But like, for people who don't know who does your backstory, how did you? How did you become a Python core contributor? What does that become? What is how did you find Python?
Brett Cannon 0:40
Oh, boy. Okay, the whole backstory. So when I was doing my undergrad, there was an intro course to the first computer science programming class. I'll preface this by I actually wasn't going to be able to actually major in it. I was actually a philosophy major, but I was trying to do enough courses because I'm old enough that I predate the bus, the first bus at the turn of the century. So it's like taking up courses and you get a programming job kind of thing. But there was a, there was a interest exam, and I was concerned, there's gonna be some object oriented thing in it, because I'd heard there's object oriented programming, because I'd only learned C up to that point. And so it was like, I should learn something to make sure I know what the heck I'm doing. And running around on the internet, back in 2000. It's two things just kept coming up Perl and Python. And I read enough that people seem to says pro should be the sixth language you learn while Python should probably be your first. So I was like, Okay, I'll go learn that one to figure out what the heck this object oriented programming thing is. And I have not looked back. I've been using Python ever since the fall of 2000. And that's how I found the language in terms of the core development team. That's another quirky story. I basically needed stir pee time, which isn't the time module on Windows, and at the time, it didn't exist. So I created it. And you had to enter all your locale information manually, like what are the names of the months. But it basically did the right thing in terms of the percent like D for dates for day of the month and all that. And that ended up in the first addition to the Python cookbook from O'Reilly, which Alex Martelli was the editor of. And it always bothered me that you had to manually enter the names of the month, right? All that locale information, like why am I having to write this out stir f time this thing over here that is on every platform, because it back then it didn't realize what lib C was, that's on every platform, but stir p times not like, how, where's that information? I want that information. And I just bugged me in a constant thought about it just when I walked to class or whatever. And then I eventually had that aha moment was like, Oh, well, I can just, I can reverse engineer, I can call ster f time to tell me the name of every month. And I can just catch that. And then magically, I will have the names of every month because St. Peter and Mr. Epstein use the exact same format strings. So I graduated. And then the following week is a graduate graduation gift to myself. I wrote up that code, put about a cup online. And then I Yeah, shows you how little warped I am I finished school. And within a week I my fun time is oh, I'm gonna go write some code. So I did that. And then I emailed Alex Martelli, just saying like, Hey, I think this might be useful in Python in the time module, because it's not there on Windows and so on other platforms, and said, Oh, well, you email this mailing list called Python Dev. Let them know what you want to do, and they should be able to help you out. So mid June of 2002, I did and Francoise Picard, actually, of Philippine from Quebec back then explained the process to me. I submitted a patch to Sourceforge for those of you who know what that is, and lo and behold, it got in. And at that point, I was taking a gap year between my bachelor's and grad school because I had gotten my bachelor's in philosophy, but I decided I wanted to go to grad school and computer science. And so I kind of was fishing around for a way to build a programming portfolio as it were to prove to grad school programs. I know what I'm talking about. I'm not just some random person who finished school in philosophy and just randomly wants to become a programmer is like, no, no, I was studying into courses and I know what I'm doing here. And at the time, there's something called the Python Dev summaries that had stopped previously, because no one was writing some basically a semi monthly summary of what was going on the Python Dev mailing list. And I was taking a gap year I had the time so I was like, Yeah, this has been fun. It's been a good experience getting involved and getting this passion. Why don't I just take that up? Because I just stayed on the list of interests. And then come, I think was mid August 2002. I started writing the Python Dev summaries twice a month. And it just kept doing that. And it put me in an interesting position of, I'm sure Colton kind of relate to this, of when you read all the emails you meet, you get to know about all the problems, which means you get first dibs to solve those problems. So what ended up happening was, I would immediately know when there was a gap or some little bugs that need to be fixed. So I'd get to it before almost anyone else. So I would immediately just go do it. And so I just slowly learned about the code base plus I was trying to understand what was going on. So I was in the perfect position to ask those quote unquote, stupid questions, and not feel stupid about it, because I had motivation to understand. So I just kept doing that, and doing that and doing that. And then at some point, I just said, Oh, I'll take care of it. But once again, I'll just need someone to commit it. And a Guido emailed saying, what? Can't you just commit yourself? I was like, No, I don't have commit race. I'll just fix that. And so April 18 2003, I got my commit rights and made my very first commit on my own. So I am, I think, exactly is the today's recording one week shy of my 20 years as
Carlton Gibson 6:12
well. Well,
Will Vincent 6:13
so this was before you started as
Carlton Gibson 6:16
well. 2020 years, but that, congratulations. That's amazing. And what a, you know, massive contribution to the Python community over that time.
Brett Cannon 6:25
Oh, yeah. Well, thanks, I'm happy, I'm glad to have done it. I mean, I'm not going to shy away from the fact that I've gotten lots out of the community, right, I get to meet wonderful people, like the two of you and everyone else, right, I get to have an employer who cares enough to employ me. And also I get to let them pay to send me off to see and hang out with friends once a week at Pycon and whatever, and gauge all the conferences and I've definitely benefited as well. So it's not not a one way street in terms of how I've given to the community, the community is definitely given back to me.
Carlton Gibson 6:54
Go move, you're gonna say something?
Will Vincent 6:56
Oh, I was just gonna say so it's not so that was the spring of your gap year you got the commit rights? Correct. Is that the timing? So that when you rolled in, in the fall cycle, your philosophy major, it'll be like, Yeah, but I'm a core contributor to Python. That must have been?
Brett Cannon 7:10
Yeah, but you have a context. Back in 2003, most people didn't know what the heck Python was. Right. So I went off to my master's program, because once because I only had my bachelor's degree, I kind of had to hop up to the PhD level. So I went and did a master's at a separate school, before I went up to do my PhD. And the funny thing about that was, people would ask, like, what do you do in your spare time? Oh, I watch movies, bla, bla, bla games, and oh, I contribute to Python. And the answers always fell in two buckets are there? What is that? Or was it that language? That weird language of whitespace matters? Right? It was not a flashy thing. It was just a group of people I hung out with online, who I found who all turned out to be friends. And were just a lot of fun to work with. And a great learning experience. I just love doing it. But it was not for fame or fortune at all. back then. It was like, What the heck is this thing? No one had any clue. Right? Like, I was lucky enough to get involved. Before the hockey stick growth Python kicked off, which I would say probably really started in earnest. I would honestly say around 2006. And so I fully admit my success in this committee. I've always said, Success comes down to luck, skill and risk taking. And I just happened to hit Get to hit all three at just the right time, the year of 2002 to end up where I'm at. Right? Like it was just total luck. I got involved when I was the youngest member of the core dev team as a person having finished school. We've not had people join on the core dev team who are still in high school. Right? So total luck. It just totally worked out
Will Vincent 8:56
wonderfully in my life that this all worked out. So I don't know if you know this about Carlton, but I have to ask about the philosophy like so. So why what what about philosophy Did you like I mean, because it's it's an art but of the arts, it's in many ways, the most rigorous in to kind of ports over pretty well to things like programming.
Brett Cannon 9:16
Yeah, so actually, funnily enough, I got into it because I made a promise. My mother made me make a promise to her when I started my undergrad. Actually, I went to junior college for those of you from getting a degree that doesn't
Will Vincent 9:29
pay is that what it was? No, I'm so.
Brett Cannon 9:34
Sorry. So when I graduated high school, I went to junior college because I just didn't have enough money to go straight to university. And when I did that, my mom made me promise her that I would take two courses, a philosophy class and a computer science class. Because that point, I've actually been doing computer stuff but like it was more like games and add minis kind of stuff, not rope. I didn't really know what programming totally was. I had a concept but no one had really told me like You seem to have a lean towards you seem to be adept at doing it right. Like, I had programmed in Apple basic in a summer course. And ugly the entire summers course in a week. But no one kind of it didn't click in my head that oh, that's a suggestion, maybe you're good at this, it was just Oh, I got it done real quick. Okay, cool. I guess I'm just a good at studying or something. So just hadn't clicked. My mom picked up on it, though later in said, like, now you should take a course. So I took a course in both and absolutely loved it. And at that point, I actually plan to double major, right, because the philosophy was the passion that I absolutely, and I was talking about computer science, but that was going to pay the bills. And the problem is I went to junior college and trying to double major, I ended up taking so many units that I ended up going, I went to UC Berkeley, which is part of the University of California system and California, which is a public university. So they actually have a unit cap to make sure that you don't become a lifelong student and take a slot from someone who actually needs it to get into university to actually get their degree. The problem is actually took so many units trying to double major, that I actually found out that I wouldn't be able to double major without getting kicked out of the university. So I actually had to choose which major I wanted to do to actually guarantee I would graduate. And at the time, there was a chance that when I transferred into the school, I still had to get accepted by the major I had been accepted at the university but not the actual department. So and philosophies acceptance was you walk into the office, say I want to major in philosophy, they ask Are you sure? You go? Yes. And they get Okay, fine. And sign the paperwork, computer science, whole application process, all this other stuff. So it was one of those? Do I guarantee I graduated with a philosophy degree and once again, early 2000s, boom, time, take a couple of computer courses, you'll get a job? Or do I try to get a computer science not get in and they get kicked out of the university before I could even graduate. So I went the safer route did the passion that doesn't pay with the assumption I would eventually do enough to actually get paid for the other passion. And here we are today.
Carlton Gibson 12:03
Let's get that recruitment put that admissions policy the philosophy is kind of internalist. It's like, Are you sure? Yes. Well, you're Yeah, that's nice.
Will Vincent 12:12
Well, you may or may not know, so Carlton has a PhD in philosophy. And so I'm constantly he actually I find that he wrote something about the LLM 's and, you know, philosophy because he's always like side chatting me all these deep thoughts. And like, Dude, come on, put put something out there. Like somebody needs you sit in both worlds.
Carlton Gibson 12:30
Just Simon's something. Wilson has been writing these pieces about them that they've been following along what he's been saying he there was this discussion about whether you can fairly describe them as lying or, you know, whatnot like that. It's, you know, first of all, it's just a metaphor. And there's lots of metaphorical utterances, which aren't literally true. So yes, they're lying. Let's go with it. Let's not stress about it. But secondly, I think a good analogy is that they're doodling, they're sort of, they're not trying to make a representation. They're just working away, you know, and it's not your doodle looks like something or doesn't is kind of an accident of history, and in their case, an accident of the training data. So
Brett Cannon 13:05
I took a class with John Searle. So the argument for anyone who has heard of that, so I am sure he's loving this right now, based on that course that he's loving. Everyone asked about MLMs. And whether there is general AI, like I can totally be in that course, right now. Totally picture him going like, well, you know, based on the Chinese room argument, they're nuts. They do not understand what they're doing. And people feel free to read the Wikipedia page for anyone who's interested. We don't need to get into that. But no, I did not know that Carleton. That is That is awesome. And actually, it's surprising. Not surprising. Honestly, there's a lot of people actually in the community who actually do have degrees in philosophy, I keep finding. And honestly, I think it's just the deep thought and just trying to make the connections is kind of tying back to programming. That's what it is, for me, at least Yeah, when
Carlton Gibson 13:53
I started out, people would always say, I'd be going for jobs. And they'd be like, Well, how did you get, you know, I had a PhD in philosophy, and I could program and they're like, Well, you know, what's the, what's the connection? And I was, you know, in the end, I was like, Look, philosophers have always constructed models of the world. It's just that if you program you can do it in a medium, which enables you to move stuff. And so programming is just philosophy from one way of looking at it, you know, but with SuperPass, its philosophy with SuperPass.
Brett Cannon 14:20
No, yeah, exactly. Right. Like if you think about it, like I got that question constantly was why, what are you going to do with the philosophy degree? And then I'd say, Oh, I'm gonna go to grad school. It's like, well, how do you make that jump? And it's always like, well, if you want to go the cheap route out, it's symbolic logic, right? Like if as long as you get handled smug logic aspect of philosophy, that's basically what programming is. It's just down at the silicon level to the CPU. But afterwards, from there, it's more be able to take the minutia and the small bits of an argument expanding up to a larger system, or vice versa, right, looking at a larger problem and how do you break that down into something where you can logically work your way back down into the finite pieces that you feel like you can and structurally support in terms of an argument. So that the overall argument that you're making holds. And same thing with programming, right? Whether whether you're given a large task that you need to break down to the small aspect that you can mentally understand and break down to a function or whatever, or starting out, like, oh, I have this thing, oh, well, you know, if I plug that in with this Sunday opens up this system, right. And that feeds more into almost API design, right? Where you go from the small bit bigger, bigger that site, how to plug these pieces together and get this bigger system. It works both ways. And I think philosophy just ties into that part of our brains of working both from small to big and big to small and just broken is basically that just a very little bit more rigid logic aspects where it's a little bit more repeatable, at least in terms of what you put in and get back out. Ignoring qubits in quantum and all that.
Carlton Gibson 15:48
No, I mean, yeah, I think I agree entirely. It's it's that parallel modes of thought that it's not the big dream, but it was a big question when that so I just want to pick up on a couple of points that you made. And then we can move on to perhaps talking about Python, this Microsoft and VS code and other packaging and all these other things we've got on the list. You said that learning contributing to output to Python gave you something to show it gave you a thumbing through your portfolio, it gave you the kind of learning opportunities, you're watching the email, mails come in, and it gave you meeting the community. And, you know, and just as a kind of summary of why contribute to open source, I think those three kind of highlights, I just want to pick out that you hit on those, as you know, why contribute? Well, because it gives you all of this back?
Brett Cannon 16:38
Exactly right. Like, it's I've literally gotten my jobs because I was able to say, Well, what's your experience I've contributed to here, you can go look at the commits, it's very obvious what I'm capable of. I don't have to question it, right. Like, as someone who's had to do hiring as a manager, I have to read CVS, more or less. And protip. Everyone else, assume the person who read them is going to read them in the most negative way possible, like I contributed to this 51. Okay, so you brought coffee, or tea to the people on the team? That's right. Like, if you're not concrete about it, I have to assume that you're stretching the truth, because almost everyone does on their CV. And you can't lie about open source, though, right? Like if the commit logs show that you did it very cheap, very likely, you wrote it. Now, obviously, someone could have written it for you, and it was in person personating. probably find that out pretty fast when you got hired. But otherwise, it's a very straightforward dude to do that. Right. Once again, also learning opportunity, right? There's some great code out there to read and learn and understand how it works, right? Just how the heck did they make that happen? I mean, honestly, I kind of missed that magic, because I know a little too much about what happens behind the curtain now that I don't get to go like, really how they make that work. I mean, you still have that right, like LLM still kind of have a little bit of that for me in terms of, I know how neural networks work, but like how the exact build in all that works. So little magical thinking is, but does anyone know how they work? I mean, isn't that the thing? Oh, to an extent, right. Like, I'm not gonna, I'm not gonna worry about the internal results and all that. Yeah, that's a whole nother conversation. But yeah, like having that opportunity to actually look right. Like, I kind of missed that on the web, right back when you could right click and see each view source and actually look at the JavaScript on how the heck did they make that happen on that web page, we don't get that anymore with all this minification. All that because we have to shrink all JavaScript to be a meg, say instead of back when it was like, you just shift it raw and how you wrote it and just didn't care. And then once again, as Golden point about the community, right? I've been doing this for 20 years, I have friends that I've made since I started being a core developer that are still friends today, who I still look forward to seeing every year at usually PyCon us or any other conference, I run into them, I still chat with them, right via whatever mechanism whether it's email, Discord, discourse, video, chat, whatever. There are people who become friends outside of the conference circuit as well, who I've gone and seen on vacation. Like, I've been extremely lucky that you end up building this friend group. And it's some part of it's technical, but also you start to learn about each other's people, and you just become friends as people. And yeah, it's been amazing.
Will Vincent 19:21
So speaking to communities, Carlton, I have often talked about how with Django, there's a sense that Django is large and mature. And it's, you know, it's not the early days, I wonder if you could speak to you since you're involved with Python, right? It's Python is also a different place now than it was 20 years ago. And so it can feel like you know, there isn't just all these low hanging fruit or it doesn't feel like that, right? You see these issues that have been there for 10 years for a reason. And so how would you advise someone today to kind of get into Python or other places are these more mature seeming places where there just isn't low hanging fruit all over the place? Yeah,
Brett Cannon 19:57
I mean, it's tough, right? Like I remember the first PyCon when everyone showed up and showed off Django for the first time, right? Like, I've been around that long. And it's projects end up at different places in their lives, right? There are the new projects that need a lot more help and a lot more low hanging fruit. And then you have projects such as Django or Python or whatever that have been around so long that usually if an issue has been open for more than a month, there's a reason. And especially if it gets measured in years, there's definitely a reason why no one's touched that. So it's tricky. Right? I will fully admit it's hard. I will say, lately, the way people have gotten involved directly with Python itself as an example, the people who have done that have usually either come forward and just just started helping, right, they started to help triage issues, they started to leave good code reviews, they started to ask appropriate questions. A lot of them kind of just hung out for a while and just listened. And then we'll just pop in and ask like some clarification questions, but a lot of it's just been helping with the stuff that helps give more bandwidth back to the people who have maybe the better skill set and just based on knowledge and time to handle the higher, bigger hairier problems, the sticker ones. And other people have come in and go like, Oh, I've noticed there's part of like the standard library. It's been neglected. And they come in and start really helping with that. And so it's a bit more nice in but much more focused on Bernie Gail is a perfect example. He just became a core developer. And he stepped in and started help out with Tatlin. And he just said, like, yeah, you know, I'm noticing this isn't really getting a lot of attention. There's no kind of active core developer who's like, heavily focused on that right now. So he just came in, looked at the issues and like, yeah, that's a bug that could get fixed. And, you know, it'd be nice to maybe have this would that make sense. And at the time, I was kind of keeping an eye on pathlab, but not really driving it. And he just started to come up. And he's like, I have this idea. And we talk it out. And I just tried to explain like, that's a good idea for these reasons, or that's not a good idea. For these reasons, try to impart some of that knowledge, and you just got better and better at it. And just starting to Kansas is a good idea. Yep. And just start to get it right more often than not, and continue to continue to continue, are then stepped away from path lib, at the beginning of this year, just to kind of not spread myself so thin. Other people stepped forward to help mentor Barney. And he just got to the point where people just kind of were almost rubber stamping his contributions, then someone says, Well, why don't we just make them a core developer. So we did the vote, he got it. And now he's managing pathlab on his own. And there's lots of other people who started as triage errs, and just were helping out and just could perpetually helping out and just conventionally showed that they could just be trusted. And so they got them at rights. And now we just trust them to do the thing that they need to do.
Carlton Gibson 22:48
I will say as well, that triage is a great way of learning because a new ticket comes in and you're just like, I have no idea what's going on with this ticket. So you have to find out and if you you know you do you, okay, you reproduce it, and you dig into the bit of code that's causing it and you'd like, Oh, by doing that you become kind of the world expert on that bit of code. You really learn it, and you're just it's such a useful if you don't know what else to do triage some tickets. It's, it's awesome. You mentioned the standard library, Brett, can I? What's the state of play though, like, cuz there's this idea about removing some batteries, which is good, especially the old ones. And then I posted a thing about how I really wanted to write an HTTP server and h h async. IO. And I'm like, but I need to bring in an HTTP parser. I'm not writing an HTTP parser. Why isn't there one in the standard library? So I invented off on that, and we had a little back and forth on fostered on whatever. Is it not maintainable? Is it that we can't bring more fresh batteries in? Is it that we need more contributors to be able to do that is is it that actually, the better way forward is to strip it down and become more nodi? What's your thought? Okay, so
Brett Cannon 23:54
there's what I'm actively doing to address this. And then there's my personal opinion, which is not necessary. So I will start with both. So I'll start with what I've been doing to try to drive this conversation, and then I'll end on my opinion. So first of all, been a member of the steering Council. I've seen what and have been involved, as long as I have, I've seen what it takes to get something in or out of the standard library. And I think it's rough. It's basically roughly maintainable as is, but I honestly think it's a bit personally, I think it's stretched. Before we did the last clean out of the standard library, which just happened for the 311 release, where we started to get a bunch of stuff. There were more modules in the standard library at the top level, and I'm talking about sub modules than there are countries in the world. And we all know we can't name every single country in the world unless you somehow on an odd talk show as being that eight year old who's just got some great memory. So I think that's a lot and that's good. eventually too much for the size of the core team to maintain. And I know some people immediately then say, well, why can't you just get more developers? Well, core developers don't grow on trees, they take a while to nurture and get to this point. And not everyone's honestly built, as it were to use a phrase for maintaining Python. It's work and dedication. And you have to build up to that level of trust. Because the way the structure of the project is, is people aren't really monitor or watched once they get the core bit, or the commit that you're just trust to do the right thing. So we can't just let anyone just walk off the street and saying get to do it, you kind of have to show that we can trust you. So there is a limit, a finite amount of people power to keep stuff going. So what I've done up to this point was I more clearly defined as part of the steering Council, what it takes to add or remove modules from the standard library. So it's a bit more gated before graph, for instance, graph flip is a good example that was actually just added by some core developers who just thought it was a good idea to have, but it didn't really go through anyone or any process really to get at it. Now, I can't even remember which pep it is now. I think maybe pep four. Can't remember. Okay. But basically, it's now written down in peps that to add something inside library has to go to the steering Council. And to remove something from the standard library, it has to go through the steering Council, we've also clarified a backwards compatibility policy and made that official so that people know that, except for extreme years, extenuating circumstances, everything will be upgraded for at least two Python releases, which is two years, we try to go longer if there's, if it makes sense, it's not gonna be strenuous to keep it going like five years, because then at least you can have an entire lifecycle of one release before you get told you gotta get off this. But the other thing that I'm doing is now that we have a way to manage it in terms of coming and going at the language Summit, PyCon. US this year, I actually have a talk, which is literally titled What is the standard library for? Because what I will say is being a member of the steering Council, I honestly don't know what it's meant to do. Right it up to this point, it's historically just been what Guido thought should go in the standard library. And once again, you have to think about how old Python is right? I've been doing this for 20 years. The project is existed as open source since February of 1991, which predates Linux, right? Like, Guido worked on one of the first graphical browsers, like he was working on a project called Gradle. That was on track to be the first graphical browser of the internet, and then NCSA Mosaic beat him out the door. But it came about in a different time. And I don't think we've ever sat down and had a conversation of Well, based on the existence of pi pi, which back when I was around when it first started, we wanted to call the cheese shop. But we were too worried about managers being upset over something called The Cheese Shop and not taking Python seriously. API. By the way, just go to a 404 page on on pipe here. And you'll find that Monty Python schedule explained that reference. So I don't think I circles Well, I just don't know what's meant for anymore. Right? Before it was the cheap way to distribute code. Because the community was so small, like anything that got any decent amount of usage around the planet, man, if it ended the standard library, more people would use it, and it more easily got to those people who needed it. Now that we have a world where we have installers, and we have, you could say two of them, at least with PIP and conda. In terms of those kinds of split of the world. I don't know what it should be. There's no thematic explanation. There's no PEP, there's only informational Pep. So as a string councilmember, I have to make a personal call. And I don't know if that really matches what everyone else expects. So at the language summit, I want to have a conversation to lead towards an informational pep that kind of outlines what the general guidelines should be for what should be in the standard library. Now, before anyone panics, this does not mean I'm then going to immediately clean out the standard library based on what that Pippins. So don't
Will Vincent 28:57
get a title for the podcast. Yeah, exactly. Fred says it's gone.
Brett Cannon 29:01
So that's not what I'm suggesting here. But I would like to be able to point to why something's in the standard library, whether it was grandfathered in, right, or that's there. Because we've agreed that you should generally be able to accomplish blink based purely on code from the standard library, because I don't have that answer right now. And the steering Council does not directly have that answer anymore. And so I want to get that written down. So that's where I think we're going with the standard library. And that's gonna, I think, kind of dictate kind of size and scoping and what's in there in terms of what we can maintain. And I think that's a follow on conversation from this, right. Because once we know kind of what the proper scoping of the certain library is, that will give us a better idea of, well, do we feel restricting ourselves too thin? Or, actually, if you look at what we're keeping, because we think it belongs there for so what's grandfathered, does that scope make sense and all that. I think that's a follow on conversation from that.
Carlton Gibson 29:53
Yeah, no, I mean, I think my sort of feeling on that is that when I first got into Python, the ability to just Write almost just lots and lots of things without needing to download anything else was just a superpower of pythons. And that batteries included thing you can do the core programming tasks of your day to day life with just with the materials that shipped in the standard library. That was amazing. I I'd like that to be maintained somehow. I don't know, you know, that's just like, you
Brett Cannon 30:24
know, exercise. It's just my question of is, what are the workloads that we should consider?
Carlton Gibson 30:32
And how does it get done? Right, like,
Brett Cannon 30:33
like, so crawl tonight, as you mentioned, we're talking I Macedon about this because I kind of threw some of these things out there and caught somebody was like, How is there no HTTP parser. Right, why can I just use this to almost write my own HTTP server is like, well, is an HTTP parser. Even the right thing for the salary? Because you could also argue, and I've heard this from some people is the standard library should only be what is required to make Python run and what is required to bootstrap in and installer, right, which isn't even necessary that because at that point, you could potentially do your own little Euro lib that only that has a Fetch API that gives that all off to the OS and just says, you figure out how to talk HTTP, I don't care, you handle the certs? I don't care. Just somehow, let me download Pip. Let me download conda or download whatever your installer is, and then I'll let that handle however it wants to handle things. Other people are the more sumo approach of like, I want the world because I want the minimal amount of stuff I have to download, I want to be as as maximally beneficial to me. And everyone runs the gamut in terms of what should be in there. Is it more networking stuff? Is it more sysadmin? II stuff? Is it data science, seeing numeric stuff? And I don't have an answer, hence why I want to have this conversation and get to a final answer. Because every time this conversation comes up on the core deaf team, it runs the gamut. And it's one of those no one wants to touch it with a 10 meter pole. And so I'm just willing to say, No, I don't want to run from this anymore. I want an answer. I'm going to ask the room, I will write a pap, this during Council will hopefully either accept or reject or will somehow reach some consensus. And that way, we at least have some under shared understand because right now, there's just none. And I just It bugs me, I want that shared understanding. I don't want to I don't want to keep running from this. I want us to work towards that kind of shared and st because also for the community, right? Because people shouldn't randomly have to go with maybe this should go on the satellite where it's like, well, I don't think so. Or I think so. But I don't know what that would would Jane over there things right, or Bob over there things. And you got to figure out whether everyone agrees on that. Like I'd rather be able to just say like, Well, do you think it matches what's in this information? If you think then yeah, we can talk about if not, yeah, I wouldn't I just don't worry about it. Just put up on pi pi. Let's communicate that way.
Carlton Gibson 32:59
Okay, that's awesome. That's really good explanation. So difficult question difficult conversations in which no one can agree on can we? Perhaps Can I ask you about packaging there? Yeah, let's just, let's just cut through all the all of them while we're here. I think there's a background to back to packaging. And it's a difficult situation. It's in flux. No one quite knows what's going on. Perhaps for our listeners, Could you perhaps give a background of the recent changes? And what why? Why is it all changing, perhaps to start just to give some backdrop, and then we can kind of discuss where we're at?
Brett Cannon 33:34
Yes, but I will have to go further back than just recently. So once again, weird history lesson. So I think one thing that a lot of people don't realize, is after they have after they internalize the fact that Python is older than Linux, they don't realize what Python is packaging. Sorry, it also predates pretty much everyone except Perl. Right? Everyone goes, Well, why don't you do it like Node? Why don't you do it like Ross? Well, you do know we predate those languages and runtimes literally not just a packaging story. So that usually takes people mental thought to go, oh, there's history here. So part of the history about all this right is how all this came about, which once again, actually came about a lot of icons. And that's PIP instead of tools, which actually Pip was predated by Easy Install for those who've been around long enough. And so for the longest time, all the faxing was basically just set up tools. And that was it had to make it work. And by the way, these all started packaging in Python, right, because I'm from a day where I went to the vaults of Parnassus, which was a website with little animated GIFs with a bunch of zip files that you download it into zipped into the directory with your code, right? None of this fancy SRC directory stuff with editable installs. No, I didn't have any of that stuff. Right. I had to walk up uphill both ways to download my zip files when I was a kid. Right, although it was not getting admittedly. So the thing was is Central's kept doing its thing, it's served as well. And all that stuff. Same with weapons continue to do that. But obviously, there's a lot of convention and a lot of baggage based on the fact that these projects come from the arts and the early aughts, right, like we're talking decades. And so we ended up happening was when I got involved with PAC gene, after I finished import, live in that whole important migration, I decided, alright, what's the next crazy thing I'm going to tackle and come to regret. And I decided to dive into packaging, obviously, is the seat at that one. I realized that we were kind of in a position where moving was hard, because it was always the risk of breaking people and breaking their code, right. And so what kind of happened in the packaging community at that time was other people started to have that similar realization. And so what we've ended up doing is we kind of broke the stranglehold of setup tools, and are kind of working towards of where world we're being a pip doesn't necessarily become the only thing everyone aims for conda. Because if you think about it, we the goal was to get from, you have to use setup tools to use setup tools, if you want. And so what that really led to was Project automall, right, that file. And the first part of that was defining what your build system was, which let you basically say, hey, to build this project into a wheel, this is the tool you need to install. And here's the API that that your build tool should call to your tooling should call the bank, make your wheel. And then suddenly, you didn't have to assume there's a setup.pi. You didn't have to try to go like you know, I need something but set up, set up. The pie doesn't meet that. So but I have to meet their API, which is a little under specified and in funky, because once again, historical reason I'm not throwing any shade on the set of tools team at all. I want to be very clear about that. But they obviously had, they had backwards compatibility concerns that limited what they could do, and also constrained what other people could do because they felt they had to match what they did. But by switching over to this new API, suddenly it opened things up and saying, like, oh, you know what, I could write my own build tool and the tools that need to potentially install from this test or do with the build. As long as I match that API, I can do whatever the heck I want. And so suddenly, we start to have this proliferation of build tools where people can have the tool that meets their needs, whether it's flit, which I know Carlton's a fan of, or hatch, or poetry, or hatchling, technically, or poetry or Maturin, for rice, or a whole plethora of tools that now exist that meet the needs of those people for their for the building. And then what's happened after that is to try to continue to move down this road. I helped spearhead PEPP 621, which led to all the project metadata going into pipe Project dot tunnel, right. So historically, that would have been your self.py, your setup dot cfg file if your setup tools user. But the goal there was to make it even easier to switch to the tool back end tool that made the most sense for you, right? Because when you standardize how that metadata gets written by a human being, instead of spent centers in how the metadata adventure gets written out in the wheel file, it makes swapping between tools way simpler, right? Like right now, if you wanted to go from old setup tools, instead of dot parse, dot cfg. And switch to flit for an example. You have to migrate from one file type to another one, right? Because flit uses pipe project. Yeah, no, I mean, but if let's say you're already on pipe project, dot Tamil, and go like, Oh, you know, let's think about I want to get hash Lena try, the delta of change is minuscule. And because of that, it makes it way easier to use the tools that you want. And once again, here's the other thing is now all of the blog posts, all the tutorials, all that stuff is very generic to the common part, this part project automall And then the individual tools just say like, oh, I add this feature set you have you can add this if you want, but at least this is common and everyone understands it. And so that's been the big push is trying to get the things that are common across tools to be common, but also even make it possible to have other tools because I think this is another stumbling block a lot of people have when they look at packaging and feel like oh, it's so confusing. There's so much stuff it's like well, you because you're joining now few viewed as confusing and detrimental there's so many tools those of us who predate back to setup tools days view this as a renaissance time and pegs you know Python because now I have options. Right? So once again, it's all about perspective and ROI ya know, super. So yeah, that's that's kind of where packaging has ended up right is trying to give people the option to have choice but also trying to make it so that those options at least from a perspective of standardization aren't aren't competing with each other and not stepping on each other's toes in places where it's not necessary. And that way the tools can actually try to actually innovate, where it makes sense for them to innovate and try to share across the board where it makes sense to share. And that's really where we've ended up.
Carlton Gibson 40:16
Okay, that's, that's a really great explanation. I want to pick up just on the one word you uses, which was confusion, because you're confusing, because from the outside, I'm not, you know, I'm 20 years using all this stuff, and, but I'm like, Ah, what's going on Windows, there's too many tools and witches. And the reason that I do like it, I like flip, because it's really simple. And it seems to do just that one thing really well. And I think even if this goes totally wrong, I don't feel I'm really committed into a tool that somehow I can't escape from. And I see all these other tools. I think they're probably great. But there's just so much going on from from the inside it could there anything you can do to alleviate that? Or do we just have to live through this period and pick one and go with it and give it a try? Don't be scared? What how? What would you say? Because I am literally I am genuinely confused. And because I haven't got the time to read every pap every time and you know all these things? Well, so hopefully
Brett Cannon 41:18
the peps you shouldn't have to care about the tool should be handling all that for you. It's those of us who are knee deep in the packaging ecosystem, it's on us to come up with the peps and worry about getting them pushed out and all that. So first off, don't worry about reading the maps.
Carlton Gibson 41:33
But all the doc's do say at the beginning, oh, this tool implements pet this number. And it's a bit like, yeah, that's not feature benefit reason. That's not like, you know,
Brett Cannon 41:43
no, not at all. And unfortunately, though, that's not something any single entity can necessarily control, right, because there's no normals. I think the other tricky bit here that we have is, when the tooling opened up, and commonality started to spread, everyone started to look for their their niche somewhere else and sort of push out the boundaries a bit more, right? When it stopped being Oh, I can just build a wheel to or I can build a wheel and also create your virtual environments. Or I can build your wheel and also help you set up your test environment. Or I can build your wheel and help you do this other thing. Right, I think that's the what's also happened here is it very quickly went way beyond just build tool, right? Because that's way simpler to build tool plus stuff. And they become workflow tools, right like, because if you think of just build tools, it's literally just like, it's like set of tools. hatchling flit, right, once again, have seen flip very simple. We all know set of tools, there's potentially Maturin, right? If you're doing rust stuff, but that's once again, very specific to areas, there's like sacred hip, which once again, very specific, right. But that's just the build tool. The problem is, then we suddenly get PIP env, we get poetry, we get hatch, and all this. And then that's ignoring the old ones, right? Like virtual env, wrapper, and all these other things that are also these tools that try to help you manage your workflow, you typically through some virtual environment manipulation. And once again, conda is sitting over there in a corner doing its thing as well. So I think the problem is, is it's, it's packaging is now being grouped together with workflow. It's not even packaging, in terms of what you upload, the pie is now packaging plus stuff, and everyone's viewing that as a single packaging thing. And so I was going, packaging is really confusing. It's like, I can understand that. But I want to be very clear about terminology here, because people I think, are getting very broad about it. And in what's coming to us who have been working on getting literally how to get a wheel bid as streamlined as possible. And going, it's all real confusing. That's true, I understand where you're coming from. But you also have to understand you've stepped a level above where we're coming from historically. We've not told people how to manage the virtual environments, we've not told people how to have task runners like toxin, NOx, or anything like that. Your project layout, people have even started to come to us and say like, Hey, how should I lay on my project? Like, honestly, that's none of our concern. We're just trying to help you get a we'll file. But everyone's now asking us for everything that leads up into that we'll file to own that part of the workflow. And I think that's part of what's happened here is people are just asking for more and more at which I mean, I think we're all used to because we've simplified the lower bits so so much, and I would like to think so well, that they're not even concerned about that anymore. But I will say is there's an active conversation going on right now on discussed python.org about potentially set up a packaging Council, similar to the steering Council, where we can potentially have a bit more of a focused group of people whether it's three or five or who knows it's it's an open question, who kind of helped drive more coherent vision of packaging to kind of help with some of these scenarios right to say like, this is within scope. This is out of scope. Let's what can we all work towards? Because right now it's all done via peps. And there are two people who technically become pet delegates automatically for packaging, perhaps. But it's just kind of their opinion, they don't want to be the person who gets on the hook necessary all the time for every decision. There, they have their needs, but their needs don't necessarily represent the whole community. And they have to then try to keep up with all of it. So it's not not so I don't want to make it sound like I they're not representative specifically. But obviously, it's harder to be representative when you're one person versus a council five. Right. So
Carlton Gibson 45:31
that, that that that point about not wanting to make the decision, like all the time, like, you know, to having just stepped down as Django fellow, it's like, you know, actually to have a steering council that you can say, hey, can we ask for a second opinion here? Because we don't want to always be making a decision, because we're just a couple of people trying to do the best we can. And we don't know. Yeah,
Brett Cannon 45:50
and I will say, actually, psychologically, people seem to do way better when a nebulous group of people say no versus an individual. Right? Like, if Brett says no to a pet, it's way different than the steering council said no to a pet. It's like, well, I don't know who to be mad at or are at the steering Council. It's a group of people who potentially make more wizened decisions, then bred over there, the silly guy from Vancouver, Canada, made a decision, I can completely disagree with that and get angry and grumpy at it. So there's also just the just extra layer of protection for those people who do have to make these difficult calls by saying the council made the call, not that individual made that call.
Carlton Gibson 46:31
For listeners who can't see on emoting massively, everything was just said,
What did you want specifically mentioned, so micro event is something you've been working on just on the virtual environment, front? Yeah, we're gonna have, we're gonna have a link to it. But
Brett Cannon 46:46
if you want to get into VS code, and all that, we can totally talk about that. But we also, if you're done with the packaging stuff, or we keep going on the packaging, and go to VS code later, but micro vam specifically ties into VS code. It's once again, the funny thing is people think that's packaging, even though it's entirely virtual environments, and Debian is fault and the whole reason exists, but that honestly has nothing to do with packaging. It's more of a VS code Debian thing.
Carlton Gibson 47:08
Well, that's just gone. Gone. Well, you because you haven't, you've hardly said anything.
Will Vincent 47:12
You know that I like this. I said, before you go, Carlton, well, okay.
Carlton Gibson 47:15
So I'll just tie in, because the reason I choose slit is because it's really simple. And it's what it does. It's one thing and I and then I use VM for VM wrapper, because they're exactly the same story on that side of it is, they're simple, they do one thing, well, they've been doing it forever. I know exactly how they work. I trust in time, even if it blew up, I trust that I wouldn't be in a position where I'd be lost. Whereas some of the more fully featured options. I'm a bit scared that if if there is a failure condition, I won't, it'll be mysterious and I'll be lost.
Brett Cannon 47:46
Because I operate parceling like I have historically used flit and I do uncertain project. But that's because they're so low level in the packaging ecosystem, they actually have to use flit, because that's becomes bootstrapping problems on Linux distros, when they want to bootstrap all the way from pure source up. I've also I've been starting to use hash lien, because hatchling by default will actually include everything in your source distribution that is checked into your Git repo, but leave everything else out. That's not while flit only will do that if you use flip build. So there's a key difference here, we're flit has a has a flip build command, which will do this. But if you were just use the the build project, like the build command, that's up on pi pi, like, literally pipe yard.org/piece. If you were to call that on flip core, which is the build system use, it doesn't do that magic, you actually have to specify in your project automall In a tool specific setting, this is what to include, or this is what to exclude from your SST. I personally, I want to be frequent lazy when it comes to my sources tuition. So hatchling just does all that regardless of how you run it. So I went the ultra lazy route. Okay. On this topic, but
Carlton Gibson 48:58
the flip, I will just saying that I just use the, the minimal that.
Brett Cannon 49:04
I use the minimal build tool, I still create all my virtual limbs, all my virtual environments directly myself. I'm personally a virtual environment in my workspace my directory, so I'm one of those dot ven people. But yeah, I'm the same thing. Like I like the tools to be simple enough, that the I view the basic all these tools as artifact creators in the end, right? And that's really what we're trying to standardize around is what are these artifacts that they're producing? And is there a way to expand what artifacts that are standardized so that they all are producing the same thing, and virtual garments are one of them, wheels or another? And I like to have the solution that fits the bills and simple, straightforward and does it really well? And once again, as coach said, fairly condition, I totally can understand the systems so I'm personally one of those people like your words, just I don't use hatch. I don't use poetry. I literally create my virtual environments as a command or Oh, that's a great environment command VS code. And I just used Yeah, hatchling or flitters, whatever, because I'm only doing pure Python code as much as I can, because I'm quite happy in my life in our three know line to see if I can help it. So I don't need any of the fancy stuff that set of tools and other tools provide to wrap to create it critic sent models.
Carlton Gibson 50:20
So one project I did want to ask you about was you've got this pi launcher, which is quite cool, because that was when I started using Python on windows had this pi launch. And it was awesome. Because I could install my multiple pythons, I just go pi, that version, and then launch it and then you shipped it to you shipped to Linux or Unix systems everywhere. Can you tell us about that? Was that part was that VS code driven? Or is that separate? Huzzah,
Brett Cannon 50:46
no, those threads work, workflow driven. Basically, what happened was, so I work at Microsoft. I've been here for over seven and a half years at this point. And when I joined Microsoft, I got a Windows laptop. I had not run Windows since since back when I was undergrad playing a lot of counter strike at night. So it and so I started to use it. And this was all before WsL was a thing I actually was actually got to know about WsL, about a month before it got announced, because they wanted to come talk to us on the Python team. And so I had I had to get used to developing for Python on Windows. And that is the Python launcher right? py. And the reason that exists on Windows, for those of you who are not Windows developers is typically, historically, when you installed Python, using the installer that you got from python.org, it was pythons not putting on path by default, you have to opt in with the clicking of a button. I've been told that is proper Windows practice, do not put a lot of stuff on path. But the thing is, is basically when you install it, it gets put into the registry on Windows. And the Python launcher just knows how to read the registry. So the way to to launch the things that you installed is to use the Python launcher because it'll just read read the registry, figure out where the things are. And that's how you launch it. And it was actually kind of handy. I liked it. I mean, it's nice and straightforward, real easy to choose what version of Python I wanted. And I appreciated that I never had to concern myself with what was the last version of Python I installed that was going to inevitably overwrite my Python command or my python three command on Unix, right. But I I've had a Mac laptop. Since I got off Windows, I will say I'm probably gonna move to Fedora this year, because I'm going to get a framework laptop as my next laptop for environmental reasons. Anyway. So I was using the Python launcher at work on my Windows laptop and then doing open source in the evenings, weekends on my Mac, and it constantly going, Oh man, I wish I had the launcher. And about the same time was also learning rust. And so I decided that you know what, it shouldn't be that difficult to write a small rust app that does roughly that right that just make sure that when I type pi, it just launches the newest version of Python, not the last version I happen to have installed. Because I've had that happen, right? Like I always try to keep up with the point releases. And so it's not and we usually release simultaneously up to two or three versions at a time. So it's not unheard of, I just immediately grab Oh, the newest one, it will be three point 11.30. But three point 10 point, I guess 10 was last one I can't remember. And then install that next. And then suddenly now python three points, the wrong things. I know, there's a
Carlton Gibson 53:41
security release with 3.7. And all of a sudden,
Brett Cannon 53:45
I typically have all this installed. Because I'm developing packages that span versions, I want to have them all in and I don't pay it, I didn't want it to keep paying attention to what order I did the installation. And so I started to write the Python launcher. And while I was developing it, I was like, You know what this is for me, no one's necessarily going to care about this. It's a pretty minor when is mainly for me to learn rust, you know, I'm going to add a little niceties to it that fit my workflow. And if the rest of the world loves my workflow, awesome, I will happily support them because I'll be supporting myself. But if it's not for them, no problem. No big deal, right? That's one of the things I've learned with open source, right is you have to be very careful about being too nice about taking new features. Because if it doesn't meet you, that's what makes you right. It's the Oh, feature a you take it and you actually never use feature a and you keep doing bug reports about it. And this usually when you start to go, I don't want to
Carlton Gibson 54:42
it's building the parachute behind you. It's like you know, the drag coefficient. Exactly.
Brett Cannon 54:45
And so in this case, because it was the my Learn rust project, and it was going to be my workflow, it was just like, Yeah, you know, I'm just gonna do what I want, right? So the launch adds a little niceties, right like, if you have a dot v and v directory either in the current director up, it will just automatically use it in short circuits to search right. As long as you don't specify a specific Python version, it'll just pick it up and do it. Because once again, that's how I do it every time I do a new checkout, Python dash m them dot v env. Then now all I do is just pi dash and then dot v and v, which will automatically create a new virtual environment using the newest version of Python installed, and then any future execution of the Python Launcher will just automatically use that. So I don't have I can't remember the last time I ran an activation script for my virtual environment. I don't care. I don't need it. And then guess what? I'm a starship user, right? starship.rs? For those of you who don't know, right, so it's a cross shell prompt? Well, you can specify the Python, or the command that it runs to figure out what version of Python you're using. Well, it guess what if you set it to pi, starship will run that and use that to figure out what you're using. So it will automatically list that is the version of what dot VIM is and grab that name. And if it doesn't, it'll say if I run pi, right now, it'll be that version. And when I go into a directory, that has a Project dot Tamil file. So once again, my workflow fits perfectly with the Python launcher. And so that's how that came about was just, I missed the basics enough that I want to implement it. And then I just expanded it a bit to really fit my workflow and just sat on it took me over two years, I think two or three years from inception conception to actually coding and just because I wanted to make sure it was rock solid, because it's one of those not a fun bug to have, when suddenly you're trying to run your tool and for your whole workflow, and it gives out so I sat on it for a long time before I made a 1.0 release. And actually, it's only had a 1.0 release. So luckily, cut off any of the major bugs ahead of time. I also give feature complete, yeah, Russ did actually make it a pleasure to do this. And it's one of those few get past Baro checker, a lot of bugs kind of just fall away. But yeah, that's how the python three came about was basically, I missed it from windows, and then decided to lean in on my workflow and got it to where it's at now and Samsung future plans to lean into my workflow even more, but once again, gotta have enough time to do it.
Carlton Gibson 57:12
Yes, slowly, slowly. Okay, I guess then let's swing around to VS code because VS code and Python have been gone well together. And it's influential, both will and I using it daily and thinking what what new what's new in vs. Code lane? And what what would you like to work in you? What would you highlight while you're here?
Brett Cannon 57:34
Oh, sure. Um, so just so everyone knows, I'm the dev manager for the Python experience in VS code. I used to just say extension, but we've got multiple extensions now. So that's experienced to not make people think, Oh, I don't have anything to do with that thing over there. Although to be clear, I'm not in charge of pylons, which is our IntelliSense engine, and I'm not in charge of the Jupiter extension, which is separate and technically language agnostic.
Carlton Gibson 57:58
I've been recently been getting lots of these pop up saying you need to you need to install the eyesore extension. Now you need to install the flake eight extension now what's going on? Yeah. So
Brett Cannon 58:07
So yeah, because you're interested about where things are going. So what's so I've been involved with the extension. Now, since it came to Microsoft, which was back in September 2017, when Don J. Mani joined Microsoft fulltiming, about the extension with them, which he released, I think, January of 2016. Don't actually he's moved on to Jupiter. So I think technically, I've been working on this extension longer than he ever did. And we've spent a long time kind of just taking it from someone's open source side project to project that staff. Because on our team there, I have four ICs. individual contributors reporting to me, we have two part time PMS and myself kind of dedicated to this roughly. And what we've been doing is there's there's been a lot of cleanup, a lot of changes, because once again, side open source project, Don was very nice about taking a lot of feature requests from people that have not necessarily held up in the test of time that we've had to slowly claw back plus also just changing the code base to match not just ons brain, and having to be understandable by a whole team of people from varying ranges from fresh out of university to people like me who have been doing this way too long. And so there was a lot of that early on. But we are getting down to the last, probably the last two projects for that cleanup. We're rewriting a lot of tests support right now. Hopefully, that will be going out No promises on dates, but hopefully the next hopefully May at worst June. And same thing with breaking out our debugger, excellent support. But what we've essentially been doing is we've decided that we want to stop being a bottleneck to the community who do come to VS code and try to use it right. So for instance, or Up until recently, if you wanted to have support to sort your imports such as a sword or format, or like black or auto pep eight, you basically used our extension and you kind of had asked us to support it. Right. And we didn't like that we didn't feel like we should be the bottleneck vs codes extension ecosystem should be embraced, not kind of shunted to the side for everything. It's for Python, but everything else gets to kind of lean into it. And so we made a conscious decision. I'd say about a year or two ago, that we were going to break up the monolith that was the Python extension, and make it much more focused and much more of a coordinator, as it were of working with Python and helping you discover things to do with Python. So in Carlton's case, where he mentioned the eisert extension, I sort used to ship inside the VS code extension inside the Python extension and was embedded in it, what we've done is we've broken it out. So now you can use whatever version of VISEART you want based on what version of VS code is there, because we ship it in the box. And because it's now separate, we don't feel bad shipping inbox, because we actually Vyas code all up always aim to have a very small, fast experiences, even for extensions. And so shipping, just eyesores along still pay to maybe everyone on the world pay a price for our entire user base, which I will say we're very lucky to have that not be a small user base. And, but there's also about like, we didn't want to ship black in the box, we didn't want to ship auto Pepe, we didn't want to ship pilot, we did not want to ship flake eight or any of the other tools that we supported, because that's asking a lot for people who may never use any of those things. So what we decided to do was we developed a extension template for tooling for Python tools specifically. And what it is, is it's a GitHub repo, that's a repo template that is set up such that you should be able to take any CLI tool, and very quickly get it spun up and working into VS code extension, I say it's an afternoon, RPM actually was able to wrap I can't remember was flaky to pilot in an hour and a half. Right? It's very straightforward, because you just basically say, here's the format. And here's the thing that TypeScript codes done, the Python codes already done, because it's all behind the language server protocol. It's very straightforward. And you should build a wrap whatever tool you want, if there's no extension from us. But the other thing is, by breaking these out, for instance, we can now ship by sort inbox, we can ship black inbox and have oldest work on install time, instead of Alright, I gotta go run PIP X to go get the version of Black I need for this or what have you, or I got to do this configuration or whatever, right, we've really tried to lean in on this whole, let's not be the arbiters of what is or is not useful for a linter or format, or let's just make it easy for the whole community to just do whatever they need. And I will fully admit it also makes maintenance way easier, because now it's easier for people to contribute, because now it's not all TypeScript code. Because the Python extension is a lot of TypeScript. But when we put this all out, language server protocol code, for instance, is pi glass, which is a Python project. It's a Python package, right, we've actually developed our own package called LS protocol, which auto generates from a JSON schema, all the ties for the language server protocol. So you can even write your own language server protocol much more easily, right, we've done everything we can to get it so that people who are comfortable writing Python, can wrap a Python tool and feel comfortable in it, versus there's this magic TypeScript stuff, I don't know, and I'm not going to touch it. And so that's kind of where we've leaned in. And my expectation is, is we're just going to continue to kind of lean in on that. So we have audacious ideas of trying to make it easier for all these other tools that want to own your workflow to participate, right. So for instance, we have a create environment command now, which helps you set up your environment and we try to make it smart once again, meet Brett's opinion of what of workflow should be. So for instance, if you want to create a virtual environment, it will ask what global install version of Python Do you want to check it we look for, if your project automall And if you have a build system in there, we will run it with Dashi and we ask what optional dependencies you want install, you can click the boxes, if you have any requirements files, both following the two scripts of Python, you're gonna have your requirements directory and stuff in there, or requirements dot txt or what have you. We just pick those ask which ones you want install. So all those we actually drop in a dot Git ignore for you. So you don't accidentally commit that virtual environment because we've had that problem with beginners. And I will say this is technically oriented towards beginners, but as I said, it also meets what I want. I since I'm the manager, I get to take the heat, I made sure it did what I want. So in general, this should be useful to a lot of people. But for instance, we want to make it so that if you use hatch or poetry, or any of those other tools that want to manage your, your virtual environment, they should have a way to tell us Like, Oh, hey, I can I can contribute to this when someone wants to create an environment, ask me whether they want to do that. And then I can do that, right? Like conda is embedded. As part of our thing, I'd love to make a separate conda extension that makes it easier and only for people to contribute to because they're conda users, but also to act as a representation of how you can do this for hatch to for poetry, do it for Pippin, virtual env, wrapper, whatever you want just some way to let other extensions contribute back in. And then we just become the integration point for Python tooling. Right? We will handle finding all your interpreters. But after that, you just install the extension that makes sense for your workflow. And you own it and you get what you want. We don't have to maintain everyone's workflow and try to make it all work ourselves. And then that way, one's happy, right? Like everyone gets the hook points they need hopefully, as simply as possible. While having the flexibility to do that, while I'm not asked to support every tool under the sun, and tearing my hair out, because everyone wants to do things slightly differently. And it's constantly chasing another upstream project when they decide to change something. So that's the big overarching thing. And then after that is web assembly, which is is a whole nother topic, if you want to get into that one. But that
Carlton Gibson 1:06:12
I'd forgotten about that. Yes. WebAssembly as well, but I'm not sure we've got time. Well, if we got time you're in charge.
Will Vincent 1:06:20
No. We should bring you to do we should do a second part.
Brett Cannon 1:06:29
We totally can. The the teaser on that then for Brett on Django chat. Part two is we are looking at we have made VS code at YZ runtime. And so you're able to run Python code with a Python interpreter compiled ahwazi. And when you ask it, like what to list the directory, it will list what's in your workspace in VS code, which can be wherever those files happen to exist, whether that's a GitHub repo on GitHub locally on your desk, however, you somehow make that file get listed in the sidebar for VS code. Your Python interpreter can actually work with that. So that's the T. So that's
Carlton Gibson 1:07:07
gonna mean that's going to mean running Python on iPad in the browser or something like that, as well, right? Because
Brett Cannon 1:07:14
you should be able to see that.
Carlton Gibson 1:07:17
Yeah, fantastic. Wow.
Will Vincent 1:07:19
Well, I just want to say, as someone who teaches beginners, I don't know if it's your specific area. But installing Python on Windows just over the last couple of years, is so much better. Like it's so simple now that you can just say go to the Microsoft Store. And you somewhere in the last year or two defaulted to having the Path button checked, it wasn't checked, which tripped up a lot of people. But now it's just check. So it's just like, it's almost easier than then Mac OS. So that's been such a huge improvement. I've been spending a lot. I'm a native Mac user. I've been doing a lot of windows, or I've been doing Windows recently, because all my a lot of people use Windows. And, and you know, three, four years ago, it was a lot more painful than it is two years ago, to do all this and to teach it. So I got Windows first. Now in all my books, he said, which means like one day a week, I use Windows, and I still prefer Mac but like all the tooling is VS code, Github desktop, you know, it's fantastic and cross platform
Brett Cannon 1:08:13
viral. So that's mostly all thanks to the work of Steve Dower. I within Microsoft itself. The old joke used to be I'm the Python developer at Microsoft, while Steve was the Microsoft developer in Python. Because I've now moved over to the VS code world, I focus more on that and then anything that kind of touches that so WebAssembly, as I said, is becoming a thing we're seriously looking into. So that's how I'm getting involved in terms of the Python web assembly stuff. The packaging stuff was pre date, but also I have to stay on top of it to make sure we have the proper support for stuff. But that all that like making Python run on Windows, totally outside my domain. That's all Steve Dotto here. So he deserves all the things. Yeah,
Will Vincent 1:08:56
it's gotten so much better. So we are close on time, we usually ask what would you change about Django but for you, if you can remove yourself from Python, and you're just floating out there? Like mate like wave a wand? What would you change? You know, if you're benevolent dictator for life, and don't care what anyone else thinks. I've had so many dreams about this one I'm getting that's a third episode. Well, no,
Brett Cannon 1:09:20
the problem is, is I happen to be in enough of a privileged position that community that if I really think it's at all feasible, it can make it happen. So it's, it's a magic one that I hope actually got comes through. Um, what I will say is, I hope we, as you pointed out, well, getting Python right now is gotten a bit trickier, and trickier. But it's, it used to be simple where we could say on every OS that wasn't Windows Python just shipped in the box. So it was always just there and it was available, and you could just use it and then Windows was always the one that fell behind. And now Heck if you type python and PowerShell He will tell you, Hey, you should go install Python for Microsoft Store. Right? And so it's just a thing you can sell from the Microsoft Store, even if I mean even if that command goes away, because I know some people hate it, right? It's still just there in Microsoft Store, it's a click away, it's no big deal. It's a win, win, get and win, get chips in the box, right? And then you go look at, then unfortunately, go look at Mac that's not in box anymore. You look at Linux distros, like Debian or anything based on like Ubuntu. And some of you don't have Vim and Pip, right. So I personally love to see us potentially, and this has already been discussed. So once again, Brett's magic wand is magically making magic happen. Very facetious, by the way, I've been talking about this, but I'm not necessarily doing the work on this. So I don't want to take credit away from anyone who deserves it. The Daniel Smith actually just posted a pep to bring what he calls pi b eyes, a Python binary interpreter interface, I can't remember what the what the exact acronym representation is. But he wants to get it so that we have almost the equivalent of wheels for builds of C Python. So oh, I need Python on Mac, just download this zip file, unzip it, and you will have a working copy of Python done. I'm on Linux, download one that will run on any Linux and just run it and you're good. No pyin Were you having to do the builds or anything like that, no having to run an installer, there's literally just going to be as there would just be a zip file, and it would just run. And from the VS code perspective, that'd be amazing. Because I know people getting up and going, one of the tricky bits is just out first stuff. And the idea that I could potentially in the Python launcher, just go like, Oh, I need python three point 12. It's not installed yet. Just go download it, right, or any Python 3.0 Blah, blah, blah, just go download, install it, just make that work. After that, I think it's really just keeping the keeping the wheels on this whole crazy thing that we call the Python community and just keeping it going. I don't have any massive gripes, honestly, we're so lucky to be in such a diverse, inclusive, welcoming, wonderful group of people that, honestly, even with all the technological whatever's as long as this Committee continues to be awesome and amazing, I'm happy. I'm somewhat known for certain phrase I threw out there at one of the icons where I said it came for language, and I stayed for the community. And that still holds true even since I said it, like I'm here for the community. So as long as like meaning continues to function. I'm not too concerned about the tech, there's always going to be weird words and stuff that we don't put in the language back in the 90s that are just going to be there. And I just learned to accept it. Also, because I know if I change things, I'm going to kill a bunch of trees, because they're going to reprint books, because people still buy those things that I just feel like I've not helped climate change that way.
Will Vincent 1:12:45
So we're not going to talk about the global interpreter lock, we're not going to go I don't know how many times
Carlton Gibson 1:12:49
you want me back on well, but that's a whole separate so three
Brett Cannon 1:12:55
books, so I actually quit the about that. We did just accept Eric snows pep that does add per interpreter gills. So sub interpreters are now going to be a potential possibility. That work should land in 312. There will not be a Python API on purpose. But if people want to experiment with it, and develop extension modules that can create sub interpreters in the same process. They all have their own Gil, that you know, that should be doable in python three point 12. So that'll be interesting. That completely removing the GIL Sam grosses work is a whole nother can of worms, and in a whole separate discussion. But yeah, in terms of wands, I would honestly say downloading Python, making that making that install easier. After that, I mean, dream of dreams would be bringing conda and the pi, pi, pi pi pi PIP side of the world together and having one wonderful package installed ecosystem. Basically, that'd be amazing. If we're talking about ones. See, that's otherwise more time.
Will Vincent 1:14:01
Okay. Yeah. Third one is the community. I mean, that sounds very familiar, similar to Django, and a lot of respect. Yeah.
Brett Cannon 1:14:07
I mean, it's the backbone of everything, right? Like, I see people go like, Oh, well, why can't we just do this? And well, it's like, well, there's people involved who care about these people. And we can't just magically just throw their work out and say, ignore their concerns and whatever stuff like it's, it's all part of the process. And I think sometimes it's easy to forget that. It's not just about the technology with this. I know, that's why a lot of people come. That's not why people stay. And I hope we never lose sight of that in this community. Because it's such a wonderful place.
Will Vincent 1:14:35
Great. Well, let's, let's end on that. And we definitely do want to have you back on again. Hopefully, we have links to all the show notes. Thank you so much for taking the time. I know you. Thank you
Brett Cannon 1:14:44
for wearing well. Thanks for having me. It's been great.
Will Vincent 1:14:47
All right. And everyone we are at Django chat.com. And we'll see you all next time. Bye. Bye. Bye bye.