Transcript: 20 Years of Python - Brett Cannon

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.

Hi, Carlton.

Hello, Will.

And today we've got special guest Brett Cannon with us, who's a 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.

People who don't know you, tell us about you, because you're kind of long-term, long-term

fixture in the Python community, but for people who don't know you, tell us your backstory.

How did you become a Python Core contributor?

What does that become?

How did you find Python?

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

I was 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 was like, take enough courses and you get a programming job kind of thing.

But there was an entrance exam, and I was concerned there was going to be some object-oriented

thing in it because I'd heard there was 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, it's two things.

And we just kept coming up, Perl and Python.

And I read enough that people seemed to say, 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.

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.

We basically needed stirptime, which is in 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 day of the month

and all that.

And that ended up in the first edition of 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?

Stirftime, this thing over here that is on every platform, because back then I didn't

realize what libc was.

That's on every platform.

But stirptime is not.

Like, where's that information?

I want that information.

And it just bugged me, and I constantly thought about it just when I walked to class or whatever.

And then I eventually had that aha moment where I was like, oh, well, I can reverse

engineer it.

I can call stirftime to tell me what it is.

I can call stirftime 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 stirptime and stirftime

use the exact same format strings.

So I graduated, and then the following week as a graduation gift to myself, I wrote up

that code, put it back up online, and then I, yeah, it shows you how a little warped

I am.

I finished school, and within a week, my fun time is, oh, I'm going to 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 it's on other

platforms.

I said, oh, well, you emailed 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 Francois Picard, actually a fellow Canadian from Quebec back

then, explained to me that I was going to do this.

He explained the process to me.

I submitted a patch to SourceForge, 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 a programmer.

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 and took courses, and I know what I'm doing here, and

at the time, there was something called the Python Dev Summaries that had stopped previously,

because no one was writing basically a 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?

Just stayed on the list out of interest, 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, 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 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 then

Guido emailed saying, well, can't you just commit yourself?

I was like, no, I don't have commit rights.

Let's fix that for you, 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 today's recording, one week shy

of my 20 years as a core dev.

Wow.

Wow.

So this was before you started grad school.

Hang on, hang on.

I've got too many things to say.

20 years, Brett.

Congratulations.

That's amazing, and what a massive contribution to the Python community over that time.

Oh, yeah.

Well, thanks.

I'm happy and 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 engage

all the conferences, and I've definitely benefited as well, so it's not a one-way street in terms

of how I've given to the community.

The community has definitely given back to me.

Fair enough.

Gomer, you were going to say something.

Oh, I was just going to say, so that was the spring of your gap year.

You got the commit rights.

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.

Yeah, but you have to put this in 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 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, blah, blah, blah.

I play games.

And, oh, I contribute to Python.

And the answers always fell in two buckets.

Either, what is that?

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

Right.

So it was not a flashy thing.

It was just a group of people.

It was just a group of people I hung out with online 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 with Python kicked off,

which I would say probably really started in earnest, I would honestly say, around 2006.

So I fully admit my success in this community, and I've always said this, right?

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

And I just happened to get to hit all three at just the right time in 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 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.

So what about philosophy did you like?

I mean, because 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.

Yeah.

So actually, funny enough, I got into it because my mother made me make a promise tour when I started my undergrad.

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

Get a degree that doesn't pay.

Is that what it was?

No.

So we're going to go even farther back to another quirky story of Brett's life.

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.

So at that point, I'd obviously been doing computer stuff, but it was more like games and admin-y kind of stuff.

I didn't really know what programming totally was.

I had a concept, but no one had really told me.

Like, you seemed to have, lean towards, you seemed 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 guess I'm just good at studying or something.

So I 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 absolutely loved it.

And at that point, I was like, okay, I'm going to do this.

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

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

And philosophy's acceptance was you walk into the office, say, I want to major in philosophy.

They ask, are you sure?

You go, yes.

And they go, OK, fine, and sign the paperwork.

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 of 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 into the university.

I paid for the other passion, and here we are today.

Brilliant.

That's good.

That recruitment, that admissions policy of the philosophy is kind of internalist.

It's like, are you sure?

Yes.

Well, you're in.

Yeah.

That's nice.

Well, you may or may not know, so Carlton has a PhD in philosophy.

And so I'm constantly, he actually, finally, he wrote something about the LLMs and philosophy, because he's always like side chatting me all these deep thoughts.

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

Like somebody who needs to sit in both worlds.

It's just, Simon's, Simon Willison's been writing these pieces about them, and I've been following along what he's been saying.

