There's a whole PEP about that

Welcome to Changeloggin Friends, a weekly talk show about Python enhancement proposals. Thanks to our partners for helping us bring you great developer pods each and every week. Check them out at fastly .com, fly .io, and typesense .org. OK, let's talk. So we're joined by a tall, snarky Canadian. His name is Brett. What's up, Brett? Hey, guys, how are you? Very good. I like to call you tall, snarky Canadian because it feels almost like, not an insult, but it almost feels like edgy, except for you call yourself that, like it's your website. So I have the freedom. I can just call you that, and I know you're not going to be mad about it.

Correct. I'm trying to at least be honest about who I am.

You have no problem being tall, being snarky, or being Canadian. You just own all three.

I tried my best.

You have to own the negatives about you, I suppose.

Yeah, well, and it's a fun little dichotomy slash contradiction, right? People typically do not think most Canadians as being snarky, so it's a slight ode to having grown up in the States, even though I am Canadian.

So you have a bit of snark.

Yeah, and my wife's pointed out over the years that, yeah, you can cut the snark down a bit.

He's like, I can't. It's on my website. I have to embody my tagline. Adam, I knew you were snarky, and we knew you were Canadian. But we, I don't know, I forgot, or I never knew exactly how tall you were until we just met you for the first time in real life. And you are tall. I can confirm it. So tall.

Yeah, I'm 198 centimeters or 6 foot 6 inches in US customary.

That is, that's pretty tall. 6' 6". Yeah.

Funny enough, a friend of mine, Thomas Wootters, who's one of the core developers on Python, he lives in Amsterdam. And he was telling us a story the other day about how there's actually a tall person, like, club in the Netherlands. And to be a member, you have to actually be 200 centimeters to be, because they're tall in the Netherlands. Wow, that is cool. I'm just above, at the upper, I was above average, at least there. So it's all cultural relative where you actually are, whether I'm that tall, really.

Kind of a club is just like tall people only, you know? Like, can't we rally around something a little bit more in our control, you know? Yeah. You think they're like, hey, can you reach that for me? Can you get that up there for me? All the bar is just super high.

The taller of the talls. I know how to change many different types of light bulbs now. So that's handy. And how to kill bugs and get cobwebs in corners. I will say flying is not pleasant. And finding a car that I fit in is a real pain. Actually. You drive a Tesla, though. Well, yes. But that's because I found a car that I

fit in.

I do fit in that. But for instance, when we were looking at EVs, because we actually had a VW, but we had to give it up as part of Dieselgate.

Oh, yeah.

We went around and looked. So many gates. Yeah, so many gates. I actually could not get into a Nissan Leaf. Literally could not get my legs into the car.

I can imagine watching that debacle. You trying to get into one of those? So do you want to buy this car? I guess not. I can't fit in it.

Yeah, I mean, thank goodness for North American and German manufacturers making cars for taller people.

We're good for them. Got to be inclusive of you tall, snarky folks. You know who else is tall? Which I found out when we were in Vancouver, by the way. For our listener, I mentioned we met Brad for the first time a couple of weeks ago, months ago. I don't know, years ago. It was recently. Time is a continuum. And that's how we realized, yes, indeed he is tall. You know who else I met for the first time and I've known for years? Adam, you as well, was Farras, a bukadijay from our JS Party podcast. He is also tall. Very tall. And was a surprise, because he doesn't put tall wizard. What does he call himself on his website? Mad scientist. Yeah, there it is. The mad scientist of open source. So that was a total surprise. And then Byung -woo, he was quite tall as

well. Why is everybody so tall? The funny thing for me is that people forget. It's not like it changed. Like when I go to PyCon US every year or PyCascades. They're all like, wow, you're tall. Yeah, literally every year people go, wow, I forgot how tall you are. It's like, I've known you for a decade or more. How do you forget this?

It's like Canadians and weather though, man. Like you've got to talk about the weather when you meet for at least five minutes. That's just how it works. You've got to forget how tall somebody was. Is that a Canadian thing? Talking about the weather? Yes,

it

is. We talk about the weather here in the States quite a bit. I mean, they will have a good 10 or 15. They will be excited about it.

Well, it's the national competition. Yeah. Who's got the worst weather that day? Oh, the worst. So it's like golf. Or the best, depending on where you're coming from. Like, oh, I want to complain about my weather. So I get to say I have the worst day. All right.

And whoever wins, you know, it's like, well, OK, fine. You've got the worst weather there.

Or, oh, I'm sorry. I can't brag about how good our weather is here today. It really depends on which angle you want to win on that day.

Because you'll just be bragging and rubbing it in. See, that part of it, I appreciate. Like just the opportunity to win something, you know, in conversation. Like, I can appreciate that aspect of Canadians, I suppose. It's like, well, how can I win this? I'm always asking myself that question. So competitive. Like when I'm going to pip install something, how can I win this pip install? How's that for a professional transition? Do we want to go there yet?

Go for it. It's up to you.

So the last time this might become confusing because we just had Matt Reyer on changelog and friends episode four. Matt depends. Coming soon from changelog. But months ago, we had him on the changelog. It was a changelog and friends prototype episode 526. And I only have that memorized because I just said it last week when we had him on this show. And I was confessing to Matt and Adam my pip install anxiety, mostly because a lot of the new tools specifically it was whisper, I believe. But a lot of the new, you know, fancy LLM AI things are Python things, which as a non Python regular user, it drags me back into the ecosystem, you know, to install these things and to handle these things. And so I was confessing to them that I have this anxiety with pip specifically. Not only with pip, I also have this with Ruby gems and I have this with NPM sometimes as well, where it's just like, I sure hope nothing goes wrong here, because if it does, I'm going to switch tasks and not try to fix it or not have a good day. One or the other. And Brett wasn't listening because he listens on a six month delay. But when we saw Brett, we said, hey, you have to listen to this because I was dissing on Python. I brought it up a couple of times and Adam was like, Jared, you're really anti Python. I was like, no, I'm not. I just have this anxiety. And so Brett being the our resident ambassador to the Python community, we should mention, for those who don't know you, a member of Python's steering committee, is that was called steering committee steering council. But yes, during council.

What's

the difference between a council and a committee? You just pick which one? I think so. Yeah. And so you're you're our ambassador to the pythons pretty much. Is that right, Adam? I mean, I'd say

so. Yeah. Apologize to the community on that one. So

if you don't think Python's well represented here on changelog shows email Brett, but he might give you some snark on the way back. And so we asked you to listen to it, basically, because we feel like, you know, if we're going to dis on Python for a while, we should give you all a chance to respond. And you responded in kind. Actually, I told you to respond. I was like, listen to this and blog about it.

Yeah. You said, have you listened to this yet? And you both joke, probably not knowing full well that it takes me a while to get through podcast episodes since I don't have a commute anymore. And you said, yeah, you want to go to read this episode? I said, why? I said, oh, I said some things. Basically,

I said some things. It's like a diss track.

I think Adam basically said, you might want to listen. That Jared said some things about Python in there. It's like, why would you say? Just go have a listen. And then I read the transcripts like, oh, and then I went and listened to. So I can make sure I heard the tone appropriately. Like, oh, OK. And then that's when I said, I messaged you two and said like, OK, you asked me to listen to this. Where do you want your reply? Right.

And then Jared said, just write a blog post. And so I did.

Well, you're a blogger. I mean, you write quite often. So I feel like that was a good place to put that down. And then I thought, well, I'll write a response. And then I was like, but I'm not a blogger. So what I am is a podcaster. So let's just talk about it. That's a lot less strenuous for me. So we have your post here. It's in response to the change log number 526. And if I might just summarize your point and we can open it up from there. I think what you're saying is you don't have a virtual environment, Jared, and you should. And so this is why you have anxiety, because you're afraid that it's going to blow up your system in some weird way, which is true. Like, I'm afraid I'm going to change things in some way that I won't know how to back out of. And if you had virtual environments, you wouldn't have this anxiety. Is that pretty much your argument?

Yeah, it was basically that I know people historically, at least especially from a Unix based perspective, whether that's Linux or Mac or whatever. Enough tooling now is written in Python that people have historically been scared about basically breaking their Python install, because that might break some OS level install. I will say Linux distributors have gotten way better about that. For instance, Fedora now has their own private copy of Python for their use that you don't get direct access to. So when you install Python, you get your own copy. So if you screw that up, it's not going to break your system. I don't think Debian and Ubuntu thus have done the same thing. So that's still a potential risk. But yeah, basically, I said in that post, virtual environments are the tool that the Python community has to isolate things. And I also took a dig at Adam for saying, I wish everyone would just make it available in my Linux distro. And I point out how hard that actually is. But yeah, it was basically, yeah, you want virtual environments and point out some tooling such as PipEx, which we can talk about as ways to do that in a much easier fashion without having to really be immersed in the Python community.

How do people come to Python? So I think some of this might just be like marketing, you know, in the broad sense of the term, like marketing problems, because as a person coming to a tool and an ecosystem, not necessarily wanting to write Python, but use Python, I don't have information about this kind of stuff. Or maybe I do and I'm not looking in the right places. But mostly I'm like, OK, I know that Python's installed on my Mac out of the box. I don't know if it's Python. It's

actually not installed in the box anymore. Oh, for Mac OS? Yeah, they took it out. Yeah, I think Ventura was the...

Why'd they do that?

They actually took out all the languages, I think, like Ruby... Dead language, dying

language. Yeah, right.

They're done with it. Ruby's still there, though. Ooh, which Python? Python not found. Which Ruby? User bin Ruby. Oh, user bin. That's not homebrew.

The gauntlet's thrown. I was going to have the snarky, humble brag that, well, if you're young enough these days, you know Python because it's being taught to you in schools, so everyone knows Python. But no, actually, I don't know why they took it out specifically. There was a move at some point at Apple to try to have less stuff directly in the box and stuff that people rely on because it used to, I believe we were told it was used to generate the cover letters for the fax app way back when. The fax app?

