Transcript: 20 Years of Python - Brett Cannon

I'm Carlton Gibson.

Joined us every by Will Vincent.

Hello, Will.

And today we've got special guest Brett Cannon with us, who's um Python Core contributor and works on Python VS Code at Microsoft.

Brett.

Thank you for joining us.

Really excited to have you on.

Thank you for having me.

No, no, no.

Move on.

How did you how did you become a Python core contributor?

What does that become?

Oh boy, okay.

Uh so when I was doing my undergrad, um, there was an intro course to the first computer science programming class.

Um, I'll preface this by I actually uh wasn't gonna 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 uh the bus, the first bus at the turn of the century.

So I was like, take enough courses and you get a programming job kind of thing.

Um but there was an inter there was a uh entrance exam, and I was concerned there was 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 I was like, I should learn something to make sure I know what the heck I'm doing.

And reading around on the internet back in 2000, uh, it's two languages kept coming up, Perl and Python.

And I read enough that people seemed to suggest Perl should be the sixth language you learned, 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.

Uh I have been using Python ever since the fall of 2000, and that's how I found the language.

Um, in terms of the core development team, that's another quirky story.

Um I basically needed uh stir P time, uh, which is in the time module, on Windows, and at the time it didn't exist.

So I created it, and uh, you had to enter all your locale information manually, like what are the names of the months?

Um, but it basically did the right thing in terms of the percent like D for date for day of the month and all that.

Uh, and that ended up in the first edition of the Python cookbook from O'Reilly, uh, 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 I didn't realize what libc was.

That's on every platform, but stir p time is not like how how where's that information?

I want that information, and I it just bugged me and I constantly thought about it just when I walked to class and whatever.

And then I eventually had that aha moment.

Oh, well, I can just I can reverse engineer, I can call STime to tell me the name of every month, and I can just cache that, and then magically I will have the names of every month because str p time and str f time use the exact same format strings.

So I graduated, and then the following week, as a graduate graduation gift to myself, I wrote up that code, put it back up online, and then I em yeah, it shows you how a little warped I am.

I I finished school and within a week I I my fun time is oh, I'm gonna go write some code.

Um, 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 it's on other platforms.

I said, Oh, well, you email this mainly 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 uh Francois Picard, uh actually a fellow Canadian from Quebec back then, uh explained the process to me.

I submitted a uh a patch to SourceForge, if for those of you who know what the heck 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 in 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.

It's like, no, no, no, I was studying into courses and I know what I'm doing here.

Um, and at the time, uh, there was something called the Python Dev Summaries uh that had stopped previously because no one was writing a some basically a um semi-monthly summary of what was going on in 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, this has been a good experience getting involved in getting this patch in.

Why don't I just take that up?

Because I just stayed on the list out of interest.

Um, and then come, I think it was mid-August of 2002, I started writing the Python Dev Summaries twice a month.

And I just kept doing that.

And it put me in an interesting position of uh I'm sure Colton can kind of relate to this, of when you read all the emails, you immediately 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 bug that needed to be fixed, so I'd get to it before most 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 then Guido emailed saying, Well, don't you can't you just commit yourself?

It's like, no, I don't have commit rights.

And so April 18th, 2003, I got my commit rights and made my very first commit on my own.

So I am, I think, exactly as the today's recording one week shy of my 20 years as a core dev.

Wow, well, wow.

Oh, hang on.

Well, too many things.

And what a you know massive contribution to the Python community over that time.

Well, thanks.

I'm I'm happy, I'm happy and glad to have done it.

I mean, I'm not going to shy away from the fact 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, uh, 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 occasional 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 it the community.

The community is definitely given back to me.

Fair enough.

You were gonna say something.

Correct.

Is that the timing?

So then when you rolled in in the fall, it's like, well, you're a philosophy major, it'd be like, yeah, but I'm a core contributor to Python.

That must have been kind of fun.

Um 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.

Um, and the funny thing about that was people would ask, like, what do you do in your spare time?

Oh, I watch movies, blah, blah, blah, I play games, and oh, I contribute to Python.

And the the answers always fell in two buckets either, what is that?

Or was it that language that weird language of white space matters?

Right.

Right.

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 loved 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 of the 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 community, I and I've always said this, right?

Success comes down to luck, skill, and risk taking.

And I just happened to have 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 now had people join on the core dev team who were still in high school, right?

So total luck.

It just totally worked out wonderfully in my life that this all worked out.

Like, so before So why what what about philosophy did you like?

I mean, because of it's it's an art, but of the arts, it's in many ways the most rigorous and kind of ports over pretty well to things like programming.

Actually, I went to junior college for those of you from the system.