And he really, there's this discussion about 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.

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.

Oh, I took a class with John Searle.

So the Chinese argument for anyone who has 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 else about LLMs and whether they're general AI.

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're nuts.

They do not understand what they're doing in the 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.

And actually, it's surprising.

That's 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.

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

Yeah.

When I started out, people would always I'd be going for jobs and they'd be like, well, how did you get, you know, had a PhD in philosophy and I could program and then.

I was like, well, you know, what's the, what's the connection there?

And that 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.

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

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 going to go to grad school.

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 for the CPU.

But afterwards from there, it's more be able to take the minutia 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, if I plug that in with this, suddenly it opens up this system, right?

And that feeds more into almost API design, right?

Where you go from the smaller bit, bigger, bigger than something, 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.

No, I mean, yeah, I think I agree entirely.

It's, it's, they're parallel modes of thought that it's not the big dream, but it was a big question when, so I would just want to pick up on a couple of points.

You said that learning, contributing to open to Python gave you something to show.

It gave you something for your portfolio.

It gave you a kind of learning opportunities.

You're watching the emails come in and it gave you meet in 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, you hit on those as you know, why contribute?

Well, cause it gives you all of this back.

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 pro tip to everyone else, assume the person who's reading them is going to read them in the most negative way possible.

Like I contributed to this project.

Okay.

So you brought coffee or tea to the people on the team and that's how you contributed.

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, very likely you wrote it.

Now, obviously someone could have written it for you.

And it was.

It was impersonating.

Probably find that out pretty fast when you got hired, but otherwise it's a very straightforward 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 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, 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, but does anyone know how they work?

I mean, isn't that the thing to an extent, right?

Like I'm not going to 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 webpage?

We don't get that anymore with all this minification and all that.

Cause.

We have to shrink all our job script to be a Meg say, instead of back when it was like, you just shipped it raw and 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 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's people and you just become friends as people and yeah it's been amazing

so speaking the 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

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 yeah i mean it's tough right 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 and i think it's

interesting to see that there's a lot more low-hanging fruit 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 um so it's tricky right 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 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 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

pathlet 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 this and i'm 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 a good idea

yep and just started to get it right more often than not and continued to continue and continued

i then stepped away from pathlib um 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 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

pathlet ball on his own and there's lots of other people who started as triage and they're like oh

we're triage creators 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 rights and now we just trust

them to do the thing that they need to do 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 go okay you reproduce it and you dig into the

bit of code that's causing it and you're like oh by doing that you become kind of the world expert on

oh yeah you really learn it and you you 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 uh what's the

state of play there 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 an http server

in async io and i'm like but i need to bring in an http password i'm not writing an http i said

why isn't there one in the standard library so i vented 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 stream it down and become more nodey what's your thought

okay so there's what i'm actively doing to address this and then there's my personal opinion which is

not necessarily okay let's have both so i will start with now let's have 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 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 on a pod 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 don't you just

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 right 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 suddenly 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 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

graph for instance graph lib 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 um i can't even remember which pep it is now

um i think it might be pep4 can't remember okay um but basically it's now written down in peps

that to add something inside library has to go through the steering council and to remove

something from the started 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

extraneous extenuating circumstances everything will be deprecated 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 going to 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 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 snired library for because

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 snared 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

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 it's pypi um by the way just go to 404 page on

on pypi and you'll find the monty python sketch that'll explain that reference um

so i don't think i steering council 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 meant if it ended up

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 pep and conda in terms of those kinds of split of the world 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 steering

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 yeah exactly brett says it's gone so that's not why i'm suggesting here but i would

like to be able to point out that i'm not going to be able to point out that i'm not going to be

able to point to why something is 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 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 going to 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

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 do we feel we're searching ourselves too thin or actually

if you look at what we're keeping because we think it belongs there versus what's grandfathered does

that scope make sense and all that i think that's a follow-on conversation from that

yeah no i mean i think my sort of feeling on that is the part 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 python's 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 life that was amazing and i'd like that to be maintained somehow i don't

know you know that's just a like you know no i agree it's just my question of is what are the

workloads that we should consider and how does it get done right like like and 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 carlton brought up was 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 necessarily 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 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 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 stuff is it data sciency 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

no i i don't want to run from this anymore i want an answer i'm going to ask the room i will write

a pep the steering council will hopefully either accept or reject or will 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 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 with maybe the

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 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 a pump ipi and let the community get that way okay that's awesome

that's a really good explanation so difficult

question difficult conversations then which no one can agree on can we