Seriously, it was some odd thing. I don't know what they could use it for, but I think their use of it stopped. And so they just took it out and they just didn't need it anymore.

So, OK, so maybe I go to Python dot org. I know what I did because mine is opt home brew bin Python three. So I know what I did was like brew install Python.

That's what I do

personally. Where do people who don't know what to do go? Do they go to Python dot org? Do they Google how to install Python? What do you think people are finding? Like, where would I get this virtual end information from? Like, is it on the Python website or is it like the happy path?

Yeah, see, that's the tricky bit. And something we've actually run into in my day job, because I'm the dev manager for the Python extension for VSCode. And one of the things we run to is where the gaps of knowledge are in the community. And we've discovered there's kind of two camps when people are taught Python, even just explicitly taught and people who just kind of fall into it because, oh, as Jared said, I want this tool that happens to be written in Python. What do we need to do to get it versus, oh, I'm learning Python because I'm going to actually use the language. And even when you're taught, there's a gap. Some people don't like teaching virtual environments because it's kind of this extra step. So they want to start simple and not go there. And some people go, well, you know, you pretty much are going to need this the instant you want to install anything. So we should just teach you this up front. And chances are you're going to want to install something at some point from PyPI, the Python package index or somewhere. We should just teach you up front. And to be clear, I should clarify exactly what a virtual environment is and kind of why this gets a little tricky. Thanks historically to Debian and Dasapuntu. So a virtual environment is kind of what it sounds like. It's an environment that's virtual, which I know. But it basically creates a directory as a very specific directory structure. And I do have a whole blog post that explains how all this works. And it's very straightforward. But it basically creates kind of a personal bins and lib directory on Unix. It's scripts and I believe just site packages on Windows. And it basically just it's a directory where Python recognizes that it's being run from such a directory because there's a configuration file. And then Python just goes, oh, you're running from a virtual environment. I won't put anything you installed globally on sys .path, which is the search path for stuff in Python. And if you're using installers like PIP, they will recognize that you're doing in a virtual environment and go, OK, I should install into the virtual environment, not into like where the physical copy is, because on Unix, they're all some links. And that's basically it. It's not a complicated mechanism. If you look in the code, it literally just goes, OK, from where the binary is on that first argument to sys .argv. If I go up a directory, is there a file called pyvenv .cfg? If the answer is yes, I'm in a virtual environment. If there isn't, I'm not. That's it. It's like the mechanism is really straightforward and simple. But the key thing there is that mention of if the installers in Python notice I'm in a virtual environment, the tools all install into that virtual environment. So it gets put into that little subdirectory you created for your project and thus it isolates it. Right. So that environment becomes isolated from everything else, which makes it easier for reproducibility, but also means you won't screw up your system install because you're not going to install the global directory in your user bin or user lib or whatever, wherever you happen to have Python installed. So it keeps that all kind of cleared out. The problem is, A, knowing about it and B, making sure it's even available. For instance, Debian historically has actually not shipped the module you typically use to do this. So in the standard library for Python, there's a module called venv and Debian does not ship it by default. Now, their policy on Debian is you do not package multiple apps together because venv has a command line interface, because usually the way you do this is you go like Python dash m venv and then a name of some subdirectory like dot venv is the kind of convention. But you can call it whatever you want. That'll create the virtual environment in that directory because it has a CLI, Debian considers its own app and they ship it separately. And it's not part of the default install. So if you go sudo apt -get install python3, you get Python, but you don't get venv. You have to do a separate python3 dash venv install. And you also don't get pip. So that's a separate python3 dash pip install, which is an extra stumbling block for people.

These are things like you need, though. Why would they not include that by default? It's like they're kind of crucial to Python, right? You want to pip install things. You want to prescribe this venv thing that you got to use to be protected from botching your system. Yeah, this is addressed in pep eight tells us why we can't do this or something.

So as I said, it's Debian policy, the way they package things. The Python steering council actually had a meeting with the Debian equivalent. I don't know if they call themselves a steering council or committee or where they choose. It's actually a committee council. They are

a committee around a council. And then another committee inside that. There you go. Circles

and circles.

Yeah, that's bureaucracy right there.

Anyway, we did meet with them and we had a conversation with them. They were very nice and friendly and totally happy to talk with us. But they said, like, look, this is the Debian policy that we view this as an app because of the way it looks and structured. And we don't ship multiple apps in a single apt package. So we're making it separate. Luckily, in the next release of Debian, whenever that comes out, as I know that you have multi year cycles, there's going to be, I believe, a Python three dash full virtual package that will install all that at once. But that is not out yet. That is not available yet. And all those instructions on the Internet will have to get updated to say install Python three dash four when you're on Debian, which unfortunately trickles directly into Ubuntu. And that's where a lot of Linux people get tripped up. Right. But other places like Fedora and stuff do the thing you'd expect where if you just install Python three shipped with all that stuff in the box.

So this is the issue right here, at least for me, to some degree. So I got a backtrack. So I said, which Python? Yeah, not which Python three. So I did install Python three via homebrew. Then I also have a version of my user, my user bin folder that's Python three. I didn't say which Python three, I said which Python. Oh, so you do have a user bin Python. Yes, I'm correcting that it is installed by default. OK, so I think you've installed it. I also think you've installed Ruby. Yes, I did. I think Brett's right that neither one of those come with the he was ringing a bell when he was starting to say that at one point they took all those things out. And so I don't have either of those things. No, if you LS your user bin folder, I bet you'll find a Python three in there. Well, let me make sure I'm 100 percent true on dognabbit. You're right. Mm hmm. So is there. Yeah. So that's the kind of the rub to some degree. If you're like not steeped in Python daily, you forget to add the three and then you're searching for just Python. That sounds silly, but I'm with him because I had to even with homebrew, I had to remember I was Python three. It's not the word Python. Now that's a homebrew thing, right? Or is that like the way you guys do it now?

Well, Python three with no Python.

No, like the Python community. If I type Python, it doesn't show up. I have to type Python three. This is like

upgrade versus

update,

Jared. There's a whole pep about that.

There's a whole pep about that. I think we just found our show title. There's a whole pep about that.

So actually what happened was is so during the Python two to three transition, which is now old enough history that I meet plenty of people who don't know what the heck that even was. Yeah, they don't even know what happened. That makes me feel old. Yeah. Hey, try being a part of that whole transition and making that actually come to fruition that. Yeah, I feel like I

don't know. I might burn out if I did that. I might burn out.

That could be a whole separate episode. Yeah. So what happened was is Arch Linux actually decided at some point that because they went Python three only earlier than most. They decided, yeah, maybe we should re relink or rebind or whatever term you want to use, point Python as a command, simply get to Python three and have that be what Python points out. And the problem was is it caused a huge amount of confusion because at that point, the transition in the community hadn't happened yet. And because we just didn't have the foresight to make it a Python two, it led to a lot of confusion. So we wrote a whole pep about it and just tried to give guidance to Linux distros of like, OK, you're the ones who are kind of doing this because you don't people don't get it from an installer typically on Linux. They usually just have the system install, which is obviously a change bed. But at that point, it had happened. So we said like, OK, here's what you should do. You should have Python three. You should only do it to Python, probably way in the future when there's zero potential confusion. Wow,

what a headache. So this this whole Python two to Python three transition. How long do you think it took? Obviously, there's no hard edges from Python three to Python two. Like like let's say like 80 percent rule to have most people moved over because it seems like it's in the past now. But when did it become past?

So Python three point zero came out, I believe, December of two thousand eight. OK, so there's one edge about a decade. So, yeah, I would say roughly there I'd have to look up numbers as to when. But yeah, about twenty eighteen, I would say seems fair for roughly that. I think it was maybe twenty fifteen, sixteen when we maybe had 50 percent. There was a really key tipping point where it kind of went fairly fast after that. But it did take quite a while to really hit that point.

So this whole time, as a member of the Python community, were you just thanking God that Pearl six was a thing? Because like, isn't that it's not like the only other even more notorious version problem?

No, although I did. I did watch and I did feel bad for them that they were having to go. Yeah, it's the exact same thing. Yeah, it's no fun, I'm

sure. The key thing for us was while the breakage was in hindsight unfortunate and things went the way they went, we did continue to improve the language and add features that tempted people more and more to want to switch. And that was what saved us was because it was on a wholesale rethink, like Pearl six seemed to feel like from the outside. I'm not a Pearl developer myself, but it seemed like they kind of went off the deep end a bit more like, OK, this is really our chance to reset things. While ours is more like we just need to make sure we have Unicode everywhere because languages are a thing, more of a change than that. So while it wasn't it was still enough to break people's code, it wasn't enough to go, Oh, my God, the transition is huge and it's a lot of work and all that. And we had to throw out a lot of code and redo our VM. Like we were able to just take the CPython virtual machine from Python two to Python three and just change it to upgrade it. Right. We didn't have to do a wholesale rewrite, so we didn't end up like with Pearl sixes. I was a pug was like the one written in Haskell and parrot and all the other VMs that came about because of that, because it wasn't a wholesale redo. It made our lives way easier in terms of maintaining it.

I think they ended up just renaming. I think Pearl six was so different that they actually eventually renamed it to something else. Let me confirm that. Well, if we have to, we can call it the Anaconda. It's my can't. My Anaconda don't want none. You know what I'm saying?

You do know that's an actual tool in the Python community, right?