Is that what it was?

So okay.

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 at that point, I obviously been doing computer stuff, but like it was more like games and adminis kind of stuff.

Not not real, I didn't know really know what programming totally was.

I had a concept, but no one had really told me like you seemed to have uh lean towards you seem to be adept at doing it, right?

Like I had programmed in Apple Basic in a summer course, and I completed the entire summer 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'm I guess I'm just a good at studying or something.

Um, so it just hadn't clicked.

My mom picked up on it though later and said, like, no, you should take a course.

So I took a course in both and I absolutely loved it.

And at that point, I actually planned to double major, right?

Because the philosophy was the passion that I absolutely loved.

And I was passionate about computer science, but that was gonna 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 um part of the University of California system in 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.

So the problem is I 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, uh I still had to get accepted by the major.

I'd been accepted at the university, but not the actual department.

So and philosophy's uh acceptance was you walk into the office, say, I want a major in philosophy.

They ask, are you sure?

Computer science, whole application process, all this other stuff.

So it was one of those, do I guarantee I graduate with a philosophy degree?

And once again, early 2000s, boom time, take a couple computer courses, you'll get a job, or do I try to get into computer science, not get in, and then 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.

That's good.

That recruitment, that um admissions policy, the philosophy, it's kind of internalist.

It's like, are you sure?

Yes.

Well, you're in.

Yeah.

That's nice.

So Carlton has a PhD in philosophy, and so I'm constantly he actually I finally he wrote something about the LLMs and you know, philosophy, because he's always like side chatting me all these deep thoughts.

I'm like, dude, come on, put put something out there.

Like, so what do you need who needs to sit in both worlds?

He really there's this discussion about um whether you can fairly describe them as lying or you know whatnot.

I'm like, no, 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 whirling away, you know.

And it's not that your doodle looks like something or doesn't, it's kind of an accident of history, and in their case, an accident of the training data.

Uh so the Chinese room argument, for anyone who knows who's heard of that.

So I am sure he's loving this right now, based on how he taught that course.

That he's loving everyone asked about LLMs and whether they are general AI and all that.

Like, I can totally be in that course right now and totally picture him going like, Well, you know, based on the Chinese room argument, they are nuts, they do not understand what they're doing in bubble.

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, Carlton.

That is that is awesome.

I keep finding, and honestly, I think it's just the deep thought and just trying to make the connections is kind of the tying back to programming.

I mean, that's what it is for me at least.

And they're like, Well, you know, what's the connect how what's the connection then?

And then 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's just philosophy from one way of looking at it.

It's you know, but with superpowers, it's philosophy with superpowers.

Like, if you think about it, like I got that question constantly was why what are you gonna 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 if you want to go the cheap route out, it's symbolic logic, right?

Like, if as long as you can handle the symbolic logic aspect of philosophy, that's basically what programming is.

It's just down at the silicon level from terms of the CPU.

But afterwards, from there, it's more being able to take the minutiae and the small bits of an argument, expand it out to a larger system, or 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 structurally support in terms of an argument so that the overall argument that you're making holds.

And it's the 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 what, if I plug that in with this, suddenly it opens up this system, right?

And that feels feeds more into almost API design, right?

Where you go from the smaller bit bigger, bigger, and then suddenly how do I 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 programming is basically that, just at a very little bit more rigid logic aspect where it's a little bit more repeatable, at least in terms of what you put in and get back out, ignoring qubits and quantum and all that.

It's it's they're they're parallel modes of thought.

It's not the big derivative, but it was a big question.

When so I would just want to pick up on a couple of points that you made, um uh, and then we can move on to perhaps talking about um Python and VS Microsoft and VS Code and other packaging and all these other things we've got on the list.

You said that learning contributing to open to Python gave you something to show, it gave you something for your portfolio, it gave you the kind of learning opportunity as you were watching the email 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 wanted to pick out that you'd you hit on those, as you know, why contribute?

Well, because it gives you all of this back.

Exactly, right?

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 pro tip to everyone else.

Assume the person's reading them is going to read them in the most negative way possible.

Like, I contributed to this.

Okay, so you brought coffee or tea to the people on the team, and that's how you contribute it, 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 chan, very likely you wrote it.

Now, obviously, someone could have written it for you and it was imperson impersonating, probably find that out pretty fast when you got hired.

But otherwise, it's a very straightforward duty to do that, right?

Once again, also a 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 miss 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'd they make that work?

I mean, it 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 and all that works, it's still a little magical thinking this.

I mean, isn't that the thing?

Like, I'm not gonna worry about the I'm not gonna worry about the internal layers and all that stuff.

That's a whole nother conversation.

