The Changelog: Software Development, Open Source - There's a whole PEP about that (Friends)

Episode Date: June 23, 2023

Brett Cannon (our unofficial ambassador to the Python community) is here to help alleviate our pip install anxiety. Along the way, we ask him about Python 4, removing the GIL, what he thinks about Chris Lattner's Mojo project, Rust in the Python world & way more (of course).

Welcome to ChangeLogin 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. Okay, 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. 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, I guess, 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? Like, 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, and cut the snark down a bit and 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 six foot six inches in u.s customary that is uh that's pretty tall six six yeah funny enough in a friend of mine thomas wuters is 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 club in the Netherlands. And to be a member, you have to actually be 200 centimeters to be considered tall in the Netherlands. Wow, that is tall. I'm just above.

I'm at the upper altitudes, above average, at least there. So it's all cultural relative where you actually are. Yeah. 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 and corners i will say flying is not pleasant and finding a car that i fit in is a real pain uh actually you drive a tesla though well yes but that's because i found a car that i barely fit in that

i do fit in that but for instance when we're 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. Like, 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? Oh, 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 Brett for the first time a couple 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 Yu as well, was Firas Aboukadej from our JS Party podcast. He is also tall. Very tall. And it was a surprise because he doesn't put, you know, 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-Loo, 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. 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 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, and they will be excited about it. Mm-hmm. Well, it's a 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. Right. And whoever wins, it's like, well, okay, fine. You 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. Just the opportunity to win something in conversation, 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 Reier on Changelog and Friends, episode four. Matt Depends, Reier on Changelog and Friends, episode 4. 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 fancy LLM AI things are Python things, which as a non-Python regular user, it drags me back into the ecosystem 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 RubyGems 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 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 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 what it's called? Steering committee? Steering council, but yes. Steering council. What's the difference between a council and a committee? You just pick which one.

I think so. Yeah. And so you're our ambassador to Python, pretty much. Isn't that right, Adam? 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 if we're going to diss 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 tonight. I was like, listen to this and blog about it. Yeah, you said, have you listened to this yet? And you both joked, 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 read this episode. I said, why? You said, oh, I said some things, basically. basically i said some things it's like a diss track i think adam yeah basically said you might want to listen that jared said some things about python in there it's like why what do you say just go have a listen and then i read the transcripts i'm like oh and then i went and listened to so i can make sure i heard the tone appropriately. I'm like, oh, okay. And then that's when I messaged you two and said, okay, you asked me to listen to this.

Where do you want your reply? 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 felt 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 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 pointed 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 marketing, in the broad sense of the term, 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, okay, 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. For Mac OS? Yep, they took it out. Yeah, I think Ventura was the... Why'd they do that? They actually took out all the languages, I think. Dead language, dying language. They're done with it.y's still there though oh which python python not found which ruby user bin ruby oh user bin that's not homebrew the gauntlet's thrown i was gonna 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 they 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 seriously that day it was it was some odd thing i don't know what they can 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 okay so maybe i go to python.org i know what i did because mine is opt homebrew bin python 3 so i know what i did was like install Python. That's what I do personally. Where do people who don't know what to do go?

Do they go to python.org? Do they Google how to install Python? What do you think people are finding? Where would I get this virtual env information from? Is it on the Python website or is it 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 VS Code.

And one of the things we run into 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, not 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 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 So we should just teach you this upfront. 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 upfront.

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 thus Ubuntu. So a virtual environment is kind of what it sounds like. It's an environment that's virtual, which I know, duh. But it basically creates a directory, has 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 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, okay, I should install into the virtual environment, not into like where the physical copy is because on Unix, they're all symlinks. And that's basically it. It's not a complicated mechanism. If you look in the code, it literally just goes, okay, 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. 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 subdirector 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 that 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 VEMV or V-E-N-V. And Debian does not ship it by default. Now, their policy on Debian is you do not package multiple apps together. Because VEMV has a command line interface, because usually the way you do this is you go like Python dash M, VEMV, and then a name of some subdirectory like dot V-E-N-V 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, Dibby considers it 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-vev install.

And you also don't get pip, so that's a separate python 3 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 VM thing that you got to use to be protected