I bet it is. They call it conduct. Well, I think at this point, almost every word is a tool. Raku Raku is a member of the Pearl family of languages formerly known as Pearl six. It was renamed in October 2019. There you go. And introduces elements of many modern and historical languages. Not compatible with Pearl. Yeah. So this is the design process for Raku. Well, yeah, in the year 2000. So Pearl six renamed Raku. And if you're going to depart that much from your, you know, other version, might as well just give it a new name and start fresh. It's like calling it mojo, you know, maybe just call it mojo. Is that much changed in your opinion? Is that backwards compatible change? Like, how would you describe that change? Like, is it drastic in terms of like Pearl six? Yeah. I'm with Brett. I'm not a Pearl monger, as they call themselves. Is that what they call themselves? They do Pearl mongers. Cool. I think so. They used to at least confirm that too, Jared. Let me confirm that. I'm just second guessing myself left and right here, but I think I'm correct on both accounts. Pearl mongers. The reason I know that is because there's a local Pearl mongers group in Omaha. Yeah. Pearl mongers is an international association of user groups of the pro programming language. So my history does serve well, but I know pro monger. So I don't know. I just like read the news and follow it along. I remember a lot of Hemen and Han about Pearl six, and it just like never being either not ready or just way too dramatic to the point where in 2019 they renamed it. I mean, that's how much different it was. So it was not like we're adding Unicode support and maybe that will break the way you would do strings right now. It's like, everything's different. It's a new version of Pearl and not called Pearl anymore. Is it,

I don't know. At least that version.

Yeah. Were you there then for this transition from Python two to Python three? Like you were a part of the steering committee. Like what were you, what was your role in the community at that point? Well, it was pre committee, right? Pre council.

Yes. Steering council didn't exist yet. That didn't come about until 2018 when Guido retired. But I was a core dev. I was involved. I actually was coauthor on pep 3 ,100, which was the miscellaneous pep that collected all of the various little changes we were going to make that were not big enough to need their own Python enhancement proposal to go through. So I was directly involved. I was part of a competition implicitly who can delete more code out of the three. So

that'd be fun.

I was around and actively involved and I will say I am part of the reason Python three happened. Wow. Take the blame or thanks, depending on your viewpoint of how it turned out.

Pythonistas around the world. Thank you.

Yeah. Right. Or hate me. Depends on how long you've been in the community.

Okay. Well, I don't know about much about Python two. I know that I now have reputation of dissing on Python because Adam gave it to me, but I'm a big fan of the language. I really am. I used it for six months, almost full time and really enjoyed that time period. I like significant white space. I think it has lots of the stuff that I look for in language built into it, especially probably over the years those things got built in and I have to read some Python code every once in a while just to do stuff. And whenever I read it, I'm like, nah, this makes total sense. I mean, I think it's solid. Well, to be clear, we weren't dissing on Python itself. We're dissing on the PIP install process. It's just the PIP thing. They're very specific because yeah. Yeah. Cause you don't know where it's going to end up if it's in a botch, something and how it works. And it's just cause you're unfamiliar. You don't do it daily. So it is, it's mostly that,

well, there's a couple of aspects of that. So one is, is you're right. There's lack of familiarity with that key bit of technology, the virtual environments, which I will say there is a tool that is available called PIP X. And what PIP X was designed to do was specifically to help you install command line tools from Python package index. So what you do with PIP X and you can install this with app get or DNF or whatever, homebrew, whatever you want. Right. It's designed to be packaged independently on its own. You can do a PIP X install, whatever, and it actually creates a virtual environment in your home directory for that tool. And then as long as you put that bin directory on your path, that's the easiest way probably to get tools on your path that are not already repackaged by your package manager, whether it's homebrew or app get or whatever. Like if someone has a Python app that you want, that's not packaged that way, PIP X can always do it. The other nice thing it has is it has a PIP X run command. Like you could do PIP X run whisper. I think Jared, you said the tool was that got you down this rabbit hole. What that does is actually we'll download and install it into your temp directory and then run it. And then it continually checks there if it's there. And if your system clears it out, it just downloads and reinstalls it in, which makes it a really kind of nice way to do ephemeral installs. Like I just need this tool every once in a while. I don't need to install it now. And I don't want to think about upgrading it later. So like if it's a occasional thing, PIP X run, whatever quickly does the install, get to use it, as I said, it gets cached in your temp directory. And then if you forget about it and your system cleans it out, no big deal. It installs it again. And that way you kind of always implicitly get a fresh version that you can just use versus, Oh, I installed it permanently. I got to remember to upgrade it on occasion. Like I personally just always use PIP X run with any kind of tool I need to use from the Python community because it's just fast and easy. That way I don't have to think about, did I update this recently? Or is this like six months old? And I'm actually using an old version because, you know, with CLIs, there's no API to tell you, yeah, broke. It just might have some weird bug. So that's how I typically do it.

Very cool. Yeah. We'll link up this PIP X. This looks like exactly what I need to just not have any more anxieties, just brew install PIP X and just go from there.

Yeah. And I think as a community, I think I mentioned this in the blog post. It's just something we just haven't gotten into the habit of documenting for those who aren't in Python, right? We, once again, humblebrag, we take it for granted. There are people out there who don't use Python regularly, right? Python's everywhere at this point. Like when kids are getting taught in school, I mean, it blows my mind to this day still, but also just, you got to remember people don't know this stuff. You're not necessarily in this world, right? You might be doing Elixir every day and you might have that little random Python script and you might still be using Python, but just cause you need that little Python script to do your thing does not mean you've been told here are the best practices of how to do things, right? And unfortunately, we just don't have that habit, especially when it's your community, right? Like, Oh, I'm a Python developer. I'm running the Python tools. I'll put this little blurb that everyone puts on use PIP install, whatever, or Python dash M PIP technically is what you should do, but you don't stop and take yourself out of the space of, okay, well, what happens if I'm not a Python developer, but I still want this tool. And you're like, what's the easiest way I can tell people to do this. It's either you put in all that time and effort to get into the package managers, which is a lot, right? Cause every Linux history has its own package manager and their own rules for getting stuff upstream, right? This was the thing I pointed towards Jared in the blog post, right? Like, how do you get into apps? How do you get into DNF? How do you get an AUR for arch? How do you get into free BSD ports? Getting into home brew. Let's not even covering scoop and chocolatey on windows, right? Like, and that's just off the top of my head. That's not even covering all the other Linux histories have their own way. So if you don't want to put it in that effort, what's the easiest way to do it. And I would argue PIPX is pretty close to it because that has been widely packaged and made available to people as a single install without having to know how Python works and it's there. It's just, I don't think the community has that habit yet of just going, Oh yeah. If you don't know Python, you don't want PIPs not a thing for you. Go install PIPX from your package manager for your OS and use that thing to run this tool and it'll just do the right thing. And we just need to get that habit.

Yeah. Well, thankfully you got that blog post out there pointing to PIPX cause that is helpful. PIP run easily doing that. Or even the zip files that you mentioned PIPX run to be very clear. What happens when we have to deal with Python 4?

I don't know if there'll ever be a Python 4. So that's actually part of the trick here was the Python 2 to 3 transition was so burdensome and so basically scarring for the community on the core team. We've actually talked about potentially never doing a Python 4. Just because we never want to do what we did with Python 2 to 3, right? Like when we did that, I don't want to say it was hubris. I know some people accuse us of that, but it was honestly up to that point. The Python community just came along with the core team when we made changes to language and we thought people would see why we were doing what we did for Python 3 and they would just come along. And yes, it'd take a little longer than normal, but at that point, historically most people upgraded within two years at worst to the latest version on Python. Like they'd basically skip maybe a version two, three years, they'd be upgraded and do it this time. Too much work to upgrade. People said, no, you're not giving me anything new here. I don't need Unicode. Why do I need Unicode? ASCII is great. All this stuff. It was a real slog and everyone, even not from the Python community now knows about the Python 2 to 3 transition, right? Like there is like folklore around this at this point.

Yeah, it's notorious.

Yeah, it's notorious. So if we go from three to four, are people going to assume it's the same thing? Like, Oh my God, they're doing it again. It'll be an uphill battle. They're doing a whole nother major version upgrade. Even if we didn't mean to, right. Even if we had a clear transition plan and planned out even, and within the community, the, in the community knew everyone outside the community would go like, Oh my God, what the hell are they doing? So we've talked about like, yeah, maybe we never do a four or what would take us to do a four? Like, I mean, there's both camps. It's like, maybe we should do a four and make it completely innocuous and take away that whole mystique and start doing Python five, six, seven, or switch to a date based one because now we do annual releases like switched up Python 23 for a Python 2023, once again, totally throw the, what the major number versions because

you're back to doing the windows stuff again. Windows 95. Come on now.

Yeah, exactly. Right. But it's one of these things it's people don't understand what the numbers mean because Python predates semvar, right? So since we don't really have semantic versioning with those numbers, people don't really have that proper association because some people just assume it's semantic versioning and it's not, so you do annual releases. Yeah. Every October, uh, on, we try to aim for the anniversary of the first broadcast of Monty Python's flying circus in October.

Well, that's important. That's an important date right there. I like that. Okay. So is that like for major features, but there's still like bugs and patches and stuff throughout the year. I mean, how do you guys about

every three months, two, three months

video bug fix. Okay. It's like a patch release. Gotcha. What kind of big stuff is in the works that would like require even a four, you asked yourself that or, you know, what's like an annual feature that's like maybe in the works right now, some big stuff.

Oh, that might call for a four. So probably

kind of stuff you're working on.

So the things that kind of trigger this kind of conversation, once again, there's zero plans. It's for there be a four to be very clear. I don't want anyone to misread anything I'm about to say

this October Python four it's coming