Um, 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 say 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 and all that, because we have to shrink all our JavaScript to be a meg, say, instead of back when it was like you just shipped it raw on how you wrote it and just didn't care.

And then once again, as Carlton pointed about the community, right?

I've been doing this for 20 years.

I have friends that I have 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?

I via whatever mechanism, whether it's email, discord, discourse, video chat, whatever.

There are people who've become friends outside of the conference circuit as well, who I've gone and seen on vacation.

Like I've been extremely lucky that it's 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 as people and you just become friends as people, and yeah, it's been amazing.

I wonder if you could speak to 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.

Um, and so how would you advise someone today to kind of get into Python or other places or these more mature seeming places where there just isn't low-hanging fruit all over the place?

Like I remember the first PyCon when uh 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's 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.

Um, so it's tricky, right?

I I will fully admit it's hard.

Um, I will say lately, the way people who have gotten involved directly with Python itself is an example.

Um, the people who have done that have usually either come forward and 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 would 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 just based on knowledge and time to handle the higher, bigger, hairier problems, the stickier ones.

Um, and then other people have come in and gone, like, oh, I've noticed there's this part of like the standard library.

Um, it's been neglected.

And they come in and start really helping with that.

And so it's a bit more niche and but much more focused.

Um, Barney Gale is a perfect example.

He just became a core developer and he stepped in and started to help out with PATHLED.

And he just said, like, yeah, you know what?

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 Pathlet, 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 he just got better and better at it and just started to okay, this is this a good idea, yep, and just started to get it right more often than not and continued, continued and continued.

I then stepped away from PathLib um at the uh beginning of this year just to kind of not spread myself so thin.

Uh, 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 said, Well, why don't we just make him a core developer?

So we did the vote, he got it, and now he's managing Path Laball on his own.

And there's lots of other people who started as triagers and just were helping out and just could perpetually helping out and just eventually showed that they could just be trusted.

And so they got the mit rights, and now we just trust them to do the thing that they need to do.

So you have to find out, and if you you know, you do you go okay, you reproduce it and you dig into the bit of code that's causing it, and you're like, or by doing that, you become kind of the world expert on that bit of code.

Oh, yeah, and you you really learn it, and you you just it's 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 uh what's the state of play though?

Like, because there's this idea about removing some batteries, which is good, especially the old ones, and then I posted a thing about oh, I really wanted to write a an HTTP server in H H Hync.io, and I'm like, but I I need to bring in an HTTP parser.

I'm not writing an HTTP I serve.

Why isn't there one in the standard library?

And so I rented off on that and we had a little back and forth on Foster Done or whatever.

Well is it not maintainable?

Is it that we can't bring more uh 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 strim it down and become more nodi?

What's your thought?

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, um, being a member of the steering council, um I've seen what it 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.

Um before we did the last clean out of the standard library, uh, which just happened for the 311 release where we started to duplicate a bunch of stuff.

Um, there were more modules in the standard library at the top level.

I'm not even talking about submodules, than there are countries in the world.

And we all know we can't name every single country in the world unless you somehow owned up on 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 potentially 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 core 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 monitored or watched once they get the core bit, or the commit bit.

You're just trusted to do the right thing.

So we can't just let anyone just walk off the street and tell them get to do it.

You kind of have to show that we can trust you.

So there is a limit, uh, a finite amount of uh people power to keep stuff going.

So what I have 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.

Um Graph, for instance, Graphlib 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 added.

Now I can't even remember which PEP it is now.

Um I think it might be PEP four.

Can't remember.

Okay, we use the key out of service.

Um, but basically it's now written down in PEPs that to add something to side library has to go through the steering council, and to remove something from the side library, it has to go through the steering council.

We've also clarified our backwards compatibility policy and made that official so that people know that except for extremely extenuating circumstances, everything will be depth grade for at least two Python releases, which is two years.

We try to go longer if there's if it makes sense and it's not gonna be strenuous to keep it going, like five years, because then at least you can have an entire life cycle of one release before you get told you gotta get it off this.

Um, but the other thing that I'm doing is now that we have a way to manage it in terms of coming and going, um, at the language summit at PyCon US this year, I actually have a talk which is literally titled, What is the Snyder 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 Snyder Library.

And once again, you have to think about how old Python is, right?

I've been doing this for 20 years.

The project has 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 the 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 PyPI, 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 against PyPI.

Um, by the way, just go to a 404 page on PyPI and you'll find the Monty Python sketch that'll explain that reference.

Um so I don't think I uh Stering Comp some, I just don't know what it'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 meant 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 like you could say two of them at least with PEP and Conda in terms of those kinds of split of the world, I I I don't know what it should be.