from botching your system. Yeah. This is addressed in PEP 8 tells us why we can't do this or something. Good one, Jared. 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 word they choose.

It's actually a committee council. They are a committee around a council. Yeah. And then another committee inside that. There you go. Circles and circles. 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 3-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 3-full when you're on Debian,

which unfortunately trickles directly into Ubuntu, and that's where a lot of Linux people get tripped up. But other places like Fedora and stuff do the thing you'd expect where if you just install Python 3, it's 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 to backtrack. So I said which python yeah not which python 3 so i did install python 3 via homebrew then i also have a version of my user um my user bin folder that's python 3 i didn't say which python 3 i said which python oh so you do have a user bin python yes i'm correcting that it is installed by default okay 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 3 in there well let, let me make sure I'm 100% true. I'm not going to have it. You're right. Mm-hmm. So it's there. Yeah. So that's kind of the rub to some degree. If you're not steeped in Python daily, you forget to add the 3. And then you're searching for just Python.

That sounds silly, but I'm with him. Because even with Homebrew, I had to remember, oh, it's Python 3. It's not the word Python. Now, that's a Homebrew thing, right? Or is that the way you guys do it now what python 3 with no python no like the python community if I type python it doesn't show up I have to type python 3 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 2 to 3 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 um 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 i feel 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 3 only earlier than most they decided yeah and maybe we should re relink or rebind or whatever term you want to use point python as a command sim link it to python three and have that be what python points up okay and the problem was 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 a python 2 it led to a lot of confusion so we wrote a whole about it and just tried to give guidance to Linux distros. Like, okay, you're the ones who are kind of doing this because people don't get it from an installer typically on Linux. They usually just have the system install, which has obviously changed that.

But at that point, it hadn't happened. So we said like, okay, here's what you should do. You should have Python 3. You should only do it to Python, probably way in the future when there's zero potential confusion. Wow, what a headache. So this whole Python 2 to Python 3 transition, how long do you think it took? Obviously, there's no hard edges from Python 3 to Python 2, like, let's say like 80% 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 3.0 came out i believe december of 2008 okay 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 2018, I would say, seems fair for roughly that. I think it was maybe 2015, 16 when we maybe hit 50%. 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 Perl 6 was a thing? Because like, isn't that... Isn't that like the only, even more notorious version problem? No, although I did watch and I did feel bad for them that they were having to go through 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 not a wholesale rethink like Perl 6 seemed to feel like from the outside. I'm not a Perl 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. We were able to just take the CPython virtual machine

from Python 2 to Python 3 and just change it to upgrade it. We didn't have to do a wholesale rewrite. So we didn't end up with Perl 6s. Pug was 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 it. I think Perl 6 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 Anaconda. 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 conda. Well, I think at this point, almost every word is a tool. Raku. Raku is a member of the Perl family of languages, formerly known as Perl 6. It was renamed in October 2019. There you go.

And introduces elements of many modern and historical languages. Not compatible with Perl. Yeah, so this is the design process for Raku. Well, yeah, in the year 2000. So Perl 6 renamed Raku. And if you're going to depart that much from your other version, might as well just give it a new name and start fresh. It's like calling it Mojo.

Maybe you just call it Mojo. Is that much changed in your opinion? Is that backwards compatible change? How would you describe that change? Is it drastic in terms of like... Pearl Six? Yeah. I'm with Brett.

I'm not a Pearlmonger, as they call themselves. Is that what they call themselves? They do, Pearlmongers. Cool. I think so. They used to, at least. Confirm that too, Jared. Yeah, let me confirm that.

I'm just second guessing myself left and right here, but I think I'm correct on both accounts. Pearlmongers. The reason I know that is because there's a local Pearlmongers group in Omaha. Yeah, Pearlmongers. It's an international association of user groups of the Pearl programming language. So my history does serve well, but I'm no Pearlmonger, so I don't know. I just like read the news and followed along. I remember a lot of hemming and hawing about Pearl 6 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 do strings right now. It's like, everything's different. It's a new version of Perl. And not called Perl anymore. Is it? I don't know.