out this October. Python 3 .12 will be coming out this October to be very clear, but there's kind of two things that lately have caused people to have like, maybe this should be, is this going to be the thing? Maybe we shouldn't make this the thing that do Python for one is our C API. We've been slowly trying to clean it up and make it a little easier to work with and more backwards compatible and make it easier for people to work with. And we can actually talk about that later because it turns out the whole reason packaging and doing all this virtual environment stuff even exists is because everyone's used Python as a glue language of the internet, which is a blessing and occurs. But we've talked about changing that and obviously C does not exactly have great mechanisms for backwards compatibility. So we've talked about if we did a massive switch to some better C API, would there be a way for us to brush the old one away and be able to talk about, well, let's figure out a good transition plan from the current C API to a newer, better long term C API. And then when we're ready to brush away the old C API, let's make that Python for and just say like, if you use old API and you didn't make the transition, we're sorry, we're deprecating all of it's going away and that's going to be the Python for them. The other one that's being very actively discussed right now, not because of potentially Python four, but just, it's literally an active topic is there is a PEP, I believe it's 703, is a PEP to remove the global interpreter lock for C Python. And that would bring true threading to Python programs. And people have talked about whether or not maybe that would have been a thing to cause Python for because that global interpreter lock that Python has, right? There was never more than one Python thread able to run at once. The only way you could have threads doing their thing was at the C level where you released it, go off, do your C thing with no Python objects and then come back and require that lock. The thing is, once again, C API changes to make that work like literally the C struct headers that are going to have to change. So there's going to have to be a separate compile target for what we call Python wheels, which are the precompiled extension modules that you can get for Python. It's potentially going to shift some things for Python code a bit from code that's just not used to it, right? There's potential enough upheaval because of this. If we do this once again, it's active. It's not officially been accepted that some people have talked about, well, maybe this should be the Python for that. We start a transition where we have both available, both a Gil free and traditional Gil builds a Python. And then we reach a point where we say, like, hey, in five years, we're ditching the version with the Gil and then the no Gil version will be the one we stick with. And that'll become the Python for a version when we ditch the old version. And that's another thing that's come up about discussing is this going to be a Python for

the uninitiated describe the reason to have a global interpreter lock and then the pros and cons of either side, because these are tradeoffs.

Oh, yeah. So Python uses reference counting for garbage collection, right? We don't have an actual garbage collector that does like traces along pointers and all that stuff. It's all literally reference counting. So every time you make an assignment, it increments a counter on that object. And when that reference goes away, that counter goes down. And when that counter hits zero, that means that object has zero references to it. So you can clean it up and free the memory. The deal is, if you have threads, as we all know, we have things called race conditions and you don't want race conditions with your reference count, because that's how you end up having memory leaks. The problem is, is if you put a little lock on every single object, your performance sucks, right? Because that's a lot of locking and unlocking and no one wants to put up with that every single time you create an assignment, especially in a dynamic programming, which is like Python, where you don't have a compiler that can eliminate things because they can take a holistic view of the code and go like, oh, well, I know this will hit zero here so I can skip all the reference counts or whatever. So because of that, we had a global interpreter lock that basically act as the lock for every Python object. So you never had to worry about screwing anything up in terms of your reference count. But it had other knock on effects, too, where we didn't ever have to design any of our data structures to worry about race conditions. Right. There are no locks on appending to a list or adding something to a dictionary or deleting anything from any data structure. Right. Because we had the global interpreter lock, we were able to design the entire system to have the best single threaded performance we could and not have the cognitive overhead of having to worry about threads at any point at any time in the code base. And once again, this is all written mostly in C, so it's not exactly high level stuff where it's maybe a little easier to reason about. But the problem is, is we now live in this multi core world where people want a way to use all of those cores. So it's been looked at over the years and people have never been able to find a way historically where we can get rid of that global interpreter lock and not take a nasty hit on single threaded performance. Because once again, most Python code at this point is not written for multi threaded scenarios. And so if I came to you, Jared, for instance, said, by the way, that app you want to use is now going to run 30 percent slower. Would you have been happy? Never.

Right. So it's one of those things that's held us up from trying to do anything about it, because there have been various scenarios to solve it without completely redoing how the garbage collector worked, because that's really even worse, because this whole incorrect dec ref thing is just baked into the C API and just how the whole thing functions. It's baked into C code,

ancient

legacy,

like the underpinnings of Python.

Exactly. And because it bleeds out through the C API, it extends outside of C Python itself as an interpreter. So we can't kind of keep that under control. It just it's out of the bag. There's nothing we can do about it. But the GIL is under our control. So we could theoretically do something. And at this point, Sam Gross from Meta did the work and actually got it down to roughly, we think, about a 10 percent performance loss on single threaded code. But it does allow scaling with threads to number of cores, roughly. And so that's where we're at with this. It's a better tradeoff. Yeah. Yeah. And that's the question is, is it a better tradeoff because.

Well, it's better than 30 percent, but is it still better? Right.

Yeah. Well, and the thing is, is we've all end up with more and more cores because CPU manufacturers have not gotten past physics yet to make the single cores that much faster. It's just, no, we're going to throw more cores at it. But because we've designed the entire system around this global interpreter lock, it's complicated to add it in. And that's kind of honestly, I think, where this whole conversation has ended up is I don't think it's necessarily even about the single threaded versus multi -threaded performance hit. It's more, I think, heading towards a can we handle the cost? Because once again, the whole code base has been coded this way. What are the bugs going to look like? Is the whole Python community ready for threaded code? Right. Because we don't have the historical tool chains and experience of writing threaded code in the Python community. Everyone's just used to, I don't have to worry about the global interpreter lock, make sure I don't screw my, shoot myself in the foot. And on top of that, are the core devs ready for it? Because once again, you might not have experience as a Python core developer knowing how to write threaded C code because you never had to till now. So those are kind of the open questions we're going to have to answer for ourselves before we decide, yeah, we're going to do this. We're going to join the multi -core world this way and do it because we also have other things too, right? Like we just landed what we call sub interpreters where you can have multiple interpreters in a single process. And those actually have a per interpreter goal. So it's still threaded, but it's more like Erlang, right? Where it's actor model in a way, each interpreter is isolated, runs on its own and it gets its own gill. So those can all run in their own threads. But at least within that interpreter, it's still single threaded. But that just landed in 3 .11. And so that's not really gotten wide usage yet. And we didn't launch a Python API because we wanted to get feedback from the community. Like, does this solve a problem for you? Is it enough? What kind of API would you want? It's really it's actually sorry. It's going to be in 3 .12. I'm sorry.

Oh, it's not even out yet.

Yeah, it's really, really going to be new. And we just don't know what the experience is going to be. The hot topics that could that I won't but have caused people to go like Python for maybe.

How do you have time for the rest of your life with all these conversations going on? You know?

Well, I don't get to coach as much. That's how I find the time for all these conversations.

Oh, you just talk. I see.

Yeah. I mean, so I'm a dev manager now. Right. So I have reports. I basically in charge of the Python experience and VS code if you don't count Jupyter stuff and the autocomplete and it leads to a lot of talking, which is probably good because if you can't see on the screen, I have RSI my thumbs right now. So it's probably good that I'm not typing too much these days right now. But it's tough. I don't get to code nearly as much as I used to. I tried to find the time, but it is honestly a lot of talking I have because I'm a steering council member. Right. It just innately leads to a lot of talking and kind of thinking and positioning and less coding things up to make things happen. I've also been a core dev now for 20 years. I just had that anniversary in April. Congrats, man. It's a milestone.

That is a long time. It is. Yeah.

It's kind of convenient. Basically, as long as the PyCon conference has been around is how long I've been a core dev because it's I literally got my commit rights like the week or two after the first PyCon. So it makes counting really easy. Also, because I've been around long enough, I'm starting to become the institutional memory of the project because there's only so many people who've been around longer than me. And so it's also led to more trying to help the new. You're an elder now.

You're one of the elders. Yeah, exactly.

Right. Back when I joined, I was the youngest core dev when I got my commit rights. It's no longer even close to being true. We've now had people join who were in high school. So my record got shattered completely because I joined right after I got my bachelor's degree.

So you said you're doing a lot of talking, right?

Yeah. Coming on to podcasts,

podcasts, you know, maybe some types of conferences. He's an ambassador. You're on this show. But what other Python related places do you talk? Would you talk or are places people should pay attention to if they want to dig further into like a Python podcast or content world?

So if you want the equivalent of this podcast, that's probably the big ones. Talk Python to me or real Python. Those are the bigger ones that are more about week, roughly weekly. Someone comes on, doesn't have you talks about some topic. If you want something more like change like news, that's Python bites. There's a couple other ones, but those are the ones I'm personally on the most. Those are the ones I always recommend to people to check out, see which ones cover the topics the way they want, because they're all slightly stylistically different and just obviously different content.

How often do you get on a call with the steering council, the six of you or eight of you or four? How many people is it? Five. The five of you, like you five on a call, Zoom, whatever it is, Microsoft Teams, I'm sure.

No, actually,

it's Google. Oh, OK.

We have two members of the team from Google. So, OK. So yes, you battle over communication tools. Which

one am I going to use?

No, it means easier because it's just in the browser versus asking people to install teams. So.

Right. Anyways, how often does this happen, these council meetings?

It's every week for 90 minutes. Plus, anything we do outside of that meeting, including reading peps, keeping up with all the conversations around those peps, it's kind of actually funny. It's a little tricky being on the steering council and participating in the conversations because you never know if people are going to listen to your comment as you personally or as you as a member of the steering council. So it's a bit of a shift being on it in terms of had to be very careful about when I express an opinion because people take it a bit too seriously. Like I've said things and they start changing the pep to meet my comment is like, whoa, it's just my idea. It's OK. You don't have to follow this. Right.

That's because you're an elder. They're like, Brett wants it changed. We have to change it

to an extent for some things. But for other things is also the added steering council weight to it. So it's one of those. I have to be careful to not overstep and give too much out there because people will just listen to me as a personal comment. I even talked to my four council members friends about my thoughts. And I have just thought of it at the moment. And suddenly they're changing the pep for me. It's like the other four me completely disagreed. So but this is my last year on it. So don't worry about past end of the year. Are you running for

reelection? Are you actually retiring or are you just your time is up