There's no thematic explanation.

There's no PEP, there's no informational PEP.

So as a student council member, 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 PEP ends up being.

So don't I got a

title for the podcast?

Brett says it's gone.

Or that's there because we've agreed that you should generally be able to accomplish blank 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 standard library is, that will give us a better idea of well, are do we feel restricting ourselves too thin?

Are actually if you look at what we're keeping because we think it belongs there versus what's grandfather, does that scope make sense and all that?

I think that's a follow-on conversation from that.

Yeah, no.

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.

And I'd I'd like that to be maintained somehow.

I don't know, you know, that's just a like, you know.

Like, like so Carlton and I, as you mentioned, we were talking on Mastodon about this because I kind of threw some of these things out there.

And Carl, Carlton brought up like, how is there no HTTP parser, right?

Why can't I just use this to almost write my own HTTP server?

And it's like, well, is an HTTP parser even the right thing for the standard library?

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 an installer, right?

Which is not even necessary that because at that point you could potentially do your own little URL lib that only that has a fetch API that um gives that all off to the OS and just says, you figure out how to talk HTTP, I don't care, you handle all 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 it 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 sysadmini stuff?

Is it data science y 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 dev 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, uh, no, I I don't want to run from this anymore.

I want an answer.

I'm gonna ask the room, I will write a pep, the steering council will hopefully either accept it or reject it, or we'll somehow reach some consensus, and that way we'll at least have some under shared understanding.

Because right now there's just none, and I just it it bugs me.

I 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 understanding because also for the community, right?

Because people shouldn't randomly have to go, but maybe this should go in the standard library.

It's like, well, I don't think so, or I think so, but I don't know what that what what Jane over there thinks, right?

Or Bob over there thinks.

And you have to figure out whether everyone agrees on that.

And like I'd rather be able to just say, like, well, do you think it matches what's in this informational pep?

If you think, then yeah, we can talk about it.

If not, yeah, I wouldn't.

I just don't worry about it.

Just put up on PyPI and let the community get that way.

That's really good explanation.

So the difficult question, difficult conversations then, which no one can agree on.

Can we do perhaps can I ask you about packaging then?

Just we'll say on the easy cut.

Um, I think there's a background to packaging.

So packaging is a difficult um 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 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.

So once again, weird history lesson for so I think one thing that a lot of people don't realize is after they have after they internalize the fact that Python's older than Linux, they don't realize that Python's packaging story also predates pretty much everyone except Perl, right?

Why don't you do it like Rust?

Well, you do know we predate those languages and runtimes, literally, not just their packaging story.

So that usually takes people a little 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 uh uh a lot of PyCons.

Um and that's pip and setup tools, which actually pip was predated by easy install, for those of you who have been around long enough.

And so for the longest time, all the packaging was basically just set up tools and pip.

That was it.

Because I'm from a day where I went to the vaults of PernaSus, which was a website with little animated GIFs with a bunch of zip files that you downloaded and just zipped into the directory with your code, right?

None of this fancy SRC directory stuff with editable installs and all that.

Uh-uh, 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 I was not a kid, admittedly.

Um, so the thing was is set of tools kept doing its thing.

It's it's it's served us well and all that stuff.

Same with hip and 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 aughts and the early aughts, right?

Like we're talking decades.

And so what ended up happening was um when I got involved with packaging after I finished import lib and that whole import migration, I decided, all right, what's the next crazy thing I'm gonna tackle and come to regret?

And I decided to dive into packaging.

Um, obviously succeeded at that one.

Um, 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 a similar realization.

And so what we've ended up doing is we kind of broke broke the stranglehold of setup tools and are kind of working towards a where world where maybe even pip doesn't necessarily become the only thing everyone aims for or 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 Pyproject.

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 the that your build tool should call, uh, should your tooling should call to make make your wheel.

And then suddenly, you didn't have to assume there's a setup.py.

You didn't have to try to go like, you know what, I need something, but setup type setup.py doesn't meet that.

So but I have to meet their API, which is a little under specified and and funky because of once again, historical reason.

I'm not throwing any shade on the setup 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 sound like, oh, you know what?

I could write my own build tool and the tools that need to potentially install from Nest Dist or do the build.

As long as I match that API, I can do whatever the heck I want.

And so suddenly we started 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 Rust, or a whole plethora of tools that now exist that meet the needs of those people for their for their building.

And then what's happened after that is um to try to continue to move down this road, uh, I helped spearhead uh PEP 621, which led to all the project metadata going to Pyproject.tunnel, right?

So historically that would have been your setup.py or setup.cfg file if you're setup tools user.