At least that version. Were you there then for this transition from Python 2 to Python 3? You were a part of the steering committee? What was your role in the community at that point? That 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 co-author on PEP 3100 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 Snired library that was not going to make it to Python 3. That'd be fun. I was around and actively involved, and I will say I am part of

the reason Python 3 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 much about Python 2. I know that I now have a 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 a 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, yeah, this makes total sense. I think it's solid. Well, to be clear, we weren't dissing on Python itself. We were dissing on the pip install process. It's just the pip thing.

They're very specific because you don't know where it's going to end up, if it's going to botch something, and how it works. And it's just because you're unfamiliar. You don't do it daily. It is. It's mostly that. Well, there's a couple aspects to that. So it is it's mostly that well there's a couple 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 uh 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 pipx, and you can install this with apt-get or DNF or whatever, homebrew, whatever you want, right? It's designed to be packaged independently on its own. You can do a pipx 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 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 pipx can always do it the other nice thing it has is it has a pipx run command like you could do pipx run whisper i think jared you said the tool was that got you down this rabbit hole what that does is actually will 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 restalls it again 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, pipx 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 pipx run with any kind of tool i need to use from in the python community because it's just fast and easy and now 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 right you know with clis there's no api to tell you you're broke it just might have some weird bug so that's how i typically do it very Very cool. Yeah, we'll link up this pipx. This looks like exactly what I need to just not have any more anxieties,

just brew install pipx 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, humble brag, 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, A, it blows my mind to this day still, but also just you, 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 because 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-mpip 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? Because every Linux distro 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 right 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 homebrew that'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 that have their own way so if you don't want to put in that's just off the top of my head. That's not even covering all the other Linux distros that have their own way. So if you don't want to put 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, pip's 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 because that is helpful. Pip run, easily doing that, or even the zip files 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 the 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 of 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 company, 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 3 to 4, 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 other major version upgrade? Even if we didn't mean to, right?

Even if we had a clear transition plan planned out, even within the community, in the community, 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. Like maybe we should do a four and make it completely innocuous

and take away that whole mystique and start doing Python 5, 6, 7 or switch to a date-based one because now we do annual releases like switch to Python 23 for Python 2023. Once again, totally throw the major number versions.

You're back to doing the Windows stuff again. Windows 95. Come on now. Yeah, exactly. But it's one of these things. People don't understand what the numbers mean because Python predates SemVar. 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. 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, we do a bug fix. Okay, it's like a patch release? Gotcha. What kind of big stuff is in the works that would require even a 4?

You asked yourself that. What's an annual feature that's maybe in the works right now? Some big stuff. Oh, that might call for a 4? Yeah, or maybe one, but the kind of stuff you're working on. So the things that kind of trigger this kind of conversation, once again, there's zero plans for there to be a 4. To be very clear, I don't want anyone to misread anything I'm about to say.

This October, Python 4 is 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 should make this the thing that do Python 4. 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 uh 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 some people have talked 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 4. And just say, if you use the old API

and you didn't make the transition, we're sorry. We're deprecating all of it. It's going away. And that's going to be the Python 4 thing. The other one that's being very actively discussed right now, not because of potentially Python 4, but 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 CPython.

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 4. 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 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 pre-compiled 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 4, that we start a transition where we have both available, both a GIL-free and traditional

GIL builds of 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 4 version when we ditch the old version. the gill, and then the no-gill version will be the one we stick with, and that'll become the Python 4 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 4? For the uninitiated, describe the reason to have a global interpreter lock

and then the pros and cons of either side, because these are trade-offs. Oh, yeah. So Python uses reference counting for garbage collection. We don't have an actual garbage collector that does traces along pointers and all that stuff. Oh, yeah. So Python uses reference counting for garbage collection. We don't have an actual garbage collector that does 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 language

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 could 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, and said, by the way, that app you want to use is now going to run 30% 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 inkref, decref thing is just baked into the C API and just how the whole thing functions. It's baked into C code. It's ancient legacy, like the underpinnings of Python. Exactly. And because it bleeds out through the C API,