from the steering council? It's technically a retirement. But when we were deciding our governance structure, I personally stated I thought five years was a good amount of time. It's long enough for a whole length of time of support for Python version today. These days we support a Python version for five years. It's the release. And then you get bug fixes for two years and then you get security fixes for three and then hits end of life and we stop supporting it. And I always said like, yeah, it's good that you can start with a version. And that's kind of the version you start with. And that's the version you kind of shepherd through its life. And then when it ends, probably good time for people to step off. We did not put on term limits when we started. But I think term limits are good. I think turnover is good. I shouldn't be constantly voted on due to people just going, oh, it's Brett. I'll just keep voting him on kind of scenarios that like I would want people to want to vote me on because I actually care about what I want and think I want to do. Just have it right. People the way human beings are, they're just going to vote for me because they just know me. And so I personally just said, no, five years is good enough. And also because we've actually ended up in a funny scenario where there's five of us and all of us have been on for a different amount of time. So I've been on for five years. Thomas has been on for four years. Craig's been on for three years. Pablo's been no Pablo's been on for three years. Craig's been on for two years and Emily's been on for one year. So we have exactly one, two, three, four, five years of experience. Like a rolling

council.

Yeah. And I'd honestly rather have it be like that.

That's kind of cool because you get one new person each year and they can kind of get integrated and used to it and everything. And then eventually they become the elder until their time is over.

Yeah. So I'm just personally making the choice that I personally stated five years was a good amount of time. I've hit five years with five people on the council. So I am going to step away. I was one of the inaugural members. So I've also served the longest at this point. And no, it's all good. I'm ready to take a break. Get that hour and a half every Monday back. Plus get to comment as myself. And I have to worry about people taking it too seriously.

Right.

And just get a bit of time and a little less stress.

Yeah. Couple of watch a few more films every week. Now you can have two more time for movies on

it. Yeah. But honestly, I just want to give someone else a chance, right? I think turnover is good. I don't think people who've been on the project the longest should be the people necessarily who keep, can you voted in? I think people who are newer to the project and other voices should get on and be heard and try to make sure the project stays fresh and has the forward momentum to keep going.

Yeah. I mean, I think a balanced mix is always best. You do want the people who've been there with the experience representing the history that a lot of people lack, but you also want the new ideas and some of the enthusiasm and maybe the different perspective on the world that those other people lack. So I like the fact that you have like one each year. That's kind of cool. If you can keep that momentum flowing, I guess if you just did one person every new year, it's just going to work that way.

And it was totally accidental. Like I re literally just realized this in April when I gave the, my final, when we gave our update at Pycon us and my final update, at least for now, unless I decide to come back to the strain council later. Yeah, it just happened to turn out that way, but it's a nice coincidence and it's a nice enough coincidence that I hopefully will kind of as a group continue that on and assuming people are continually happy with the other four, I don't want to say people should definitely vote the other four back in, but hopefully they're happy with how they're handling things.

Yeah. When do you think the first AI will become a steering council member? How far are we from trans humanist Python steering council? I'm going to guess never. Yeah, I don't think so either. I've been thinking about this with regards to Python. Cause one thing you mentioned earlier on in the show is like, we have to get all the blog posts updated, you know, which would be like obviously an impossible task, but let's just call it a very large task. Cause like all those extent resources on the web need to point to the new thing. And that's a very hard thing to do. And then I was thinking, well now with the trend, we're actually two steps away because you have to update all the sites and then you have to retrain all the models because they're going to still be pointing out the wrong information until they're trained again. That's kind of a bummer. So now we're getting further and further away from like being able to be up to date. And that got me thinking about this Python as a default language, which you're kind of, you know, you're saying it's so used, it's taught of course, other languages are still taught as well, but it's so entrenched that the tools that we have now are really good with it or about it or know it well, right? Like a lot of our models know Python really well. And like, what does that say for up and coming languages like Raku, for instance, like they probably don't know, for instance, Elixir, both chat GPT and BARD are pretty bad at Elixir. It's just, they're not very good at it. They're probably way better at Python. And so is this like kind of a rich gets richer situation as we move away from blog posts and Google searches to asking a GPT every single time, if they don't know these new, I mean, it's probably not as good at Rust as it is at C maybe. I don't know. What are your thoughts, Brett?

Yeah, I think that's a fair point, right? Like the Python community is spoiled to the hilt with a wealth of knowledge and content out there because it not only has become as popular as it has, but because it's being used for teaching, there's a lot of documentation out there oriented towards beginners and it just gets repeated in different ways to try to help reach beginners from different perspectives. And because Python's one of the lines we like to say in Python language is Python's the second best at everything because of that, it's not hard to find someone who decided to use Python for something and wrote something about it. So because we have that breadth, there's just a ton of knowledge out there. So yeah, it's going to be very hard if people rely on AI to do this sort of thing to get to do more. And let's be honest, having Python be the lingua franca of the AI community is also adding even more weight to that, right? Like if you look at ChatGPT and their plugin system, one of the plugins is a built -in Python interpreter, right? So they even have already gotten ChatGPT to the point where you can talk to ChatGPT and tell it to generate Python code and then be able to execute it right there. So we're already in a very blessed position of tons of content and being used by the people for the thing that's now taking the industry by storm and kind of becoming a massive thing that everyone kind of has to think about and learn about and do stuff with. So it's going to be hard. I'm going to fully admit it. Now, there will always be places where Python is not necessarily the best solution, right? You're not about to write the Linux kernel in Python, right? C is there, Rust is starting to eat C's lunch, I think, a bit in that kind of perspective in terms of really low level system coding. So that's, I think, going to be a place. But yeah, it's making it harder and harder for languages to kind of break out. And I would like to think that we've done a good enough job that you kind of also have to kind of stand out a bit because the general good language that covers a plethora of possibilities is Python already. So how do you differentiate yourself against Python and somehow come out as better perceivably or at least perceptually to other people? And it's just hard. Like, as I said, I'd like to think that we've done a great job and we'll continue to do a great job, but add that on top of the volume that we have now in terms of information out there and being taught to kids in high school and elementary school now around the world. It's hard. Like, I fully admit it and I will fully admit, like my position and all this is total luck. Like I've always said this, like success is a combination of luck, skill and risk taking. And I just happen to be at the right place at the right time and just happened to hitch my wagon to a project that happened to blow up shortly after I got involved. Because when I joined, no one knew what Python was. It was what the heck is that? Or is that that language where white space matters? And now look at where we are. So it still blows my mind personally. But yeah, I don't know. It's I feel kind of bad, but well, yeah, it sucks. Right. I'm Canadian, right? Like I do want people to have success. You want to apologize. Yeah, I want to apologize. But I have to admit, it is rather nice to be in this position of working on a language that found this level of success.

Really sorry for winning.

Exactly. I'm sorry. I'm sorry we've done well. Yeah, because I don't honestly none of us set out for getting to this level. We just all enjoyed the language and just enjoyed working with each other. And it just happened other people agreed and continue to agree until we got to the point where we ended the Python package index. Like I've always actually said the Python package index is actually a trailing indicator, not a leading indicator of Python's popularity. Right. Because people had to get to the point that they wanted to write all those packages. And then it got big enough that that started to attract people. And now we've gotten big enough that people are forced to use Python instead of choosing to use Python, which was also a really weird turning point. Like hearing people complain that they were being forced to use Python at PyCon for the first time. Jacob Kaplan Moss of Django pointed that out as like, wow, we've really made it. People are being told they have to use it, not because they want to use

it. Right. So the very first time I heard the word Python that wasn't referring to a snake but was returning to a programming language, I was in college. So let's put it at 03 -04, somewhere in that time frame. And someone told me I was in a computing class. I think we were doing we were writing C. I remember writing a blackjack server in C. So it had like networking TCP IP and then also had like the blackjack rules. It was really a fun project. I would love to write. I would love to have just a free time to just write that again today. But I was writing that in C and somebody was writing some. I don't think we had a choice what to write, but he was saying how much better Python was than C. And I didn't know. I didn't know any programming languages. I'm like, I don't know. This seems better than C++, because my first class was actually C++. And they were using that to teach like programming, not to teach C++. And then my next class was C. And it was just so much simpler and like straightforward, like, oh, this makes more sense. Anyways. And he's like, no, Python's where it's at, you know, you ever get one of those? And I was like, oh, OK, Python, why? And his reason, even back then, he said, well, Google uses it. You know, and I was like, oh, that's cool. He's like, yeah. So if you ever want to work at Google, learn Python. I'm like, well, maybe I will. Now, I never went and learned Python after that. But even way back then, like it had this because Google uses it. It just had that instant appeal.

Yeah, I know. I know some other people had that same view, but I actually have some ironic story to do with that. One of my alma maters, and I'm not going to call him out, was talking about changing the intro language. And they were proposing Python at the time. And that came up, but it was used as a negative. Oh, like, yeah, but they use this at Google. Like, if you have to be as good as a Googler to use this, then there's no way it's good enough. It's going to be approachable by students.

Oh, because like those are hardcore programmers. Yeah. And

so they ended up, I think, going with Java.

I wish what I would have done that day instead of picking up Python is I should have picked up some Google stock. You know, I should have been like, oh, there's 2003 buy a bunch of Google stock. Yeah. Would have been smart. Oh, well. Yeah. Hindsight

didn't

pick up either, but I did write that blackjack server and I should find that code. It's probably just the worst code ever. Yeah, but it was fun. That was a fun project.

I will say the very first project, I think I really wrote seriously on my own for fun. And when I really knew I loved programming was tic -tac -toe nice. And because it's a solvable game, I was able to just figure out the AI, but the rule that the computer had to play to in order to consistently win. If I screwed up, you

always start in the middle. Yep. Every time

you just got to do the right weights in the corn in all the cells, that's how I calculate. And so I did it and I spent six hours without stopping doing it and see, it was like, oh my God, this is amazing. I think I want to do this for a living.