But the goal there was to make it even easier to switch to the tool backend tool that made the most sense for you, right?

Because when you standardize how that metadata gets written by a human being, instead of spend standardizing how the metadata eventually 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 in setup.py or setup.cfg and switch to flit for an example, you have to migrate from one file type to another one, right?

Because Flit uses Pyproject.tommel.

Yeah, no, I mean.

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 the other thing is is now all of the blog posts, all the tutorials, all that stuff is very generic to the common part, this pipeproject.toml, and then the individual tools just say, like, oh, I add this feature set, you have to 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 to even make it possible to have other tools.

Because I think this is another stumbling block that 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 it view it as confusing and a detriment that there's so many tools.

Those of us who predate back to setup tools days, view this as a renaissance time and packaging of Python because now I have options, right?

So once again, it's all about perspective.

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.

Um, I want to pick up just on the one word you used, which was confusion because or confusing, because from the outside, I'm not uh you know, I'm 20 years, you know, using all this stuff, and uh but I I'm like ah, what's going on?

And there's too many tools, and which is it?

And the reason I do like Flip, I like Flip because it's really simple and it seems to do just that one thing really well.

And I and I 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.

Um, and I see all these other tools, and I think they're probably great, but there's just so much going on from the from the inside.

It could you is 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.

Like, 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 pep every time, and you know, all these things.

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 peps.

And it's a bit like yeah, uh that's not feature benefit reason.

That's not like you know,

And unfortunately, unfortunately, though, that's not something any single entity can necessarily control, right?

When it stopped being, oh, I can just build a wheel to oh, 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 other 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?

Well, once again, hatchling flip, very simple.

We all know set of tools.

There's potentially maturing, right?

If you're doing Rust stuff, but that's once again very specific to areas.

There's like Scikit HEP, which once again very specific, right?

But that's just the build tools.

The problem is then we suddenly get pip, 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, condist sitting over there in a corner doing its thing as well.

Um, so I think the problem is it's it's packaging is now being grouped together with workflow.

It's not even packaging in terms of what you upload to PyPI, it's now packaging plus stuff, and everyone's viewing that as a single packaging thing, and so everyone's going, packaging is really confusing.

It's like I can understand that, but I I want to be very clear about terminology here because people I think are getting very broad about it, and everyone's coming to us who have been working on getting literally how to get a wheel bit as streamlined as possible, and going, it's all real confusing.

Well, oh 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, right?

Historically, we've not told people how to manage their virtual environments, we've not told people how to have task runners like talks and knocks or anything like that.

Your project layout, people have even started to come to us and say, like, hey, how should I lay out my project?

Like, honestly, that's none of our concern.

We're we're just trying to help you get a wheel file, but everyone's now asking us for everything that leads up into that wheel 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, 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.

Um, what I will say is there's an active conversation going on right now on discuss.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 it's an open question, uh, who kind of help drive a 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 pep delegates automatically for packaging peps, but it's just kind of their opinion.

They don't want to be the person who gets on the hook necessarily all the time for every decision.

There's 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 I they're not representative specifically, but obviously it's harder to be representative when you're one person versus the council of five, right?

Because we don't want to always be making the decision because we're just a couple of people trying to do the best we can.

We don't know.

Like if Brett says no to a pep, it's way different than the steering council said no to a pep.

And it's like, well, I don't know who to be mad at, or oh at the steering council, it's a group of people who potentially make more wisen decisions than Brett over there, the silly guy from Vancouver, Canada, made a decision.

I can completely disagree with that and get angry and crumpy at it.

So there's also honestly just an 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.

But uh we can also just if you're done with the packaging stuff, or we can keep going on the packaging and then go to VS Code later.

But micro Venv specifically ties into VS Code.

It's uh once again, the funny thing is people think that's packaging even though it's entirely virtual environments in Debian's fault, and the whole reason it exists, but it honestly has nothing to do with packaging, it's more of a VS Code Debian thing.

No, no, that I like this.

Go ahead, you go, Carlton.

I trust entirely even 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 um 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.

Like I I have historically used Flit and I do on certain projects, but that's because that they're so low level in the packaging ecosystem, they actually have to use Flit because it becomes bootstrapping problems on Linux distros when they want to bootstrap all the way from pure source up.

Um I've also uh I've been starting to use Hatchling uh because Hatchling by default will actually include everything in your source distribution that is checked into your um kit repo, but leave everything else out that's not.

Well, Flit only will do that if you use Flip Build.

So there's a key difference here where um 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 um that's up on PyPI, like literally pypi uh.org slash p slash build.

If you were to call that on Flip Core, which is the build system you use, it doesn't do that magic.