perhaps can i ask you about packaging then sure right now we'll stay on the easy

yeah yeah let's just let's just cut through all of all of them while we're here um i think there's

a background to practice your 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 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 yes but i will have to go farther back than just recent

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's older than linux

they don't realize that python's packaging story also predates pretty much everyone except pearl

right everyone goes well why don't you do it like node why don't you do it like russ well

you do know we predate those languages and run times 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 a lot

of pycons um and that's pip and setup 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 fact was basically just

setup tools and pip 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 pernassus 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 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 i mean

admittedly um so the thing was is setup tools kept doing its thing it's it's served us well

and all that stuff same with hip is 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 live in that whole import migration i

decided all right what's the next crazy thing i'm going to tackle and come to regret

and i decided to dive into packaging um obviously succeed 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 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 set

up tools to use setup tools if you want and so what that really led to was pyproject.toml 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 uh 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 setup.py doesn't meet that so but i have to meet their api

which is a little underspecified and funky because of 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 something like oh you know what i could

write my own build tool and the tools that need to potentially install from nestest 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 Rusts

or a whole plethora of tools that now exist that meet the needs of those people for their building.

And then what's happened after that is to try to continue to move down this road,

I helped spearhead PEP 621, which led to all the project metadata going to pyproject.tunnel.

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

But the goal there was to make it even easier to switch to the back-end tool that made the most sense for you.

Because when you standardize how that metadata gets written by a human being,

instead of spending...

Instead of 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.tunnel.

Yeah, I know.

But if, let's say, you were already on pyproject.tunnel and go like,

Oh, you know what? Flit's been good, but I want to give Hatchling a try.

The delta of change is miniscule.

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 that's pyproject.tunnel.

And then the individual tools just say like, Oh, I add this feature set.

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

Right, yeah, no, super.

So, yeah, that's that's kind of what it is.

That's that's kind of where packaging's 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.

Okay, that's that's a really great explanation.

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

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

And the reason I do like Flit, I like Flit 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 in.

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

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.

What would you say?

Because I am literally I am genuinely confused because I haven't got the time to read every pep every time and, you know, all these things.

Well, so hopefully 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 peps.

But all the docs do say at the beginning, oh, this tool implements pep this number.

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

That's not like, you know.

No, not at all.

And unfortunately, though, that's not something any single entity can necessarily do.

It's like control, right?

Because those are, you know, I think the other tricky bit here that we have is when the tooling opened up and commonalities 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, oh, I can build a will and also create your virtual environments or I can build your will and also hope you set up your test environment or I can build your will and help you do this other thing.

Right.

I think that's 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 it's like set up tools, hatchling, flit, right?

Once again, hatchling, flit, very simple.

We all know set up tools.

There's potentially maturing, right?

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

There's like psychic hep, which once again, very simple.

Very specific, right?

But that's just the build tools.

The problem is, is then we suddenly get pipenv, we get poetry, we get hatch and all this.

And then that's ignoring the old ones, right?

Like virtual and 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, condus sitting over there in a corner doing its thing as well.

Um, 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 to pipe.

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

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

But 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 people.

Or who knows, it's, it's, it's an open question 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 necessary all the time for every decision.

They have their needs, but their needs don't necessarily represent the whole community.

And they have to.

And try to keep up with all of it.

So it's not, not, so I don't want to make it sound like they're not representative specifically, but obviously it's harder to be representative when you're one person versus a council of five.

Right.

So.

But that, that, that point about not wanting to make the decision, like all the time, like, you know, 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 the decision because we're just a couple of people trying.

We want to do the best we can.

We don't know.

Yeah.

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 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 are at the steering council.

It's a group of people who potentially make more wise and decisions than Brett 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 honestly 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.

For listeners who can't see, I'm emoting massively everything Brett's just said.

Did you want to specifically mention, so micro VEM is something you've been working on just on the virtual environment front?

Yeah.

We're going to have a link to it.

If you want to get into VS code and all that, we can totally talk about that.

But we can also, if you're done with the packaging stuff, or we can keep going with the packaging and go to VS code later.

But micro VEM specifically ties into VS code.

Once again, the funny thing is people think that's packaging, even though it's entirely virtual environments and 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.

Well, let's hear it.

Go on.

Go on.

Because you've already said anything.

No, no.

I like this.

I said before.

Go ahead.

You go, Carlton.

Well, okay.

So I'll just turn time.

Because the reason I choose Flit is because it's really simple.

And it does its one thing.

And then I use VM for VM wrapper because 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, 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 there is a failure condition, it will be mysterious and I'll be lost.