Yeah, that's super cool. Did it have a little ASCII GUI or anything or how that actually, yeah,

fun. And it tied to the numeric keypad for choosing where you want to place it. So you just type the number and just on the keypad and just have it go in the right spot.

Have y 'all ever played the ultimate tic -tac -toe? No. No. Is that the last one? It'll change your life. If you like tic -tac -toe, it's one dimensional. For the better or for the worse? For the better. It's challenging. Oh, it's a 3D? Kind of. Is this Star

Trek tic -tac -toe? So

it actually takes what would typically be the nine squares you have for tic -tac -toe and each of those is a separate game. So, you know, embedded tic -tac -toe essentially. And so let's say the rule of thumb is to start in the middle, right? So you start in the middle cell, which has its own tic -tac -toe board, and you go in the middle of that one. Well, your player has to play in the middle too. So you follow it. So then if you go from middle and you go to the top right and you play, let's say, play a whole game in there. Yeah. You just kind of follow. You go to the square or to the game in which the person before you played. So as you move around within the individual board, you're moving around on the grand board. And so you're playing essentially, you know, nine games at once, which is one big game. I don't feel like that breaks the rules enough because wouldn't you still be able to win every time? Well, the problem is, is you've got to follow. So you can't just be like, okay, well, I want to play here to get back to that. Let's say you're about to win in the top right quadrant. I would have to play so that you go there to play, you know? So you're blocked by my ability to, but you followed me there. You always play after me. So I could just keep playing the top right corner and you'd have to, uh, not necessarily. Let's say, well, yeah. I mean, you can keep playing there, but then I'm also there too. When I see your move and I can block you easier, you know? So if I see you're about to win, it's no different. You have to be more strategic. It's like 3d chess in a way. It's ultimate tic -tac -toe. I think we just had to play after the show, Jared.

Yeah. Yeah. It's really intense. I play with my son because we've been like, you know, he's been, you know, very young playing tic -tac -toe with me. Now he wins every time on a single board. And now on ultimate, it's like, it's nine games at once. Very challenging. And it takes a long time to play. Like it's a good half hour. So versus like minutes for the single game. Gotcha. So it's a different experience. Yeah. I'll have to check that out the way I'm conceptualizing it. I don't think that it would be any actually more complicated. I'm obviously missing some sort of rule that makes it that way. What makes it more complicated is that you have the blocking, you know? So you still have the freedom to move around, but only if I move there or if you move there. So if after your play, you go to the bottom left and, you know, there's a strategy there. I have to play there with you, you know, and then I can move to try to take my strategy elsewhere. It's all about strategy and like the ease of blocking. What happens if you win an individual square? Like, so that's a good point. We've recently done this. I don't know all the full rules totally, but I think you, you know, if you're a circle, you circle it. If you're an X, you exit. And so then if you push somebody into that place, my son calls it free play and I don't know if he's got these rules. He introduced me to this game. I didn't discover this game that your son made up. Okay. So is this a real game? It's a true game though. It is a true game. I promise you. Okay. But he says it's free play, which does not make sense to be rules wise. So basically if I take you, let's say I've won the bottom left quadrant and I take us back there. Or like I play, you know, in a different game in the bottom left corner in a different quadrant, right? You cannot go there because I've won that board, right? If I try to take you there, you can't go there. So I think you can play anywhere else based on his interpretation of free play, but I don't believe that's how I would design the role. So I want to investigate further. So question mark on that one. I don't know. Okay. I do know you can win boards and something happens where you skip it. Somebody out there is listening to this and they're like, they're an ultimate tic tac toe grand champion. And they're like, you fools, you don't even understand the rule of ultimate tic tac toe. You're wasting my time with this guesstimating. Well, Brett, once you are off the steering council, maybe you could code up, you know, one more tic tac toe game, go deeper, go 3d on it. That's right. You got free time

now.

I think I'm gonna have to wait until the show notes come out to find the link to the official rules to understand how I'm supposed to code that up.

Yeah, fair enough. Well, then they'll be out there.

I could. Yeah. And I'll use textual to do it as a two E and yeah. Still be old school with new stuff and yeah, ultimate

tic tac toe is on, on Wikipedia. So link it up. We'll, we'll read the rules and we'll explain them to you in the comments. We're like, Adam, here's how it works. Brett, what do you think

of textual? Have you used it all? I haven't had need yet, but, uh, Will's a great guy and I think what he's doing is really cool and how he's pulled that off is crazy. So I think it's a really great resource for the Python community in general and obviously anyone who has to do it to eat these days. And I think it's pretty neat and a nice way to get a quick gooey going because Lord knows trying to do a cross platform gooey is not easy.

Right. Yeah. Somewhat ironically, when we had him on the show, I mean, I was, I'm super impressed with what he's built over there as well. Like his main sticking point, I think at this point was like distribution, you know? And, uh, he's like, yeah, I'm not sure if Python's the best choice for that particular problem, but everything else, it's amazing. I'm like, yeah.

So touch you on that point, right? Like this is Brett's like, yeah, not on a soapbox, but wanting to point out that part of the reason this is hard is because of Python's popularity and because the Python's use is the glue language of the internet, right? Like if the world was just pure Python code and people just use Python code with Python itself, none of this complication would be there, right? Like, like pulling out the back of my day phrasing, right? When I first learned Python, you didn't need any of this, right? Like you downloaded zip files, unzipped it, put it in the directory with your own code and you just went with it. But when people started leaning into CPython C API and wanted to like wrap, like the canonical example is always like libPNG or something, right? And get that shipped to people without forcing them to have to have a compiler installed, which was always a problem for Windows users, right? We had to come up with some way to have you be able to download the right thing for the right version of the interpreter and all that stuff and have it all just work. And we did, and those are called wheels. The trick is, is those wheels are tied to the version of Python that you're running and the interpreter you're running and how it was compiled and downloading for the right OS for the right CPU architecture and all this stuff. And so there's a lot more work to it to download and put it on your machine for it to work and have it work going forward, because that's the other thing, right? Like Python's evolving language, people will install versions of Python. And if you just dumped it into the directory with your code and suddenly upgraded your version of Python or downgraded or whatever, moved to a different machine even, right? This is a generic problem with dynamic languages. Suddenly it could break because once again, it was compiled for a different thing and made it to work for a different thing, right? You can't just copy that code over, right? Like if you were going from your old X64 Mac to your new Apple Silicon Mac, you couldn't just bring your hard drive over because all those binaries are now wrong, ignoring Rosetta and all that stuff, right? So that's where this whole need for virtual environments came up was a way to isolate it and make sure that like, hey, virtual environments are designed to be tossed. They're not designed to be an actual like artifact that you do anything with is designed to help you install something. And if you need to get rid of it and do a reinstall, they're designed to be lightweight, right? As I said, they're literally just direct, like three directories and threesome links, like whatever. You can delete them, recreate them, not a big deal. But because of that, I mean, because of the desire to install the fastest thing and the right thing, you need a way to stick it in the right spot so you don't shoot yourself in the foot. Once again, moving machines and only a different virtual Python, your OS installing a different version of Python for you, right? Because you did an upgrade in place, right? And suddenly, oh, you were relying on the system Python that used to be 310 and now it's 311, that kind of thing. So we had a way to kind of isolate stuff. And that's where this complication came in. So if C and Rust and Fortran and all that other wrapped code for Python went away, the problem would completely go away overnight. We'd just say, yeah, just download your Python code, put it in the same directory and it'd be done. But once again, this is the curse of the popularity thing, right? Like everyone uses Python for everything and they wrap the world and wrap some of the weirdest things out there. And so everyone loves that they have this stuff, but then they hate the overhead of having to maintain it. But that's just part of the cost is there is no C package manager we can rely on. Everyone does it their own way and not everyone even has a compiler set up or the tool chain they need to compile that thing, right? Like not everyone's going to have C make, not everyone's going to have GNU make versus BSD make even, right? Like even that's a difference. So it's one of these things where we can't have you just download and build it. We got to make it precompiled. And then if you have that, got to make sure right version, right thing for that scenario and that it doesn't suddenly go wonky if you change things around on your system. So we have to keep it isolated. So at least it's still the right thing in that scenario. And yeah, this is why packaging in Python is hard and why you sometimes hear people complain about why is packaging so hard in Python? Why can't it be simpler? It's like, well, it would be totally simple if we all just wrote Python code and no one ever brought C or Rust or Fortran or anything else over into the Python community. But because we're that glue language, people do that perpetually and it just complicates things.

Here's an idea. What if you had a brand new programming language that combines the usability of Python with the performance of C, unlocking unparalleled programmability of AI hardware and extensibility of AI models? Of course, you know.

Are you talking about a certain language that uses an emoji for its file extension? Do they? So I'm talking about Mojo. Do they use an emoji? It's optional. But yeah, Mojo, you can use the fire emoji as the file extension.

I kind of love that, honestly.

I guess because Mojo is fire if you're if you're hip to that lingo these days. Mojo means fire or it's just on fire. I don't know. It just is fire. Don't the kids just say it's fire? Kids have moved on from saying it's lit to saying it's fire. Things aren't lit anymore. They're just like, that's fire.

I've heard people say that's fire.

You two tell me you're the parents in this call. What do the kids say these days?

I don't let my kids use emoji. I'm just kidding. I don't know. I'm intentionally dense sometimes. So Mojo is a new thing, sort of modular dot com. This is coming from Chris Latner and friends recently announced made big a splash. It's, you know, it's Python compatible as a goal and but brand new in certain ways. I don't know much about it. What do you know about it, Brett?