You actually have to specify in your Pyproject.tuml in a um tool specific setting, this is what to include or this is what to exclude from your S Dist.

I personally just I want to be freaking lazy when it comes to my source distribution.

So Hashing just does all that regardless of how you run it.

So I went the ultra lazy route.

Um, the flip but well, just I was saying that I just use the min the minimal then that's the workflow side of this.

I still create all my virtual limbs, all my virtual environments directly myself.

I'm personally a uh virtual environment in my workspace, my directory, so I'm one of those dot vemp people.

Um but yeah, I'm the same thing.

Like I I like the tools to be simple enough that the I I I view basically 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 um are standardized so that they all are producing the same thing?

And virtual environments are one of them, wheels are another, and I like to have the solution that fits the bells and simple, straightforward, and does does it really well.

And once again, fill as Carl said, failure condition.

I totally can understand the systems.

So I I am personally one of those people like you where it's just I I I don't use hatch, I don't use poetry, I literally create my virtual environments as a command or as a create environment, command to VS Code.

And I just use, yeah, hatch lane or flatters, whatever, because I'm only doing pure Python code as much as I can because I am quite happy in my life if I never throw it down a line to see if I can help it.

So I don't need any of the fancy stuff that set up tools and other tools provide to wrap uh to create Accenture models.

Um can you t tell us about that?

Was that part was that VS Code driven or was that separate or was that?

that was Brett's workho workflow driven.

Uh basically what happened was so I work at Microsoft.

Um I've been here 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 back when I was undergrad playing a lot of Counter-Strike at night.

So it'd been a while.

And so I started to use it.

And this was all before WSL was a thing.

I actually was I actually got to know about WSL about a month before it got announced, um, because they wanted to come talk to us uh on the Python team.

And so I had to I had to get used to developing for Python on Windows, and there's the Python launcher, right?

Uh uh PY.

And the reason that exists on Windows, for those of you who are not Windows developers, is typically uh historically when you installed Python using the installer that you got from python.org, it was uh Python's not put on path by default.

You have to uh opt in with the clicking of a button.

Um I've been told that is proper Windows practice to 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 launch the things that you installed is to use the Python launcher because you'll just read um 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 was nice and straightforward, real easy to choose what version of uh Python I wanted.

And uh I appreciated that I never had to concern myself with what was the last version of Python I installed that was gonna inevitably overwrite my Python command or my Python 3 command on Unix, right?

Um, but I I've had a Mac laptop um since I got off Windows.

Uh I will say I'm probably gonna move to Fedora this year because I'm gonna get a framework laptop as my next laptop for environmental reasons.

Anyway, um so I was using the Python launcher at work on my Windows laptop and then doing open source in the evenings wigguns on my Mac and constantly going like, oh man, I wish I had the launcher.

And about the same time was also learning Rust.

And so I decided, yeah, you know what?

It shouldn't be that difficult to write a small Rust app that does roughly that, right?

That just makes 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 on 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 will be 3.11.3, oh, but 3.10 point, I guess 10 was the last one, I can't remember.

And then install that next, and then suddenly now Python 3 points the wrong thing.

It's like no, I wanted that to be.

Exactly.

What's going on?

I want to have them all in, and I don't pay it, I didn't want to have to keep paying attention to what order I did the installation.

And so I started to write the Python lecture.

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 win.

It's mainly for me to learn Rust.

You know what?

I'm gonna add 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?

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 your needs, that's what makes you grumpy, right?

It's the oh, feature A, you take it and you actually never use feature A and yet you keep being bug reports about it.

It's like you know the drag coefficient.

And so in this case, because it was the my learn Rust project and it was gonna be my workflow, it was just like, yeah, you know what, I'm just gonna do what I want, right?

So the launcher has little niceties, right?

Like if you have a.vnv directory either in the current directory or up, it will just automatically use it.

It short circuits the 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 create do a new checkout, python dash mvam.vnv.

Then now all I do is just py dash mvam.vnv, 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?

It's a 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, guess what?

So it will automatically list that is the version of what.ven is and grab that name.

And if it doesn't, it'll say if I run Py right now, it'll be that version when I go into a directory that has a Pyroject.toml 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 wanted to implement it, and then I just expanded it a bit to really fit my workflow and just sat on it.

It took me over two years, I think, two or three years, from in conception to actually coding it 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 uh 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, I just only had a 1.0 release.

I luckily caught any of the major bugs ahead of time.

I will also give credit.

Yeah.

Um, Rust did actually make it a uh a pleasure to do this, and it's one of those if you can get past the bar checker, a lot of bugs kind of just fall away.

Um, but yeah, that's how the Python launcher came about.