it extends outside of Cthon itself as an interpreter. So we can't kind of keep that under control. 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, 10 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 is a better trade-off yeah yeah and that's the question is is it a better trade-off because well it's better than 30 but is it still better right yeah well and the thing is is we've all ended 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 now 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 gill. 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 the 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 4, maybe? How do you have time for the rest of your life with all these conversations going on?

Well, I don't get to code as much. That's how I find the time for all these conversations. on, you know? Well, I don't get to code 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'm 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 on 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 try 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 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 have been around longer than me. And so it's also led to more trying to help the new people.

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 toxic 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're wanting to dig further into 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 roughly weekly. Someone comes on, does an interview, talks about some topic. If you want something more like changelog news, that's Python Bytes. 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 nope actually it's google me oh okay we have two members of the team from Google. Okay, so you battle over communication tools. Which one am I going to use? No, Meet's easier because it's just in the browser versus asking people to install Teams.

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 how 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. It's like, whoa, it's just my idea. It's okay. 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, it's also the added steering council weight to it. So it's one of those I have to be a little careful to not overstep and give too much out there because people will just listen to me. And that's a personal comment. I even talked to my four council members slash friends

about my thoughts. I mean, I've just thought of it at the moment and suddenly they're changing the pep for me. The other four of me completely disagreed. But this is my last year on it so don't have to worry about past end of the year are you running for re-election nope are you actually retiring or you just your time is up from the syrian 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 a 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 then hits end of life and we stopped 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 like oh well it's

brett i'll just keep voting him on kind of scenarios like i would want people to want to vote me on because they 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 like nope 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 on. 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 you know what? 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 not have to worry about people taking it too seriously. Right.

And just get a bit of time and a little less stress. Yeah. Watch a few more films every week now. You can have more time for movies yeah but honestly I just want to give someone else a chance

right I think turnover is good I don't think people who have been on the project the longest should be the people necessarily who

can be 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 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 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. I literally just realized this in April when we gave our update at PyCon US and my final update, at least for now, unless I decide to come back to the Australian 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 hopefully we'll kind of, as a group, continue that on. 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. When do you think the first AI will become a steering council member? How far are we from transhumanist 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, because one thing you mentioned earlier on in the show is we have to get all the blog posts updated, which would be obviously an impossible task, but let's just call it a very large task. All those extant 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, 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. Now we're getting further and further away from being able to be up to date. That got me thinking about this Python as a default language, which 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 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 right 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 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, right?

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, right? 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 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's 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. I fully admit it. And I will fully admit my position in all this is total luck. I've always said this. Success is a combination of luck, skill, and risk-taking.

And I just happened 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, right? Because when I joined, no one knew what Python was. It was what the heck is that? Or is that that language for white space matters? And now look at where we are. So it still blows my mind personally. But yeah, I don't know. I feel kind of bad. I feel kind of bad.

Well, yeah, it sucks, right? I'm Canadian, right? I do want other 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 just happened other people agreed and continue to agree until we got to the point where we ended up 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 choosing to use Python, which was also a really weird turning point. Hearing people complain that they were forced to use Python at PyCon for the first time. Jacob Kaplomas of Django pointed that out. It's 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 referring 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 networking, TCP, IP, and then it also had the Blackjack rules. It was really a fun project. I would love to have just the free time to just write that again today. But 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 okay 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, it had this, because Google uses it,

it just had that instant appeal. Yeah, I know some other people who had that same view. But I actually have some ironic story to go 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. It's like, yeah, but they use this at Google.

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 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. I should have been like, oh, they're smart. 2003, buy a bunch of Google stock.

Would have been smart. Oh, well. Didn't pick up either, but I did write that Blackjack server. 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. Yeah, you always start in the middle. Yep. Every time. You just got to do the right weights in all the cells and just calculate. And so I did it and I spent six hours without stopping doing it in C.

I was like, oh my God, this is amazing. I think I'm going to want to do this for a living. Yeah, that's super cool. Did it have a little ASCII GUI or anything? Or how did it actually? Yeah, it was fun. And it tied to the um the numeric keypad for choosing where you wanted to place it so you could 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 is one dimensional for the better or for the worse for For the better. Oh, it's challenging. Oh, it's a 3D? Kind of. Is it 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.