That's also how I operate, personally.

I have historically used Flit and I do on certain projects, but that's because 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.

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

Well, Flit only will do that if you use Flit build.

So,

there's a key difference here where Flit has a, has a Flit build command, which will do this.

But if you were just use the, the build project, like the build command, that's up on PyPI, like literally pypi.org/p/build, if you were to call that on Flit core, which is the build system use, it doesn't do that magic.

You actually have to specify in your pyproject.toml in a tool specific setting, this is what to include, or this is what to exclude from your S dist.

I personally, I want to be freaking lazy when it comes to this.

I don't know how I got into my source distribution.

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

So I went the ultra lazy route.

Um, okay.

And I've been using the Flit on this topic, but the Flit, but we'll just, I was saying that I just use the min, the minimal there.

Yeah, exactly.

I mean, 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, I'm one of those .venv people.

Um, but yeah, I'm the same thing.

Like I like the.

Tools to be simple enough that the, 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 does, does it really well.

And once again, as culture said, failure condition.

I told you.

You 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 VS code.

And I just used, yeah, hatchling or flitters, whatever.

Cause I'm only doing pure Python code as much as I can.

Cause I'm quite happy in my life.

I've been over throwing out a 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, uh,

to create Accenture modules.

So one project I did want to ask you about was you've got this PI launcher, which is quite cool.

Cause that would, um, when I started using Python on windows, it had this PI launch and it was awesome because I could install multiple Pythons.

I just go PI that version and it launched it.

And then you shipped it to, um, you shipped it to Linux or Unix systems or, you know, everywhere.

Um, can you tell us about that?

Was that part, was that VS code driven or was that separate or was that, no, that was Brett's work workflow.

Yeah, it was, it was a lot of work 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, 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 got to know about WSL about a month before it got announced.

Um, cause they wanted to come talk to us on the Python team.

And so I had to, I had to get used to developing for Python on windows and that was the Python launcher, right?

Uh, P Y.

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, they got from python.org, it was, uh, Python's not put on path by default.

You have to opt in with.

The clicking of a button.

Um, 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 launch the things that you installed is to use the Python launcher.

Cause it'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's 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 going to inevitably overwrite my Python command or my Python three 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 going to move to Fedora this year cause I'm going to 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 and the evenings weekends 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 make sure that when I type PI, it just launches the newest version of Python, not the last version I happen to have installed.

Cause 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 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 three points, the wrong thing.

It's like, no, I want it to be.

There's a security release with 3.7 and all of a sudden, I typically have all this installed cause I'm developing.

Yeah.

Packages that span versions.

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

It's 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 they'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.

Cause if it doesn't meet your needs, that's what makes you grumpy, right?

It's the, Oh, someone has feature a, you take it and you actually never use feature a, and yet you keep being bug reports about it.

And this usually when you start to go, I don't want to

it's building the parachute behind you.

It's like, you know, the drag coefficient.

Exactly.

And so in this case, because it was the, my.

Yeah.

Learn rust project and it was going to be my workflow.

It was just like, yeah, you know, I'm just going to do what I want.

Right.

So the launch has little niceties, right?

Like if you have a dot V and V directory, either in the current directory or up, it will just automatically use it and 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.

Cause once again, that's how I do it.

Every time I do a new checkout, Python dash M VAM dot V and V then now all I do is just pie dash and VAM 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 dot 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?

If you set it to pop.

I, the 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 VAM is and grab that name.

And if it doesn't, it'll say, if I run PI right now, it'll be that version.

When I go into a directory that has a PI project automa 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 inception 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 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 also give feature complete

yeah um rust did actually make it 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 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

you

still have some future plans to lean into my workflow even more but once again gotta have

enough time to do it yeah slowly slowly okay i guess then let's swing around to vs code because

vs code and python have been you know like gone well together and um it's a influential both will

and i are using it daily and thank you what what new what's new in vs code land and what what would

you like to what can you what would you highlight while you're here oh sure um so yeah just so

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 so 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 pylance

which is our intellisense engine and i'm not in charge of the jupiter extension which is separate

and technically language agnostic i've been recently been getting lots of these pop-ups

saying you need to you need to install the iso extension now you need to install the flake 8

extension and you need to install the flake 8 extension and you need to install the flake 8 extension

now what's going on yeah so so that's so yeah because you're interested about the 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 jay money uh joined microsoft full-time and bought

the extension with them uh which he released i think january of 2016 um don actually has moved

on to jupiter so i think technically i've been working on this extension longer than he ever did

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