It 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 still have some future plans to lean into my workflow even more.

But once again, gotta have enough time to do it.

Okay, I guess then let's swing around to VS Code, because VS Code and and Python have been, you know, like gone well together, and um, it's influential.

Uh both Will and I are using it daily.

And thank you.

What what what new what's new in VS Code LAN and what what would you like to what can you what would you highlight while you're here?

Um so yeah, 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 our experience.

I just say experience 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 Pilance, which is our IntelliSense engine, and I'm not in charge of the Jupyter extension, which is separate and technically language agnostic.

What's going on now?

So what's so I've been involved with the extension now since it came to Microsoft, which was back in September of 2017 when Don Jay Mani uh joined Microsoft full-time and brought the extension with him, uh, which he released I think January of 2016.

Um Don actually has moved on to Jupyter, so I think technically I've been working on this extension longer than he ever did.

Um and what we spent a long time kind of just taking it from someone's open source side project to project that's staffed, because on our team there I have four ICs uh um 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 a lot there's been a lot of code 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 Don's 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.

Um, and so there was a lot of that early on.

Um, but we are getting down to the last probably last two projects for that cleanup.

Uh, we're rewriting all our test support right now.

Uh hopefully that will be going out.

No promises on dates, but hopefully the next hopefully May, at worst June.

And same thing with um breaking out our debugger extent uh 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?

For so for instance, up until recently, um if you wanted to have support to sort your imports such as iSort or a formatter like Black or Autopep 8, uh you basically used our extension and you kind of had to ask us to support it.

Right.

And we didn't like that.

We didn't feel like we should be the bottleneck.

VS Code's 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 make it much more of a um coordinator, as it were, of working with Python and helping you discover things to do with Python.

So in Carlton's case where he mentions the iSort extension, i sort used to ship inside the VS Code extension, uh, 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 iSort 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 it in box because we actually VS Code all up always aims to have a very small, fast um experiences, even for extensions.

And so shipping just i sort along still paid a made 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 it also meant like we didn't want to ship black in the box, we didn't want to ship AutoPutPay, we didn't want to ship Pylant, we didn't want to ship Flakeate 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 as a VS Code extension.

Uh I say it's an afternoon.

Uh RPM actually was able to wrap, I can't remember if it's Flakeate or Pylant 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.

The TypeScript code's done, the Python code's already done because it's all behind the language server protocol.

It's very straightforward, and you should be able to wrap whatever tool you want if you if there's no extension from us.

But the other thing is by breaking these out, for instance, we can now ship i sort inbox, we can ship black inbox and have it all just work on install time instead of all right, I gotta go run pipex to go get the version of black I need for this or what have you, or I gotta do this configuration or whatever, right?

We 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 formatter.

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, the language server protocol code, for instance, is Pyglass, which is a Python project.

It's a Python package, right?

We've actually uh developed our own uh package called LS Protocol, which auto-generates from a JSON schema all the types 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 gonna touch it.

And so that's kind of where we've leaned in.

And my expectation is we're just gonna 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 a workflow should be.

So for instance, if you want to create a virtual environment, it will ask, all right, what globally installed version of Python do you want?

Um, you check it.

We look for uh if you have Pyproject.toml and if you have a build system in there, we will run it with dash e and we ask what optional dependencies you want to install.

You can click the boxes.

If you have any requirements files, both following the two scoops of Python, you're gonna have your requirements directory and stuff in there, or requirements.txt or what have you.

Um we detect those, ask which ones you want to install, install those.

We actually drop in a.gitignore for 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 dev manager, I get to and I have to take the heat, I made sure it did what I want.

So in general, it should be useful to a lot of people.

Uh, 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 um 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's embedded uh uh as part of our thing.

I'd love to make a separate conda extension that makes it easier not only for people to contribute to because they're conda users, but also to act as a representation of how you could do this for hatch, do it for poetry, do it for pipingv, 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 everyone's happy, right?

Like everyone gets the hook points they need, hopefully as simply as possible, while uh having the flexibility to do that.

Well, 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 WebAssembly, which is a whole nother topic if we want to get into that one.

Uh, but that's the other

Yes, WebAssembly as well.

But we have I'm I'm not sure we've got time.

Will have we got time?

You're in charge.

I would say that we're also working towards

I will I would the the teaser on that then for Brett on Django Chat part two is we are looking at we have made VS Code at WASI runtime.

And so you're able to run Python code with a Python interpreter compiled to WASI.

And when you ask it uh 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 disk, 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 teaser.

Because you should that was yeah, yeah, fantastic.

Well, I just want to say as someone who teaches beginners, uh, 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 uh checked.

It wasn't checked, which tripped up a lot of people, but now it's just checked.