Oh, okay. 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 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 uh 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 uh well the problem is is you 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 court 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 could just keep playing top right corner and you'd have to. 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'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 a 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.

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 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? So that's a good point.

We've recently done this. I don't know all the full rules totally, but I think, you know, if you're a circle, you circle it. If you're an X, you X it. And so then if you push somebody into that place, my son calls it free play. And I don't know if he's a circle you circle it if you're an x you exit um 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 oh okay so this is a 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 uh but he says it's free play which does not make sense to me rules wise so basically if i take you let's say i've won the bottom left quadrant uh 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's 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 rules 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 by then they'll be out there i could Yeah, and I'll use Textual to do it as a TUI. Yeah. Still be old school with new stuff. Ultimate tic-tac-toes on Wikipedia. Okay, link it up.

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 at all? I haven't had a need yet, but 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 a TUI these days.

I think it's pretty neat and a nice way to get a quick GUI going because Lord knows trying to do a cross-platform GUI is not easy. Right. Yeah, somewhat ironically, when we had him on the show, I mean, 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 he's like, yeah, I'm not sure Python is the best choice for that particular problem, but everything else, it's amazing. I'm like, yeah.

So touch on that point, right? Like this is Brett's like, 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 of Python's use as the glue language of the internet. If the world was just pure Python code, and people just used pure Python code with Python itself, none of this complication would be there. Pulling out the back of my day phrasing, 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 to lean into CPython C API and wanted to like wrap like the canonical examples 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? 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. Cause 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 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. It's 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 and 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, installing a different version of 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 3.10 and now it's 3.11, 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. You'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 pre-compile

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. We have to keep it isolated so at least it's still the right thing in that scenario. 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? 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.com. This is coming from Chris Lattner and Friends. Recently announced. Made big a splash. It's Python

compatible as a goal but brand new in certain ways. I don't know much about it. What do you know about it, Brett? I only know what I've read on their website. And 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 superset of Python. So fully backwards compatible with python itself

plus their additions to make 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. 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 because Python's type hints or hints like they're kind of documentation that people statically analyze to make sure the documentation is accurate but technically you can't rely on it

being true necessarily well i think mojo's compiler does that or is 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 him 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 to randomly download. I think it'd be on an invite list to get to play with it through a Jupyter notebook. So good luck to them. I will say that the history of 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 their done ends up being.

Right. Hopefully. It'd be nice. Yeah. I think the superset is smart. I think that's a play out of TypeScript's playbook. And I think that was one of the reasons why TypeScript was... And Swift. Yeah, Swift as well. Good call. Which, of course, Chris designed Swift, if you're not.

Yep. 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. They say, we believe that Python is a beautiful language. It says it's designed with

simple and composable abstractions. It eschews needless punctuation that is redundant in practice with indentation. And it's built with powerful, in parentheses, dynamic metaprogramming 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 for Mojo as taking Python ahead to the next level, completing it instead of competing with it. Yeah, 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's 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 in C or Rust, and then you do that extension module. But I think Mojo is trying to present itself 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 their code base. There's no massive language jump to this crazy curly brace world. It's just right there. And just a couple 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. That's pretty cool, actually. As I said, the Amy for super set, it's technically supposed to be fully Buxer compatible. So yeah, technically you just make 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 uh they've subsequently picked up the type hints uh the python has so that you don't have to use their language subset um but it's it's still a little different it 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-inted Python code and compile that straight to C code. But once again, they have limitations because they only support certain constructs and certain types and all that stuff. So it's not fully generic 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 even 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 3 500 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 super set 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 points, rewrite that mojo right then and there, and just use it, and you'll just be faster. It'd 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 re-implement 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... Right, 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 PyO3 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 pre-compiled 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 Flake 8 does, if you happen to know 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? It's 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've got to add

a bug here to make sure that this actually happened. Same thing here. It's really, really fast. 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. It looks like the Python community might

start 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 isn't eating into my development time, let's use the fastest language we can to get 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 partially on the recommendation of the Rust community. When we decided to standardize the configuration files for packaging, there are 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 that's partially why we went with it for pyproject.toml. To the point, actually, that Pradoon, 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. 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 it's it's cool that sometimes you can get i think i've used the word entrenched too many times on 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 just execution speed on this exact same task, I think it would be foolish not to look over there and say, hey, what if we just used both these tools together