so i had open source project don was very nice about taking the time to do this and i've been

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 meant be understandable by a whole team of people from varying ranges from

fresh out of university to people like me who've 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 the 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 uh 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 auto pep 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 out

the monolith that was the python extension and make it much more focused and make it 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 mentions the isort extension isort 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 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 in box because we actually vs code

all up always aims to have a very small fast experiences even for extensions and so shipping

just isort along still paid it 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's also my like we

didn't want to ship black in the box we didn't want to ship auto pet bait we didn't want to

ship flakey 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 i say it's an afternoon rpm actually was able to wrap i can't

remember if it's five or six hours i don't think it's five or six hours i don't think it's five or six hours

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 there's no extension from us but the other thing is by breaking these out for instance we

can now ship isort in box we can ship black in box and have it all just work on install time

instead of all right i gotta go run pipx to install it and then i'm gonna have to go 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'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 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 a workflow should be so for instance if you want to create a

virtual environment it will ask all right what globally installed virginal python do you want

um you check it and it will ask you to create a virtual environment and it will ask you to create

it we look for uh if you have prior project automl 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

going to have your requirements directory and stuff in there or requirements.txt or what have

you um we detect those ask which ones you want install install those we actually drop in a dot

git ignore 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 the

manager i get 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

and then i can do that right like conda is embedded 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 can do this for hatch do it for poetry do it for pip

and 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 can do it for all your interpreters and then you can do it

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 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 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 there's a whole other topic if you want to get

into that one uh but that's the other i'd forgotten about that yes web assembly as well but we i'm i'm

not sure we've got time where have we got time you're in charge no

we should bring you we should try to do we should uh do a second part

we totally can't i will the the teaser on that then for brett on django chat part two is we are

looking at we have made vs code at wazi runtime and so you're able to run python code with a python

interpreter compiled to wazi 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 that's going to mean that's going to mean running python on

ipad in a browser or something like that as well right because you should that was

yeah yeah fantastic wow 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 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 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 you said which means it's like one day a

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 i will so that's mostly all thanks to the work of steve dower

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 web assembly

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 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 yeah it's gotten so much better 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 you're going to be able to do a lot of things and you're going to be able to do a lot

like may 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 oh boy i've had so many dreams about this one um

maybe that's the third episode well no the other problem is is i happen to be in enough of a

privileged position in the community that if i really think it's at all feasible i actually can

try to make it happen so it's it's a magic wand that i hope actually comes true um what i will say

is i hope we as you pointed out will getting python right now has gotten a bit trickier

and i've 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

in powershell it will tell you hey you should go install python at the microsoft store right and so

it's just a thing that's going to happen and i hope that's going to happen and i hope that's

something you can solve 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

then unfortunately 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 a vim and pip right

so i would personally love to see us potentially and this is already being discussed so once again

pretz magic wand 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 credit away from anyone who deserves it um nathaniel smith

actually just posted a pep to bring what he calls pi bi's a python binary interpreter interface i

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 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 pi m where you're having to do the builds or

anything like that no having to run an installer there's literally just going to 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 just go download and install it right just make that work

um after that i think it's really just

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 world and we're so lucky to be in such a diverse inclusive world and we're

so lucky to be in such a diverse inclusive world and we're so lucky to be in such a diverse inclusive

world and we're so lucky to be in such a diverse inclusive world and we're so lucky to be in such a

diverse inclusive world and we're so lucky to be in such a diverse inclusive world and we're so lucky

to be in such a diverse inclusive world and we're so lucky to be in such a diverse inclusive world

honestly even with all the technological whatever 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 going to be weird warts and stuff

that guido 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 and i just feel like i

i've not helped climate change that way so we're not going to tackle the global interpreter lock

we're not going to go i don't know how many times you want me back on will but that's a whole

separate conversation i will that'll be episode three folks so i can actually quickly say about

that um we did just accept eric snow's pep that does add per interpreter gills

so sub interpreters are now going to be a potential possibility uh 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 that all have

their own gill that should now that should be doable in python 3.12 so that'll be interesting

the completely removing of the gill 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 pi pi 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 see that's otherwise

more time okay yeah third one is done

i mean that sounds very familiar similar to jango in a lot of respects yeah i mean it's the backbone

of everything right like i i see people go like oh why can't we just do this and 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'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

in this community um because it's such a wonderful place great 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 thank you a lot of hats you're wearing

well thanks for having me it's been great all right and everyone we are at jango chat.com

and we'll see you all next time bye-bye bye-bye