So it's just like it's almost easier than than uh 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 window, 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 like I'm Windows first now in all my books, so which means it's like one day a week I use Windows, and I still prefer Mac, but like all the tooling is you know, VS Code, GitHub desktop, you know, it's fantastic and cross-platform.

Um I within Microsoft itself, the the the old joke used to be I'm the Python developer at Microsoft while Steve was the Microsoft developer in Python.

Um because I I'm 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 a thing we're seriously looking into.

So that's how I'm getting involved in terms of the Python and WebAssembly stuff.

The packaging stuff was pre-date, but also I have to take on top of it to make sure we have the proper support for stuff.

Um, but that all that like making Python run on Windows, totally outside my domain.

That's all Steve Dower.

So he deserves all the things.

Um, 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 may like wave a wand, what would you change, you know, if you're a benevolent dictator for life and don't care what any anyone else thinks?

Oh boy,

So it's it's it's a magic wand that I hope actually comes true.

Um what I will say is I hope we I as you pointed out, Will, getting Python right now has gotten a bit trickier.

It might gotten 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 Windows was always the one that fell behind.

And now, heck, if you type Python and PowerShell, it will tell you, hey, you should go install Python at the Microsoft store, right?

And so it's just a thing you can install 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 in Winget, and Winget ships in the box, right?

And then you go look at and then unfortunately, when you go look at Mac, that's not in the box anymore.

You look at Linux distros like Debian or anything based on like Ubuntu, and suddenly you don't have Vimf and Pip, right?

So I would personally love to see us potentially, and this is already being discussed.

So once again, Brett's magic one is magically making magic happen.

Um very facetious, by the way.

I I've been talking about this, but I'm not necessarily doing the work on this, so I don't want to take quick head away from anyone who deserves it.

Um, Nathaniel Smith actually just posted a pep to bring what he calls PyBIs, 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 CPython.

So, oh, I need Python on Mac.

Just download this zip file, unzip it, and you will just have a working copy of Python.

Done.

Uh, I'm on Linux.

Download one that will run on many Linux and just run it and you're good.

No PyM where you're having to do the builds or anything like that, no having to run an installer.

There's literally just gonna be a there would just be a zip file and it would just run.

And from a VS Code perspective, that'd be amazing because I know people getting up and going, one of the tricky bits is just that first step.

And the idea that I could potentially in the Python launcher just go like, oh, I need Python 3.12.

It's not installed yet, just go download it.

Right?

Or any Python 3.12, blah blah blah.

Just go download and install it, right?

Just make that work.

Um 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.

Um we're so lucky to be in such a diverse, inclusive, welcoming, wonderful group of people that honestly, even with all the technological whatevers, as long as this community continues to be awesome and amazing, I'm happy.

Um, I'm somewhat known for a certain phrase I threw out there at one of the Pycons where I said I came for language and I stayed for the community, and that still holds true even since I said it.

I I'm here for the community.

So as long as the community continues to function, I'm not too concerned about the tech.

There's always gonna be weird warts and stuff that Guido put in the language back in the 90s that are just gonna be there, and I just learned to accept it.

Also, because I know if I change things, I'm gonna kill a bunch of trees because they're gonna reprint books because people still buy those things, and I just feel like I I've not helped climate change that way.

So we're

We're not gonna go.

Um I will say episode three, but so I can actually quickly say about that.

Um, we did just accept Eric Snow's Pep that does add per interpreter gills.

So subinterpreters are now gonna be a potential possibility.

Uh that work should land in 3.12.

There will not be a Python API on purpose, but if people want to experiment with it and develop extension modules that can create subinterpreters in the same process that all have their own GIL, that should now that should be doable in Python 3.12.

So that'll be interesting.

The completely removing of the GIL, Sam Gross's work, is a whole nother can of worms and a whole separate discussion.

Um, but yeah, in terms of wands, uh, I would honestly say downloading uh Python, making that making that install easier.

After that, I mean Dream of Dreams would be bringing conda and the Pi Pi Py PI, PyPA, pip side of the world together and having one wonderful package install ecosystem.

Um basically that would be amazing if we're talking about wands.

Um say that's otherwise more time.

Yeah, third one is don't mess up the community.

I mean, that sounds very familiar, similar to Django in a lot of respects.

Like I I see people go like, oh well, why can't we just do this?

Well, it's like, well, there's people involved, and we 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, 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, but 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.

Well, let's let's end on that.

And we definitely do want to have you back on again, hopefully.

Um, we have links to all the show notes.

Thank you so much for taking the time.

I know you're wearing it.

I've it's been great.

Bye bye.

Bye bye.