Uh, I only know what I've read on their website. And, uh, I did listen to Chris's interview with Lex Fridman and all the Mojo bits, at least. So their goal from my understanding is to be a super set of Python. So fully backwards compatible with Python itself. Plus their additions to make, uh, additions to the language that allow you to design and write things that are as performant as possible. So they add, for instance, a struct that I think is more like a C struct in a way, very hard to find. You can't add extra things to it after you've defined it. It's the orders specified, all that stuff they have. I think, I can't remember what the call it FN, I think, instead of def for defined functions where you can type the arguments and everything, and it's guaranteed to be that by the compiler. Like, cause Python's type hints or hints, like they're kind of documentation that people statically analyze to make sure that the documentation is accurate, but technically you can't rely on it being true necessarily. Well, I think Mojo's compiler does that, or it's supposed to do that. Otherwise, I don't know, honestly. I haven't talked to Chris or anyone from modular about this. They've talked to Guido, I think once they just chatted about and gave them the heads up that this was coming, I think, but like they haven't come to the core dev team and it introduced themselves or anything. I know there's nothing publicly available to just a randomly download. I think it'd be on an invite list to get to play with it through a Jupiter notebook. So good luck to them. I will say that the history, uh, the world of software is riddled with the dead bodies of people trying to re -implement Python. I hope they pull it off because their goals are quite audacious and if they pulled it off, that'd be amazing because then it'd be even more Python software out there and then stuff that makes it even faster. And it'd be fantastic. But I don't know where they're at because as I said, they haven't really publicly released anything yet. If you read the docs, it reads a lot of, this is what we hope to do and plan to do, not what we have done. So I'm just waiting to see where they're done ends up being

right.

Hopefully it'd be nice.

Yeah, I think a superset is smart. I think that's a, a play out of TypeScript playbook. And I think that was one of the reasons why TypeScript was and Swift as Swift as well. Good call, which of course, Chris designed Swift, did he not? So he's done this before. He seems like a very talented engineer. And I think, you know, if anybody can do it, maybe he's the one, obviously he's not doing it alone, but it's interesting to say the least. And like you said, very early days and lots of audacious goals. So I'm always cheering for anybody with audacious goals. It's not like it's going to obviate Python or something, even if they're successful, obviously it's a super entrenched and it's the most popular thing there is. Like you guys just assume everyone's using it. That's how deep it's in there. I mean, Google uses it, right? I heard that one time Google uses it.

And Instagram, don't forget about Instagram.

Okay. Never count out Instagram. Their docs have some nice things to say about Python that they say, we believe that Python is a beautiful language. It says it's designed with simple and composable abstractions. It is skews needless punctuation that is redundant in practice with indentation and is built with powerful in parentheses, dynamic meta -programming features, all of which provide a runway for us to extend the language to what we need at modular. We hope that the people in the Python ecosystem see our direction from Mojo as taking Python ahead to the next level, completing it instead of competing with it.

I mean, listening to that interview and reading those docs, I don't think, I don't view this as adversarial or confrontational at all. I think they're coming from a position of mutual respect. I think of just like, yeah, Python successful. It's done well for itself for good reason. Hopefully they think it's good reasons. And we just think there's some things we can tack on to the language to give you some performance boosts in certain scenarios that people, especially in AI, really want right now. And bring Python along for the ride so that when you need that, you can. But when you don't, you don't. And so, yeah, it'd be great. As I said, I wish them luck. I hope they're successful because, as I said, it sounds like they want to see Python continue to be successful. They just want to expand it a bit to make it even more successful in other places. Right. Because historically, if you run into a performance problem, you jump out of Python, write it and see your Rust and then you do that extension module. But I think Mojo is trying to present yourself like, yeah, you don't even have to jump out of Python, just write some extra Rust code over here. And it just integrates directly into the system. And it's just a part of the code base. There's no massive language jump to this crazy curly brace world. It's just right there. And just a couple of different keywords, but nothing exotic. And I think that's how they're trying to position it.

It's like you just switch your file extension to a fire emoji and now you've got extra superpowers, you know. That's pretty cool, actually.

As I said, the Amy for Super set, it's technically supposed to be fully box compatible. So, yeah, technically, you just make any any Python project is a Mojo project by definition for what they're aiming for. As I just don't know if they're long enough to have proven they've been able to pull that off. Hope they do. Right.

So it's like if you want to do Python plus you would use Mojo to get there.

It's one way. There are a couple other projects out there. There's Cython, which used to have its own domain specific extension to Python syntax to let you define more or less like C types and then have that compiled down to the C API directly. They've subsequently picked up the type hints the Python has so that you don't have to use their language subset. But it's it's still different, has slightly different rules and all that stuff, but they do their best to be fully compatible. And then there's another project called MyPyC that comes out of the MyPy project, the type checker, where they try to take type into Python code and compile that straight to C code. But once again, they have limitations because they can only they only support certain constructs and certain types and all that stuff. So it's not fully generic like Mojo is kind of aiming for of we'll just take any Python code. Hopefully that base performance will be equivalent. I don't think they're being claiming Python's going to be personally faster, just that it'll be the same for us. But if you do Mojo, the Mojo bits will be way faster, right? Like I think three thousand five hundred times faster kind of level claims, really, really faster. And so that's the interesting perspective they're coming from is like you don't have to code within a restriction because we're a superset. You just take your Python code. It won't be any worse. But if you toss in some Mojo stuff in there, that Mojo bit will be way faster. So I think they're trying to go like, oh, yeah, write your Python code, profile it, any of the slow points, rewrite that Mojo right then and there and just use it and you'll just be faster. Be awesome.

Yeah. All right. Anything else? I know we've mentioned rust. We haven't brought it up too much. And I'm curious about Python rust. I know, Brett, that you've been doing some rust yourself. What's the story with rust in the Python world?

Yeah, I will say I'm a rust fan. I actually created the Python launcher for Unix, which for those of you who are Python developers on Windows and are used to the PY command, so the Python launcher on Windows, I decided to kind of reimplement it in Rust for Unix as my Rust learner project. I think it's great. It's honestly, if Python doesn't fit the bill, I see if Rust fits the bill. That's kind of my decision tree now for languages. Yeah, there's actually pretty good synergy between the two communities. I think kind of the approaches historically around trying to be open and welcoming and all that stuff kind of tied the two together as being friendly towards each other very early on. Plus Rust not kind of targeting the same aspects of the world in terms of Python because Rust is not a scripting language or a dynamic language. It's very much a complementary. Yeah, it's more systems oriented. So yeah, it's a complementary language to Python, I think. Yeah, there's good support. So there's a project called Py03 that makes it fairly easy to take a Rust project and expose it to Python. There's another project called Maturin that is a build backend that lets you take a Rust project that you use with Py03 to compile it to build those wheels I mentioned earlier to get those precompiled binaries. So that's easy to just download and install for Python on your machine. There is a linter called Rough by Charlie Marsh, R -U -F -F, where he decided to write a linter that more or less did what flake8 does, if you haven't known that linter for Python, except he didn't Rust and it's blazingly fast. Like it's one of those, did it actually run? It exited with no errors and it already said it's finished. Like, is there a bug?

So fast, I'm not sure if it ran.

It's like when I write Python code and it passes all the tests and everything works the first time, it's like, I got to add a bug here to make sure that this actually happened. Same thing here. Right. And it's really, really fast. And it's done so well, actually, that Charlie got VC funding. So he started a company called Astral, A -S -T -R -A -L, astral .sh, to hopefully do more of that. So it looks like the Python community might start be leaning towards what the TypeScript and JavaScript community have done of, you know, for this stuff where someone can sync the time upfront into the tooling. And thus it is an ED into my development time. This uses the fastest language we can to get that tool, those tools as fast as they can be. While my time, while I'm doing my development can be in the language I'm most productive in. Right. So let's write the tools once in the really fast, fast, low level systems language that's going to take someone else a lot of time. Let them pay the time penalty to get that working so I can run as quickly as possible. But then I get to code in the language that I'm most productive in. And in this case, I would say Python. So, yeah, there's definitely some synergy there. We actually use Toml Parsi on the recommendation of the Rust community. When we decided to standardize the configuration files for packaging, there were a couple options and we considered Toml and we went and talked to the Rust community about their use of cargo .toml. Right.

And they like it.

Yeah, they liked it. So we that's partially why we went with it for pyproject .toml to the point, actually, that Purdue when someone who's now a core dev and very active in the Python packaging committee is actually now the co -maintainer of the toml spec.

Is the toml spec under development?

Not anymore. I think it's pretty much at stable after they added datetimes. I think they more or less hit 1 .0 and just kind of said, nope, we're good. We're done. I don't think it's changing very much, but.

Check out the astral website. There's definitely some cool testimonials for rough here. Nick Schrock, who was one of the guys who started GraphQL called it a game changer. And he's like, why? Primarily because it's nearly a thousand times faster, literally not a typo. So that aligns with what you're talking about there. We're just like so fast that just like, why not? I think it's, it's cool that sometimes you can get, I think I've used the word entrenched too many times in the show, but you can kind of get like stuck in your own world and think like everything has to be in Python, you know, like Python, this Python, that. And it's like, that's kind of goes against the best tool for the job principle, right? Because it's a general purpose tool, but that doesn't mean it's necessarily the best for every job. And so if you have a job that you need done and rust is way better at it a thousand times in terms of like just execution speed on this exact same task. I think it'd be foolish not to look over there and say, Hey, what if we just like use both these tools together and had a better life?

I think the key word there is tool, right? Just because a tool for your ecosystem was written in something or use something that you wouldn't necessarily want to use from that ecosystem doesn't mean that your choice of that ecosystem is wrong, right? As I said, like Charlie choosing to take the time and effort to write a linter for Python and rest for speed doesn't mean your choice of Python for your development needs was wrong. It just means Charlie was willing to sink in the extra hours it takes to implement the same thing from Python, just so that you would benefit with a shorter time to run that tool. And so I think it is very much a choose the right tool for the job. And part of that's choosing the right tool to write that tool. It's a bit meta here, but I think as tool creators, it behooves you to do what works best for you. Now, if Python is the most productive thing for you, go for it. But if something else works better and even gives you extra wins, you kind of want to go for it because the people who use your tool then get those benefits. And it's a per project thing, right? So I'm not at all saying that no one should use Python for tools. It's really going to depend on you. It's just Charlie liked Rust and found a thing for it and it worked out great. And same thing it seems in the TypeScript and JavaScript communities where it's worth sinking that time and effort because I'm not going to stand here and argue that Rust lets you code faster than you can. But if it's one of these things where you expect it to be around for years and years and you have the time and the knowledge to do it, it might make sense to consider using Rust to do this sort of thing.