and had a better life? I think the key word there is tool. 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 rust for speed doesn't mean your choice of python for your development needs was wrong it just means charley 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 great but if something else works better and even get and 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 everyone should no one should use python for tools it's really going to depend on you 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 could in Python. 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 and you know having a thousand times faster is it would be foolish to not want that yeah as long as the trade-offs on their side weren't you know 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 it 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 I'm 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. And it just worked out for me on this. But like all my other toolings still on Python, it's not performance sensitive. They don't need to worry about it. So what's the point? We're not Fix-A-Felix, you know. Can't walk around with a gold hammer just whacking stuff, fixing things. Fix-A-Felix as fast as you can. Use the magic hammer you got from your old man. No, not yet.

Haven't found that hammer yet. Goldhammer. Nicknamed Python or something like that. No, that's how it works. What about our Python? We have CPython. 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? Yep. Some people decided to re-implement the CPython 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 CPython compiling to Wazi specifically for WebAssembly

and the PyDi project already existed 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 projects. You know, I have a good idea and it already exists in the world and 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 can 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 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 it's like oh you just take them to whiskeykey 6. I'm like, oh, okay. Smart. 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 barbecuing 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... The bus boy.

He's the bus boy. The pool boy. I was going to say, he's the pool boy. It's a different podcast, Jared. So that was cool. I don't think I've ever seen a place like that

just run entirely by one person. You know, it was just kind of cool. It was different too. I tried to ask him about like his rub and he was 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 he was also not going to disclose 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 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 but they're not trying to keep the secrets. It's like time and temperature is the primary thing. You can cook it on a Traeger, which is wood pellets, or you can cook it with legit post oak, which is legitimate wood and tending a fire. But it's really just time and temperature, seasons, seasonings, rubs, whatever. That's what you think. Well, I mean, that's what I hear.

Well, this is why you're going to have Craig backstage what i hear 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 asking what your secret is you might tell him tell him, yeah, I'm not going to tell you what my secret is. Well, I was just trying to BS the guy, and 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 enjoy. Did you get your bourbon? Do you like it? Okay, good. Drink that. But there you go. It was a good experience, though.

It was nice meeting Brett. Can I believe how tall he is? And then, obviously, the barbecue was stellar. So tall. Not quite as tall as some people who join clubs. And then we got that ice cream afterwards. What was that ice cream? Oh, yeah.

Oh, we went to Ernest Ice Cream, one of our favorite ice cream joints. Ernest. Y'all got sundaes. Right. So if you're ever in Vancouver, meet up with Brett and Andrea. Or just go to Whiskey 7, Whiskey 6? 6. Whiskey 6.

You can't have 7. Ice cream at Ernest Ice Cream. Although... Well, I'm actually thinking about making Whiskey 7 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 going to have two people work there, not just one. Get your food twice as fast. Yeah, we're very lucky to have that because there's not a ton of barbecue places in town, which is probably why he was a little productive. We are very lucky to be spoiled for ice cream, though. 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 give that up. Yeah. I can definitely take you to multiple ice cream spots next time you come. There's lots of great ice cream spots there. Well, when you come here to Texas, I'll take you guys, Jared, I'll take you any day. They still let you in the States, Brett?

They still let you come? Yep. I actually have... Well, he's a dope citizen, right? Aren't you a 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 straddle the line anymore. 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 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 was a massive hassle. So it 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 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. Oh, man. The day before. Let's go.

Hey, Anaconda is actually a local company to you. They're actually based in Austin, Texas. Is that right? Peter Wang. Peter Wang. Anaconda. He's been on Practically AI. Never heard of it.

Smart guy. He's been on Practically AI a couple 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 was fun. Hey, anytime. Great talking to you both. It was fun, Brett. Bye, friends. Bye, friends. Bye, friends. Well, where are your pip install anxiety levels?

Is PipX 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 ChangeLogging friends, tell your friends about the show. 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 ChangeLogging 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.