Absolutely. And if it's the kind of tool that you run multiple times a day, all day long, you know, having a thousand times faster is it would be foolish to not want that. Yeah. As long as the tradeouts on their side weren't significant.

Exactly. Like the Python launcher for Unix, I wrote that in Rust because I didn't want to code in C. But I also wanted to be as fast as possible because it's what you use to launch Python and no one wants Python to launch any slower than it does. So I just said, all right, I'm going to bite the bullet. I'm going to learn Rust and I will just maintain it in Rust. And I don't regret that decision at all because the performance is fantastic. But I will admit it takes a bit more effort for me because I try to keep up with Rust, but I'm not exactly ingrained in the community like I am with Python and not just living a Rust life every day. So it takes a bit more effort. But my pain is my users gain because they get that performance perk while I just have to put in a bit more effort to know how to do it. It just worked out for me on this. But like all my other tooling is still in Python because it's not performance sensitive. They don't need to worry about it. So what's the point? We're not fixing Felix, you know,

can't walk around with a gold hammer, just whacking stuff, fixing things. No, not yet. Haven't found that hammer yet. Gold hammer, nickname Python or something like that. No, that's not how it works. What about our Python? You know, we have C Python. Could there be a future where there's a Python implementation in Rust or is it just too much groundwork to get that done?

It already exists. It's called Rust Python. Oh, really?

Some people decided to reimplement the C Python interpreter in Rust. They actually kept even the bytecode. I don't know the current status of it. They haven't done a blog post in a while. They did get PIP self -hosting on it. One of the big things initially was they can get it compiled to WebAssembly and do it that way. I've personally, subsequently gotten C Python compiling to WASI specifically for WebAssembly. And the PyDie project already exists and they got Python compiled to WebAssembly for the browser. So that's definitely at least already there even from the C code. But yeah, no, someone's already done that project.

That was my favorite kind of project. You know, I have a good idea and it already exists in the world. I love that.

It's done. No work. Easy. Free win.

Yeah, no time either. I don't have to even wait for it. Just like it's already out there, man. Somebody else had that idea a long time ago and they did it. So kudos on them. All right, Adam, anything else you want to talk about your Canadian barbecue experience? I got a few minutes, but we can also just say goodbye. Well, mainly just to throw a nod at Brett because he took us out. So we sit at the top of the show. We met Brett for the first time. We went to Canada, to Vancouver, Canada, which is where Brett's from. He went there for Open Source Summit as part of Linux Foundation's big conference there. Many things happening in addition to the Open Source Summit. We got to meet Brett. He wasn't even at the conference. We're just like, hey, Brett, I know you live here. You want to get together. And so Brett took us out to what was the barbecue place, Brett? It was your spot.

Whiskey Six on Renfrew Street in East Vancouver.

Whiskey Six. So he came and picked us up in his Tesla. We had a drink in the bar quickly. And then we went to this Canadian barbecue place, had some bourbon, I think, bourbon and whiskey potentially, I don't know, just maybe just bourbon, some good barbecue. And that was good stuff. I'm from Texas. So, you know, barbecue is a thing around here. Very, very popular to be around here. And there's lots of good barbecue. So to impress somebody who's impressed by Texas barbecue is a good thing. And so that's why I wanted to mention it because it was really, really good barbecue.

Kudos to my wife, Andrea. She's the foodie of the house and loves staying on top of all the restaurants. So when she's like, where do I take them? And it's like, oh, you just take them to Whiskey Six. Oh, okay.

She's smart. And you had to get reservations. It's like a one man show, small local town kind of spot. It doesn't seem like a place you would have to get reservations, but you do. But it's tiny. So there's one guy he owns and operates and he's the bartender. He's obviously the cook. He's doing the barbecue and all day. He's a waiter. He's probably the drink maker. I was going to say the pool boy. What's it called? The guy who take the bus boy. He's the bus boy, the bull, the pool boy, he's a pool boy. It's a different podcast, dude. So that was cool. I don't think I've ever seen a place like that just run entirely by one person. You know, they're just kind of cool. It was different too. I tried to ask him about like his rub and he was just like not having it. There was zero information coming from that guy. He was like, I ain't giving

away my secret.

Hey, he's busy, man. He's got to run the whole place. Well, that too. He was busy, but it was also not going to disclose any, any detail about his process. Very protective. Yeah. Well, I mean, you don't go and ask somebody their secret sauce, you know, just rude. Well, you know, that's not the truth here in Texas though. I mean the, the Texas barbecue folks, it's like a community similar to the way software is for us. Like they get together, they share, Oh, what's your method here? And they're sharing constantly. Like there's no secrets really. I mean, there's obviously some secrets because you know, there wouldn't be any if there wasn't any, but they're not trying to, they're not trying to keep the secrets. You know, it's like time and temperature is the primary thing. You can cook it on a trigger, which is wood pellets, or you can cook it with legit post Oak, which is legitimate wood, you know, and tending a fire. But it's really just time and temperature seasons, you know, seasonings, rubs, whatever.

That's what you think.

Well, I mean, that's what I hear. This is why you're going to have on backstage and you're gonna have your barbecue episode. That's right. We do have to do the Craig. Well, you

know, Craig's got to come on, share his thing and he'll probably agree. I mean, it's mainly time and temperature at least here. There's almost no secrets with Witcher processes. If you had a secret though, and some guy came into your restaurant, asked me what your secret is, you might tell him, yeah, I'm not going to tell you my secret is. Well, I was just trying to, you know, BS the guy and he wasn't, he wasn't having any of it. He was like, nah, no, he wasn't. Sorry. We're not going to talk about my rubs at all. Just, just enjoy. Did you get your bourbon? Do you like it? Okay, good. Drink that.

But

there you go. Yeah, it was a good experience though. It was nice meeting Brett. Can't cannot believe how tall he is. And then obviously the barbecue is, was stellar. So tall, not quite as tall as some people who joined clubs, but. And then we got that ice cream afterwards. Well, that was the ice cream. Oh yeah.

Oh, we went to Ernest ice cream. One of our favorite ice cream drinks. Y 'all got Sundays,

right? So if you're, if you're ever in Vancouver, meet up with Brett and Andrea, or just go to whiskey seven, whiskey, six, six, six, six. You can't have seven ice cream

at Ernest ice cream. Although, well,

I'm actually thinking about making whiskey seven after I talked to him, I was trying to take his secrets. Yeah, you were, yeah. You're like the same guy. I'm going next door. One more ingredient. I'm gonna have two people work there. Not just one. Get your food twice as fast.

Yeah. We were very lucky to have that because there's not a ton of barbecue places in town, which is probably why he was a little protective. We are very lucky to be spoiled for ice cream though. So

he's like, you cannot take my recipe, man. I am killing it here. Okay. I've got the market cornered. He's got a monopoly on good barbecue there. So can't, can't give that

up. Yeah.

I can definitely take it to multiple ice cream spots. Next thing you come, there's lots of great ice cream spots there.

Well, when you come here to Texas, I'll take to you. I'll take you guys, Jared. I'll take any day. They still let you in the States. Brett, they still let you come.

Yup. Uh, I actually have, well, he's a dope citizen, right? Aren't

you dope citizen? Not

anymore. No, no. Remember he turned it over. I remember that's right. You gave it up. You wanted to be fully Canadian. You didn't want to start a line. I was

born here. So the American was bonus. I just didn't need it.

It was a bonus. Here's a bonus. You get to pay more taxes. Congratulations. You get to pay the taxes of two countries.

You'd be surprised at how complicated forms get when you have two citizenships on visa applications and stuff. When you travel abroad, it's just, it was a massive hassle. So it was just simplified my life and just like, I'm good. I'm living here. I'm married to a Canadian. I just don't need it, but it was a lot of fun. But yeah, no. I actually have a nexus pass, which is really fantastic for getting across down to the U S so getting down is not that not a hassle. It's more time and carbon footprint at this point.

Well, if you find yourself in the Austin, Texas area for whatever reason, I'm super close. So I'll take you out.

Oh, I know. Don't worry. Next time I'm in Austin, Adam's getting a message on Slack about it. So, oh man, a day before let's go. Hey, Anaconda is actually a local company. They're actually based in Austin, Texas. Is that right? Peter Wang,

Peter Wang,

Anaconda. He's been on practically. I never heard of it. Smart guy. He's been on practically a couple of times. Is that right? A different. Okay. Well, I heard of that Anaconda. So many Anacondas out there. That's true. The ones that will get you and the ones that want to get you as a customer. The ones that don't want none. Brett, thanks for hanging out with us, man. It's fun.

Hey, anytime. Great talking to you both.

It was fun, Brett. Bye friends. Bye friends. Well, where are your Pippin stall anxiety levels? Is PipEx the answer I've been looking for? Does Brett's take on Mojo? Jive with what you're thinking? Let us know in the comments. There's a link in your show notes. Seriously. We want to hear from you. And if you like the smell of what we're cooking up here with Change Logging Friends, tell your friends about the show. There's plenty to go around. Coming up next, it's our friend Kelsey Hightower. Maybe you've heard of him? We're having some fun now. Thanks once again to our partners, Fastly .com, Fly .io, and TypeSense .org. And of course, to Breakmaster Cylinder for helping us loop the freshest beats in the biz. All right, we're done for now, but let's talk again next week.