Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 221, I think, recorded, when is it? February 17th, 2021.
I'm Brian Okken.
I'm Michael Kennedy.
And we also have Brett Cannon, yeah.
I always talk over the third person. I'm not sure why.
Well, you're always going like, is there going to be an introduction or should I just join the Brady Bunch theme?
Let's just go in a circle and just introduce ourselves.
Well, if we're going to do Brady Bunch, we've got to have more people so we can fill out, what is that, rows of three or whatever in the picture?
I'm sure Anthony Shaw and Paul Everett are available based on how often they show up here, so I'm sure they're waiting in the ways.
That's right. We'll just swoop them in here for the right picture.
Welcome, Brett. It's great to have you here.
Lovely to be back.
You know what, Brian, I'm impressed with Brett's microphone.
He has mastered the work from home.
Yeah, I love this. We're going to have to put a link in the show notes to this thing.
Tell people about this.
So, Brian and I both have good microphones.
We have many different microphones we've tried, but yours has a visual aspect, which is unusual for audio.
Yeah.
So, it's a HyperX Quadcast S specifically, and it comes with RGB lighting because it's really a gamer mic.
But, obviously, in pandemic times, I work from home.
And my wife is also at home because of the pandemic.
And we always had an issue of her wanting to come in and not knowing whether I was actually occupied actually in a meeting, because I'm in them a lot for work, or whether or not I was just sitting there with my headphones on listening to music or whatever, and she could totally just walk in.
And so, the great thing about this microphone is if it has a touch sensitive top, and if you tap it, the LEDs turn off.
And so, it acts as like an on-air light for the room.
I mean, it's not that bright specifically, but if she opens the door, she can totally just look in and go, is the mic lit?
And if the mic's not lit, she knows she's not going to be heard or be directly interrupting me, and I can just turn and answer any questions she has.
And it's awesome.
It works out great that way.
That is so fantastic.
The whole mic glows when it's on and active.
Different colors.
It's beautiful.
I love it.
Yeah, and you can even change which colors it uses.
I can't remember if it's waterfall or not, but you can actually change how the color spectrum changes from side to side in terms of colors and whether it's top to bottom or not.
It's very pretty.
I think I once did Harry Potter color theme for a co-worker of mine who's a big Harry Potter fan for all the houses.
And I've purposely not played with it and kept with the defaults because it's definitely one of those things I could totally nerd out on and play with the colors all day long.
I tried Python colors once.
The transitions didn't look quite as nice, but, you know.
Yeah, no, it's good.
I have the microphone that matches.
I'm sorry, the mouse that matches it.
Oh, nice.
And it pulses.
So, I didn't get it for the color, but it's the only one I could get that had color.
I'm like, why is it of color?
How do I turn this off?
But no, it just has color.
It's fine.
But anyway, great mic.
I think people should check that out if they have like weird work from home situations and people are interrupting.
It's super cool.
I love it.
Definitely get a mic stand, though.
The default stand is a little low.
And I have found that getting a cheap, like $10, $15 stand.
I got this from Amazon that pushes it off about seven inches, I think.
I'm trying to do the American units.
It pushes up about 15 centimeters.
Perfect.
It's a nice sweet spot in terms of distance while it's still not completely taking up your vision in the screen.
Yeah, excellent.
Excellent.
Well, Brian, you want to kick us off here with our first topic?
Yeah.
Well, we've got – it's hard to keep up with Will McCoogan.
Sorry, Will.
Will wrote Rich, which is a – I forget what he calls it.
Basically, it's a CLI tool.
But there's been a whole bunch of really cool things he's done recently, like really recently.
So in December, he added Live View, which allows you to just – it continually updates whenever an event happens or something in that part of the screen, which is cool.
He didn't write a blog post on that.
But then in January, Tree View came out.
And the Tree Views are lovely.
You can do all sorts of stuff with the Tree View.
And yeah, it's a nice thing to have in a CLI tool.
And then what's really impressive to me, I think, was layouts.
So this month, he released layouts.
And it allows you to split the screen up.
And his demo even shows it happening within a VS Code.
Oh, yeah.
Within the bottom.
Yeah.
Terminal part of VS Code.
Yeah.
Brett, you've heard of this, right?
You've heard of this tool?
How can I not?
I'm a fan of the podcast.
And Brian loves this tool.
So I've heard about it multiple times.
So I guess we've covered it before.
But one of the reasons why I'm covering it again, there's a couple of reasons, is the layout's neat.
And really, now I want to click on stuff and I want to do entry.
And he sort of hinted at that, that he's kind of going towards a full TUI, which I had never heard of before.
Text user interface.
Yeah, TUIs.
All right.
Right on.
That'd be cool.
So I think that would be neat.
And I'd like to encourage that.
So the other thing that's going on with Rich is he's accepting sponsorships now.
And it's kind of hidden in the demo window.
But we're highlighting it on the show so more people can know about it.
So on GitHub, he's doing sponsorships on GitHub.
And I like how GitHub sponsorships work.
It's kind of neat.
So check it out.
The other thing that I guess when I was playing with these layout things that I didn't really realize before is you can just say Python-mrich.
And it shows a little demo of a whole bunch of stuff.
And then some of the particular parts of it, you can demo them individually.
Like for the layout, you can say Python-mrich.layout.
And it'll show a demo.
That's cool.
The tree is also as a demo.
And the live one, actually, I couldn't escape it.
I had to kill my window.
So the live one just continually updates some, like, I think it does.
I don't know if it's actually going out to the internet.
But it's doing some, like, conversions of monetary conversions.
And it just kept updating.
And it doesn't hit Control-C.
So it's got a bear except somewhere they shouldn't have.
I think it's very reliable.
I mean, the only way to exit it is forced quit.
So we're all...
Kill Dash 9.
Where's your friend?
So, yeah.
I'd love to have Rich continue with this and make it a full 2E.
That would be fun.
That would be very cool.
Because the presentation is really nice here.
I will also fully support Will making this a full-on thing.
Because actually, a couple months ago, I did a slight dive on a weekend trying to find some TUI libraries.
Because I have a personal project for work purposes that I've been trying to do a GUI for.
And two years in a row, I've tried to do it during hackathon week at Microsoft.
And I keep failing because I don't have enough time to dive into all the GUI libraries that go from, like, here's how to do Hello World.
Here's the reference.
And it's like, no, no.
I need more steps there.
Where's that middle ground?
Come on.
Yeah, exactly.
And then I decided, oh, well, I totally could just do this in Curses.
It's like, it's literally just to keep track of what I do every day.
And it's just like, it's snippets from Google is where I picked up the habit of just literally just, oh, I did this today.
That was out of ordinary.
I did this today.
That was out of ordinary.
Just to kind of track the high level, not just meanings, but I actually did something different today.
And it's like, oh, I could totally do this in the terminals.
Like, suddenly pull up in Curses library.
It's in the Snare library.
And it's like, oh, yes, you need to know the size of your terminal window and all this other stuff.
And, oh, how to move the cursor to this specific position.
It's like, yeah, no, I still don't have time for this.
So if we're trying to move this along and make input work, I mean, I would be totally down for giving it a shot.
Yeah.
Yeah, quite cool.
And if people don't know, you kind of live an alter ego.
You've got Brett Cannon Open Source Steering Council and also work closely with VS Code at Microsoft, right?
So having the screenshot on the screen is right at home.
Yeah, yeah.
Just for people who don't know, I'm the dev manager for the Python extension for VS Code.
That's how I pay for my open source habit, which includes being on the Python Steering Council and the core dev.
Yeah, yeah, quite cool.
So Gandalfor says, I've been using Prompt Toolkit for the Tui library for a while, but this rich seems a lot nicer if it actually accepted input, which I agree.
It seems very cool.
And I've heard some people using them together.
I just don't know how to do that.
So if somebody wants to write a tutorial on how to use both rich and Prompt Toolkit together, that'd be cool.
Yeah, that would be cool, actually.
All right.
What I want to talk about is this article I ran across and some tools that I went to play with afterwards after reading it called 12 requests per second.
Sounds amazing, right?
So it's a realistic look at web frameworks and Python web frameworks.
So if you look out there, you'll hear things like, oh, we're getting 100,000 requests per second on uv loop with a single thread.
Or, you know, we've got Sanic doing 100,000 requests or even Jopronto up to 1.2 million requests per second, right?
Which is amazing.
And then a lot of these examples are doing like really not real type of work, right?
They're just doing some little tiny thing like, oh, here, let's add two numbers and tell you how fast we can do that.
So this article is more like, well, let's go through a real application and see what kind of performance you might expect.
So I thought it'd be fun to talk about this because it gives some people some things to think about.
You know, how can you compare your app to these types of quotes that people are getting and so on?
And would it be better to choose something like Jopronto or AIoHTP or FastAPI or something like that over, say, Flask or Django,
which don't have so much support for things like Async.
So I thought this was fun to go through and just kind of look at it.
They start out by profiling just sort of a Hello World app and they get, all right, well, Hello World's pretty good.
If you run Flask on CPython, you get some amount here.
Maybe it was 500 to 1,000.
You run it on PyPy.
They were able to get 3,000.
You run it.
And so that's just, you know, Flask run, right?
Which is not really the way you should probably be doing things.
You should be running on G Unicorn or uWSGI or something like that.
So if they ran the same thing on G Unicorn, right, it's up to like 12,000.
And you run it on, compare that against Sanic, you get, you know, Sanic was doing like 24,000 or something.
So these comparisons I thought would be fun for people.
You can go through, they've got a bunch of graphs that you can check out.
But then they write one that actually talks to a database doing database-y things.
And then let me get down to the numbers here, the bottom for that.
And they're like, okay, well, with this one, now we're running at, you know, quite a bit lower request per second.
And I think in the end they said for our real app, what we ended up with is a whopping like 12 requests per second.
Yeah, here we go.
Here's the graph I was looking for.
Where like, this is Flask running the synchronous Postgres driver there.
And that's all pretty interesting.
I think, you know, even be able to answer the question, you know, well, what about me?
What about my app?
How would it do if I were to run these things against it?
And we've talked about Locus before.
Locus is a really fantastic way to write load testing and user interaction testing against websites,
web APIs and so on.
And it's all about Python.
So what you do with this is you go through and you write some kind of class and you say, okay, here's a test,
like a representation of what people might do to my website.
They might log in.
They might go view the episode page.
If we were testing the Python Bytes site, they go check out the episode page.
They might drill into an episode.
They might do a search.
And what you can do is you write simple little bits of Python to say, here's a function that does this action.
Here's a function that does that action.
Like, here's one that goes to the episode listing.
And then you can actually, it's not shown in the example here, but you can say things like, well, you know, 10 out of 15 times, I want them to view an episode page.
One out of the 10 times, I want them to do a search.
And three out of the 10 times, I want them to actually go to the listing, right?
So you can sort of break it up to what the normal look would be.
Then you just run Locus and you get like this web UI where you enter some information.
And then it just runs, if you want, even in a distributed way against your site and then, you know, pounds it until it gives up, basically.
Brett, have you heard this tool?
No, I actually haven't.
I mean, you hear about different tools for different things, but this is pretty, looking at this example, it's pretty simple, which is pretty great.
Yeah, the simplicity is really great.
And then when you run it, you actually get a web view into it.
Then the web UI lets you basically control and monitor the tests in real time.
So anyway, coming back to some numbers off of that, I decided, well, if they're getting, you know, 12 to 80 requests per second, what does my stuff look like?
Like, for example, I talk to Python training stuff.
It's not using any of this async stuff.
How is it doing?
So it's Python 3, MicroWisgee, Pyramid, MongoDB on a $20 server.
Would it get 12 requests per second?
I don't know.
So I turned this thing loose and it'll do about 125 requests per second.
I felt better than, that's better than 12.
I felt pretty good.
But one of the things that's cool about Locus is you can tell it, not just, I want you to use this partitioning, but also I would like you to have a distribution of how often the user actually does something.
So you can say, well, this user is going to make between every 10 to 60 seconds, it's going to do one of these things among this mix.
So instead of just pounding it, it's like, well, an average user doesn't just hit F5 or control command R as hard as they can.
They move around and they pause, right?
So you can pause that.
So I don't know, maybe it's 10 to 20,000 realistic users I was able to sort of map out with this.
Anyway, it was just a fun deep dive into like, well, what does performance look like?
How important is async?
Some of the tools to do it.
I don't know.
If people are, if that's interesting, people definitely check out this 12 requests per second article here.
I think you'll enjoy it.
Then also check out Locus if you want to try to answer that question for yourself.
So I was curious how, when you're testing your site, did anybody else like experience downtime or something while you're being on it?
Well, so that's the question, right?
Like with the Locus thing, you can start to see what the like real time, what the response times are and everything.
It never crashed.
It just got a little bit slow.
So I was, you know, I ran it locally and I'm like, well, what's it look like in production, right?
So I'm like, I really want to know what with all the way that everything's put together, what number will I get?
So I'm like, I'm just going to turn it loose on it.
And if it starts to overwhelm it, I'll just hit the stop button, you know, and it never died.
It just got to where it took like three or 400 milliseconds to get back to me.
So it was okay.
Okay, good.
Yeah.
So pretty fun.
Pretty fun example there.
I think one other thing I appreciate about that blog post actually was they pointed out towards the end that at some point scaling is no longer a Python problem and it's an infrastructure problem.
Like, oh, it's probably better to update your database and stuff.
And I've heard this from a lot of people too.
There's kind of a misnomer if you're not in the Python community that, oh, Python's so slow, it's going to be your bottleneck.
And instead, I've heard it from a lot of people in the community that, oh, actually it's not.
I can get it done, get my work done a third of a time.
And then the two thirds of time it would have taken me to do it in, I don't know, Java, just choosing a language.
I can optimize my infrastructure.
And guess what?
I end up with the same performance with more time to bug fix and test than I would have in the other platform.
And the other thing is, is obviously there's, there is always throwing more hardware at the problem if you need to horizontally scale.
But, and honestly, I think when I say this post also, I think from our correctly pointed out, not everyone needs a thousand requests a second.
Most people don't.
Even popular websites are not doing a thousand.
I mean, that's a lot of requests.
A thousand requests a second.
That is a lot.
Like most people measure in queries per minute, not per second.
Right?
Yeah.
So like even 12 per second, like we're still talking 720, if my math is not finding me on the spot, requests per minute.
Right?
That's still a decent cliff.
Like if you're running a business that's getting that much traffic every single minute, you're probably still doing pretty good for yourself.
Yeah.
That's 32 million page views per month.
Right?
That's like you're at a limit where you've got some real stuff going on, some real infrastructure.
Well, okay.
So, but there's also, if I've got services running, I've got a bunch of services that include this.
So, I mean, one user interaction isn't one hit.
It might be dozens.
Yeah.
So, my rule of thumb is honestly, don't worry unless you're going over a hundred a second.
Like you should be able to hit a hundred a second without too much effort.
And after that, you might have to start doing some planning.
But I would suspect as a general rule of thumb, you can handle hundreds without a whole lot of effort in Python.
Yeah.
If you're getting to a thousand, you might have to do a bit more planning for it, but it's solely serviceable for that kind of thing.
Yeah.
Totally agree.
Magnus Carlson has a quick comment.
Nice.
So, I can now see if my work turning my FastAPI app into async was worth it.
Yes, you can.
That's a very good use of that.
I'm going to be biased and just say it was totally worth it, Magnus.
You just don't know yet.
Because it's got the cool new design patterns.
Absolutely.
Exactly.
All right, Brett, you're up next.
You've got something special for us.
Yeah.
So, the world exclusive news breaking thing is the Python launcher for Unix is probably at RC stage.
For those of you who don't know about this, it's a project I've been working on since May of 2018.
And if you're a Windows user, you probably know what I'm talking about.
But on Windows, there's a little app called the Python launcher for Windows.
And it ships with Python.
And it gives you the Py command.
So, sometimes you might see this on websites where they say, well, if you're on Windows, you run Python using PY.
And then the command and other platforms just run with Python 3.
And I decided that I kind of wanted this on Unix.
I had enough people complain to me about how it's difficult to get started.
We're having the Windows instructions on how to run something was always different from the Unix version and all this.
Yes.
That is really annoying.
The very first thing you got to do, like right at the start, like, oh, it's so easy.
But there's these two ways.
There's like this diversion, right?
Exactly.
And I saw some benefits of the Python launcher because what it does on Windows is it serves kind of two key purposes.
One is it kind of makes up for the lack of shebang support on Windows because the launcher will actually look for a shebang line,
figure out what version of Python is required, and then finds the right version of Python to run it.
The other thing is it does away with the need of caring about what order you installed your Pythons in.
Because, like, for instance, on Unix, like Python 3, what does that point at?
Well, what it points at is the last version of Python 3 that you installed, not the newest version of Python.
Yeah.
So if you installed 3.9 today, but then installed the 3.8 security release that I think happened yesterday, you will get 3.8 as your version for Python 3.
So if you don't specify Python 3.9, you won't be running it.
Like, you have to either create your virtual environment and be using it that way or remember that.
Python launcher takes care of all that.
It will automatically just figure out what versions you have installed and just automatically run the newest version.
And so I really like that.
So I decided to implement it in Rust, partially as a Rust project of decent size, and it's about a thousand lines of Rust code.
And also because I wanted it, because if this works out, hopefully some projects can stop listing two different ways to run things.
So in the Unix version, it's a little different from the Windows version, and I'll ask for feedback from the two of you and anyone in the live stream if they want to provide it.
First, it looks to see if a virtual environment is activated.
So it looks for the virtual under env environment variable, and if it's there, it just uses that.
So automatically, this is a little shorter and easier if you have an activated virtual environment.
It's just PY now instead of having to type Python.
The next one is if you have...
You're here to save us from RSI already.
I'm kidding, but this is really interesting.
Keep going.
Yeah.
One third the typing.
The other thing is if you create a virtual environment in a .venv directory, it will also automatically use that without activation.
So once again, if you use the, I personally think, standard nomenclature, naming your virtual environments .venv, you don't even have to activate them anymore.
Because activation is just a shorthand for the shell that, honestly, I typically just use to make Python do the right thing.
Because I use dashed m for everything, even when I'm in an activated environment.
This takes care of that entire step for me, so I don't have to activate my environments anymore.
That's super cool.
After that, it does the shebang, just like on Windows, trying to figure out what the right Python might be for that.
And then after that, it checks some environment variables.
Like if you want to, if you have 3.10 installed, for instance, for Python, you have an alpha installed.
But you want to make sure that if you ever say, hey, if I say Python, if I run Py with no arguments or say, hey, I want to run a Python 3 version of Python, you can actually set the environment variables to restrict it and basically specify the exact version you want.
And then after that, it just, if none of that triggers, it just finds the newest version and runs that.
I've been running this personally for a while.
And when I added the .venv support, I've completely switched.
I don't even bother typing Python anymore because this completely fits my workflow of just doing exactly what I think it should do whenever I need.
Now, the question I have for the two of you and anyone in the audience who cares to answer is, do you think prioritizing virtual environments over shebangs makes sense?
Now, my argument is yes, obviously, or else I would have done it this way.
But this is partially, I don't know how much of this is a Unixism versus just in general, because I do hope to actually add Windows support to this as well and make this a universal Python launcher.
So the reason I did it this way was on Unix, you can just chmod a file and add the executable bit.
And that's how you can execute it.
And honestly, most of my files at this point are going to be in a virtual environment anyway, whether it's sold via PipX or I create an entry point and I install that.
So once again, I don't need the shebang directly.
It's just going to be baked into the executable and Windows will do the exact same thing, right?
Like set of tools will give you that little shim.
So to me, if I am running in a project directory with a virtual environment, whether activated or not, I'm assuming that's what I want.
Don't try to figure it out for me or else I'd be running this somewhere else and I would not have a virtual environment installed.
Does that logic make sense?
Do people do you think I made the right decision here and choosing virtual environments over shebang lines or am I crazy?
I forgot shebangs were even supported.
I'm all about virtual environments.
Yes.
Okay, cool.
I think this is fantastic.
I've long wanted an easy way to just say I'm down inside.
Maybe you can tell me if it works this way.
Does it traverse up looking for a virtual environment?
Like if I'm in a subdirectory and I try to pie a file, but one directory up, there's a virtual environment.
Will it go up and find that and then use it?
No, I did not implement it that way.
It would not be too difficult to do it that way.
But for simplicity reasons, when I first plugged this in, for my purposes, I'm not an SRC guy like Brian is, for instance.
So I don't need to worry about that as much.
But that would be totally reasonable feature request to ask for to be able to traverse up a directory who's looking for the .vnv directory.
Yeah, very cool.
I'm down a level in my SRC.
Go up a level to find the actual.
Right, like I have a lot of things that will do like maintenance for my website.
So I'll have like a bin folder as one of the subfolders of my website.
Then I'll go in there and I want to run something.
If I'm like, oh, I should have run and gone up and then bin slash.
I think it'd just be really cool.
Like I'm sort of in the realm of this virtual environment, even if it's not at the same working directory.
Yeah, and one thing I do want to clarify here is this is very much about simplifying running Python manually.
It is not meant to completely replace running Python, right?
Like a misnomer I hear from people when I tell them about this is like, oh, hey, are you going to add a config file to be able to alias to PyPy versus specifically or this thing or a framework builder that thing is.
And for me is if you have that kind of specific requirement of a specific version of Python you have installed, just use the absolute paths of that version of Python.
Yeah, I don't think this is this is purely for I just want the newest version.
I don't care what it is.
Just give it to me or I have a virtual environment.
Just give me the virtual environment.
I don't want to have to think about it.
If you have to put thought into what kind of Python you want to run, I think you should be specifying that manually, not be using this.
Well, so on the side of the being able to go up a couple directories looking for virtual environments, I'm often not in the source directory.
I'm often sitting in the tests directory running pytest on stuff, in which case, I guess I already am in a virtual environment.
So it doesn't matter.
But I might just open up another terminal and try to just run Python.
So I like this.
I'm excited to hear that this is eventually going to be a Windows thing also, hopefully.
I don't actually normally use the Python launcher on Windows.
Does it?
It doesn't do looking for virtual environments, does it?
No, that's exclusive.
That is exclusive to the Unix version of this launcher.
So basically, the environment variable it will use, it doesn't actually look on path.
It completely uses the Windows registry.
It does the shebang.
And that's it.
So looking in the .venv folder, that is entirely my addition.
And the order of execution here is kind of tweaked to what I think.
And it doesn't search on path, actually.
So that's a Unix thing specifically.
But I suspect this will actually help with the Windows Store, although I think Steve Dower fixed that issue with the Windows Store install.
But yeah, so there's slight tweaks.
But I figure if I have all the logic done already, there's no reason not to just make it universal to support multiple platforms.
So why not?
Yeah.
So your announcement here has kind of lit up the live stream.
So ZDocs is just a Brett Cannon fan, which is awesome.
So Gendal Forth asks, is the Rust version cross-platform in any way?
Is there a chance of this on Windows?
No, I don't.
I've not tried it on Windows.
It definitely works on Mac and Linux, right?
So it truly is Unix-based.
So it will handle that no problem.
I've not tried to wire it up into the registry at all.
So that's not there.
I have an open enhancement issue to do that.
I honestly don't know what would happen if you tried running this on Windows.
I haven't tried.
Everything's very hard-coded to Unix at the moment, just to get this done.
If you look at the readme, you'll notice everything is slash bin.
Slash user slash bin, yeah.
There's no scripts support here.
If slash one, I do Windows support.
Obviously, I'll look at fix.
But I have tried putting zero effort.
Because the Python launcher for Windows just comes with the install from Python.org, right?
So there was no real time pressure to try to get that done.
So I haven't tried it.
I'm a big fan.
I could try this on my macOS and I'd be happy now.
Yeah.
This is how I do it.
I have it on my Mac.
I just installed.
You do have to install Rust to install it right now.
Because I haven't figured out how to do distributable binaries that you can just download.
But yeah, if you have Rust installed, which you can get through Rust up or Homebrew or whatever,
it's just a cargo install away.
So if you want to get a shot, please do so.
Fantastic.
And then I kind of forgot that my Mac was Unix-y.
That's right.
And Magnus agrees on the VNV over shebang.
Awesome.
And Gandalfor says same as well.
I don't think I've ever seen a shebang that was more specific than user bin Python 3 anyway.
Yeah.
And I actually suspect the shebang support was partially because the Python launcher has been
around back in Python 2 days, right?
Where that was much more of a concern.
So like, as I said, I started this in 2018.
So it was pre-Python 2 deprecation.
So it's still supported there.
But a lot of this, I think, was also partially to support the 2 to 3 transition.
So those little extras here, I don't think are quite as important unless Python 4 happens
someday, which there are zero plans for.
So I don't think so.
Yeah.
Don't hold your breath.
By the way, one extra nicety I want to tell people is if you're a Starship user, the Starship
cross shell prompt, there's a setting in Starship that lets you specify how it figures out what
version of Python you have.
Now, it does look for virtualenv, but otherwise it has a list of binaries that it will execute
to try to figure out what version of Python you have.
If you set it to Py using this, it will always tell you either what the virtual environment's
Python version is in the prompt or whatever the newest version of Python is installed.
So it has a really nice side effect.
Because if you read the docs in Starship, there's a big tip saying, hey, if you have
a Python installed that's default, i.e.
macOS, and it'll always say 2.7 unless you happen to have an activated virtual environment,
which always threw me because it's like, yeah, I'm not using 2.7 in this project.
As soon as I added this support for .venv files and tweaked my Starship config for this,
it always tells me the exact version that I happen to have set up for my virtual environment.
It's really handy.
For those of us not in the know, what's Starship?
So Starship is a cross-platform shell prompt tool.
So it's written in Rust.
But basically what you do is it has instructions for Bash and Zeesh and Phish and PowerShell and
everything else.
And basically it just gives you a line.
Brian's got it pulled up on the screen for those on the live stream.
And it's basically just an easy way to just say like, hey, this is how I want my prompt
to look.
Don't worry about whether it being Bash or Zeesh or Phish, whatever.
Like I'm a Phish user.
I'm sure Michael's probably a Zeesh user being a macOS user like he is.
Yep.
But it shouldn't matter.
My prompt is a prompt.
And pretty much they have pretty consistent user support.
So I decided, yeah, you know what?
I like some of the niceties it has automatically baked in.
It does like notification, it changes prompt for the usual, oh, I edited my Git checkout.
It'll tell you what branch you're on.
All these little nice things.
And setting fear code as my font gives me all the nice little glyphs that I want.
And so I said, nice.
All right, cool.
It'll tell me what version of Python is currently activated.
Except for that annoyance of being on Mac.
It kept saying, oh, you've got 2.7 until I activated.
And I was like, no, I don't like this.
So I prioritized getting the .vnv done.
And then lo and behold, it magically now tells me exactly what I want for Python.
Nice.
Wow, that's super cool.
Yeah, now we know.
Starship, fantastic.
Yeah, so before we move on, I'd like to thank our sponsor.
So this episode of Python Bytes is brought to you by Datadog.
Are you having trouble visualizing latency, CPU, and memory bottlenecks in your apps?
And not sure where the issue is coming from or how to solve it?
Datadog seamlessly correlates logs and traces at the level of individual requests
allowing you to quickly troubleshoot your Python application.
Plus, their continuous profiler allows you to find most resource-consuming parts
in your production code all the time at any scale with minimal overhead.
Be the hero that got your app back on track at your company.
Get started today with a free trial at pythonbytes.fm/Datadog
or just click the link in your podcast player show notes.
Ooh, that's neat.
Yeah, very cool.
Thanks, Datadog.
So, Brett, I want to take you down a little bit lower.
If it's turtles all the way down, a few turtles down to this whole TUI world
and talk about this thing called build a text editor with Python and curses.
Is curses, is that what you do when you get upset because it's too low level?
Or, oh, no, it's about the curses.
Sorry.
Okay.
Got to remember, I'm on the Python Bytes podcast.
There are going to be jokes like that.
They're going to be bad, too, by the way.
So, no, here's a really cool article by Wasim Lorgat about basically walking you through building
a text editor like Vim or Emacs in the terminal using curses, which is a library that lets you
control what happens on the screen much better than, like, print and log and warn and whatnot.
So, there's a couple of just interesting things.
I thought going through this might just give people a sense of, like, what it's like to
work with curses.
And then there's this context of this text editor you can play with.
So, for example, a minimal curses app, all you got to do is define a function.
That's your main function.
And then while true, go to the screen and get the key.
And that's it.
You just say get key.
And it just gives you whatever gets pressed.
Without any help here, there's probably not a way to get out of it.
No.
Maybe control C.
But, yeah, there's not, like, a quit or anything.
So, you can really easily add, like, some tests and say, well, if they gave me the key,
you know, escape, then show the little colon.
You can WQ, exclamation mark, whatever, to get out of it.
However you want to exit your text editor that you're building.
And then they talk about how to show stuff on the screen.
So, if you want to just add a line, you can say, at this X, Y screen, you know,
cursor location, just write this line of text on the screen.
And it'll add that.
So, really easy.
And, you know, one of the things they do is they pass over the file name.
And it's kind of meta.
Like, they edit the file that is the demo for the editor with the editor as they're building it,
which is always fun to do.
So, you can do that.
But then, through this article, they go through and they build out, like, a window class
that talks about how big is the screen.
This is what Brett was talking about.
Like, ah, I got to figure out what my screen looks like and all that stuff.
And also, a cursor where you are on the screen.
How to have, like, a view into the file.
Because you might have, like, moved to the right a little bit.
And the file might be a thousand lines.
But you've only got a 40 on your screen or whatever.
So, anyway, if this is interesting to you,
I think you should go through this article and check it out.
In the end, you end up with a pretty simple but non-trivial little text editor
that lets you do stuff.
So, I think it's pretty neat.
What do you guys think?
This shows me why I really hope Will grants Brian's wish
of making Rich a full TY library.
Yeah.
I do agree.
I think if Rich, if something like that that has a really beautiful display technology,
but also has input.
Like, this is cool because it has a really great way to accept user input
and, like, update the screen.
But it's very low level.
It's like, I don't know, it's OpenGL versus Pi game or arcade.
You're, like, at the level of, here's what I put at this cursor, this XY coordinate.
Let's put that there.
Yeah.
I think it's a great showing of actually how much work it actually needs to go into making
those full text-based UIs that you see, like you used to see at the grocery store and those
screen, you probably still do at some of your grocery stores on that screen and just like,
or when they book your airline ticket and you're like, oh my God, what the hell are you using?
You do this all day?
Yeah, exactly.
It takes a lot of work to make those things happen.
It's surprising how much work it is and hence why getting higher level libraries like,
I think, that was the prompt toolkit we were told about earlier and Rich and all that would
be very welcome in existing.
Yeah, absolutely.
Do you got, either of you guys know if there's any curses libraries for Windows?
Magnus is asking.
That's why he's used prompt toolkit before, but I'm not sure actually.
Neither am I.
Yeah.
Cool, cool.
All right.
What's the next one?
Brian, you got the next one, right?
Actually, I skipped.
So, Brett's next.
All right, Brett's next and I'll pull up Brett's thing.
All right, Brett.
Okay.
So, there's been a major language feature announced that is coming in 3.10, right?
Yes, which actually was in your quick links at the end of episode 220, which Brian called
the five-barrel foot gun, which is pattern matching.
So, one of the things that always happens whenever there's a new Python feature that gets announced,
and especially one of this size that gets out into the general community, is some interesting
feelings from people.
And so, this is kind of slash, I don't want to say rant, but a little just me as a steering
council member just trying to explain how this all came about, where we're coming from as
a steering council in general.
I mean, obviously, I'm speaking for me directly, but generally, I think how the steering council
kind of thought.
But also, just kind of helping put all this in perspective, because I think for a lot of
people, this might be the first big feature that they've seen, because we used to do this
all the time in Python 2.
But things kind of slowed down for Python 3.
So, as I said, I've seen around the internet a lot of people ranging from, oh, this looks really cool.
I can't wait till I can use it, to people screaming bloody murder that we're killing Python.
And oh my God, it's the death knell of the language.
I've been doing this for 17 years.
Is it stressful for you?
Because it used to be?
It used to be stressful.
Now, it's just frustrating.
So, for instance, I gave a talk at PyCon US 2018.
It was one of the keynotes about participating in open source.
And one of the key things I said in it was people just need to try to be kind to each other.
It's kind of a very generic thing, I know.
But it really makes a difference.
As a project maintainer myself, having people tell me what they think I need to be doing or what
I should be doing is really frustrating, right?
Like, I put my personal time and effort into helping make this happen.
And the way you respond to that is telling me what I should be doing.
Yeah.
Like, I can only imagine people who are parents having other people tell them how they should
be raising their children.
It's worse than helicopter parents.
It's like helicopter backseat parenting.
Exactly.
And it's kind of the equivalent for open source maintainers.
People doing the backseat.
Oh, here's what you really should be doing with your free time, with what little time
you have left on this planet, right?
Yeah.
So it used to get really upsetting.
And now I'm just frustrated and just disappointed that this still happens.
It's also a little weird, too, because in Python, right?
I mean, we have tens of millions of people using language at this point, right?
It's immeasurable.
It's just cute.
Which means even if you assume one out of a thousand people are jerks, right?
0.1%.
Let's do 0.01%, right?
Like, we're still talking tens of thousands of people out there who basically know my face,
name, and address and feel totally fine sending me mail on occasion or just posting out in the
comments outside where we all congregate about what they think I should be doing with my life.
So it's one of these things where it's just frustrating.
I don't know how a lot of people feel about it.
Sorry.
But I think when you hear those negative things said to you, even if a thousand people are
appreciative, the one negative thing you get feels so much.
It makes such a bigger disproportionate impact.
Yeah, at least.
At least.
And the problem is it's not relative numbers.
It's absolute numbers.
And at the scale that we're at with Python, the absolute number of people who just don't
haven't quite either just, I mean, honestly, some people are just totally ignorant that they
are speaking this way and that they don't really realize the way they're phrasing things matters
or even that the way they're phrasing it comes off that way.
Like not everyone who says should really means for it to come off that way.
Thank you, Dean.
I appreciate the awesomeness call out.
But it's one of these things where I have to bring this up every couple of years.
And then I usually end up doing a blog post, which honestly, this is kind of a rough draft
of the blog post.
I'm just talking out loud with all of you.
Yeah.
And bouncing ideas off all of you for the feedback.
But it's just it gets a little exhausting that this is something I have to bring up every
couple of years.
You'd hope that we'd all learn this by now.
It's not like open source is a new newfangled thing we've all just discovered.
But there's still this disconnect between the consumer slash user slash takers of open
source versus the maintainer slash producer slash givers of the community.
And the disconnect of how to kind of just communicate with each other is still there.
And so specifically when it comes to this stuff with Python, right, is people go like, oh, my
God, this is crazy.
And it's like, no, it's not.
I've been doing this for 17 years.
Everything is controversial when it comes to syntax.
True and false were controversial, right?
Like true and false.
There were arguments on Python dev and whether or not we should add those keywords because
they would break code that chose to define those constants as one and zero.
Is that why it's capital T?
Well, it's also because they're singletons, right?
And that's just kind of the practice we follow with none.
So that was really kind of where it tied in.
I mean, it definitely helped that capital T lower the chance.
It's less likely.
Yeah, exactly.
It's less likely.
But that was an actual discussion we had was do we want to add booleans to the language?
Now, today, everyone scoffs at that and laughs.
Like, what?
Are you kidding me?
Booleans?
Really?
Everything in the language gets debated, right?
And in this too, right?
Like everyone's going like, oh, my God, what are you doing?
Like, do you understand the timeline of this?
Guido brought this up, I think, in July, maybe?
And had as one pep, got a massive amount of feedback on Python dev on this, went back with
his co-authors, broke it up into three peps, 634, 635, and 636, so that there was a pep
about the design, a PEP about the rationale behind the design, and a PEP that acts as
a tutorial to try to make it more easy to consume.
Brought that out in October.
We discussed it on Steering Council 2020.
We made a recommendation that probably the next one should accept it, but we still didn't
feel we had enough time to accept such a large thing.
Fast forward now to today, where Steering Council 2021 had a chance to sit down and look
at the recommendation and the peps and have a discussion, including calling Guido in personally
at least two times to talk directly to the Steering Council to help us understand where
he was coming from.
Like, this was not a snap decision, but everyone acts like it was.
Right.
This is literally taking over half.
It finally appears on their radar, and they're like, oh, where'd this come from?
Exactly.
Oh, it's like on Hacker News today.
Suddenly it happened.
Like, no, no, no.
This has been happening.
This has been in discussion actively in public for six months.
I first heard Guido talking with someone at a language summit in 2018 about the idea of
pattern matching.
Like, this has been on people's radar as something people have wanted for that long.
And I'll fully admit I wanted it.
Like, pattern matching is something I've wanted for a long time.
But it's just one of these things, once again, people just don't stop and think about the
time and effort that go into all this behind the scenes.
It's just, in my worldview, this just happened versus, oh, there's probably stuff that happened
that I'm just not aware of.
And specifically about this, one thing I always notice about this is people need to understand
the way the language is designed, right?
Like, we aim to increase your productivity.
Now, that means different things to different people.
But in general, it means keeping a language that's easy to understand and small enough to
have in your head, but also leads to you being more productive, which also means readability,
right?
There's a lot of side effects that we all appreciate that come with productivity, but that's
really the ultimate goal to me.
It's not that the language is readable.
Readable makes you productive.
And for pattern matching, there are certain algorithms that are just really difficult
to do without pattern matching, right?
Like the classic examples are parsers and compilers.
And they're not easy to do without having pattern matching.
There's a reason why functional programming languages that have had pattern matching for
a very long time are the best places right now to typically write a parser or compiler because
it just, the algorithm just works so much better that way.
So there were reasons why we brought this in.
There will be increases in productivity for some people.
We do realize that it is a big lift, but we also realize not everyone's going to see this
day one, right?
This is not, it is way more than a switch statement, which I know a lot of people typically look at
it as, right?
But the key point is it matches on structure.
It's not a mat.
It's not matching necessarily just on value, right?
This is the big difference between an if statement versus not.
And so there was a lot of work behind this.
So there are reasons.
Like this was not major.
The other thing I keep seeing about this is people going, oh, this is not Pythonic.
Well, I hate to break it to people.
Well, it is now.
Yeah, I hate to break it to people, but Guido Van Rossum, the creator of Python, and that's
probably the harbinger of what is Pythonic, is a co-author and a big pusher of this pep,
right?
Like Guido helped make this happen.
So unless you want to go up to him at PyCon and tell Guido that he doesn't know what's Pythonic
or what's not, I think we kind of just have to go with it that this is now what is considered
Pythonic.
And I will say, I have seen people say, oh my God, this is what happens when we lose the
BDFL.
Like the person who was the BDFL made this happen, right?
Yeah, it's not that.
It's not a really funny disconnect with people.
Like Guido drove this.
Like Guido talked to the steering council about this.
Like he was the point person for this.
Like he really helped make this happen.
So it's as Pythonic as it can be if you consider Guido the creator and head person in terms of
the design of the language, which I will fully admit I still do.
I kind of view Guido no longer as being BDFL.
It's kind of, he relinquished bureaucratic overhead costs in his life of the language.
And the steering council has more or less taken that on.
But I still trust Guido's gut more or less.
Like if he really went off the rails, we'd stop him.
But I don't think this is him going off the rails.
I think this is us going like, he's that one step ahead of us.
Yeah.
And Echelion says, I just wrote a horrible if LF statement and he's looking forward to pattern
matching.
Yeah.
I mean, there are some real places where I think there's going to be benefits to ways to structure
things that will just make things look better.
Yeah.
And Magnus says, agrees with me, that Python's full spectrum language and it just extends
that spectrum.
Yeah.
Right.
Yeah.
Thanks for that, Magnus.
It's one of these things I think some people lose track of that being beginner friendly does
not mean only for beginners.
And that's where this productivity thing comes in.
I think that's actually a huge part of Python's success, right?
Visual Basic 6 was awesome for beginners, for example.
But it just stopped.
Like, well, you can't do that here.
You're at the limit.
I'm sorry.
No, I don't want to be at the limit.
I want to learn C++.
Don't make me.
Hey, if you want to be beginner friendly, go code and scratch.
Right?
Yeah.
No one wants the right production code and scratch.
It's great to get going, but there's a limit.
Yeah.
One of the, one of the great quotes that I've heard that I think applies to Python is that
you can, you can do easy things simply, but you can do difficult, difficult things are
possible.
And I know I got that quote wrong, but it's definitely close enough that I'll just go with
it.
Like that is very true.
Like that is the goal here is to make the common things easy and simple.
And make, and definitely approachable and make the hard things at least possible.
And this is part of it.
This opens up the possibility for things that were really difficult to do in Python before
it.
Yeah.
Fantastic.
So, yeah.
So I'm thinking of doing a blog post about this whole rant called the social contract of
open source to try to harp on this whole shoot versus need.
And just, it's okay.
It's, it's, it, I start to criticism is totally acceptable.
It's just be understanding about how you're delivering it because we're all on the internet.
We do here and they indirectly you will suffer because guess what?
That project you're using is going to then suffer based on what you say.
So it does matter.
Yeah.
And just one aside, I think last podcast, Michael said this was influenced from Haskell is actually
the design comes a lot from Scala specifically for this.
But we got this comprehensions from Scala.
So we have actually gotten some nice things out of Scala.
Interesting.
Yeah.
Okay.
Very interesting.
Yeah.
I mean, my feeling is it's, it's a big step.
I think it's going to take some, take a while to really see the value of it.
If you're not working directly in a place where it's one of these algorithms that applies
a lot, but I think it'll be good.
Yeah.
It's definitely one of those things that when you see it for the first time, if you, if you're
not used to using like a language, like most functional languages that have pattern matching,
it just goes like, what?
Why?
Yeah.
And then when, when you get exposed to it, when you start to use it more, it starts much
like learning another programming language.
It starts to tweak your approach to certain algorithms and stuff.
And it's just, it's another tool in your toolbox.
Really?
Nice.
Well, Brian, you've got the follow-up, huh?
Yeah.
So I'm actually, that's why I thought this would be good as a, as a follow-up.
So Guido announced that he wrote the introduction to pattern matching and, and that it's, it's
now part of, it's part of an appendix A of PEP 636.
So I went off and looked at it and it actually really helped me a lot.
So this, this introduction kind of, I actually, I've been trying to follow this PEP and honestly
been confused for a while as to like exactly how it's working.
A lot of people have been focusing on the weird parts, but the easy parts actually are
really nice.
So I really, the, the, there's an example that it starts off with that kind of looks like
a switch statement, right?
So it's a, I want to match a status and like an HTTP status.
And then I do something different based on 400 or 404 or 418.
And then, and then of course we're like, well, what, what about default?
Right?
So there's going to be some sort of fall through that I handle all the other cases.
And there's an example of that.
And I was actually curious, the example here shows using the, just the single underscore
variable, magic variable as a, as, as a catch all.
And so Brett, I was just curious, can I use any variable here or does it need to be the
single underscore?
Do you know?
So I was actually going to come on at this when you were done.
Um, so the underscore actually has some special semantics here because, in most, most
languages that have pattern matching, the underscore represents the wild card.
Um, this has actually been one of the most controversial parts of peps 634 was the selection of this to
stay consistent with other languages.
Um, while I will not suggest to people that there's an opportunity to remove pattern matching
or to necessarily have massive changes to it.
One of the things that if people try this out in real world code and can get feedback to
us well before beta one locks in and gets released.
Cause that's our cutoff, for feature changes, for Python 3.10, which will be in
May.
Uh, this is one of those areas where we could, we could actually consider changing, right?
Like fixing up code to change this case, wild card syntax of an underscore to something
else is totally possible.
If we got feedback from the community that, yeah, this really was a nasty sticking point and
really didn't work out well.
So I do want to say that there is still a chance to potentially influence the final outcome
of how the exact exact thing is.
Although I don't want to suggest that because it's not shipped in 3.10 yet, right?
It's exactly.
It's not shipped in 3.10 yet.
Uh, so we can tweak if necessary, but don't come out.
I wouldn't suggest people come out and try to completely rewrite the entire syntax.
But in this specific case, yes, it is special.
Uh, yes, some people don't like it.
And if enough people really came forward and really said, this is the one thing I'd want to
tweak.
We, I think we'd be open to considering.
Well, the underscore gets used so much for so many interesting things.
Like why not one more?
Make it.
I'm okay.
I personally, I don't care.
I just want to know what it is.
Um, I mean, I didn't like, I didn't like spaces instead of braces when I first hit it.
So, anyway, but what happens if I put it like X there instead of a underscore?
If you put X, so the rules here basically are, if you put a single name that has no dot in
it, it's a binding.
If you put a name there with a dot, it will be a binding.
Now, this is one of the things that I learned from Guido in one of our meetings that really
helped clarify this for me.
And one of the reasons I ended up, voting to accept this was let's look at the, like,
consider these cases, right?
Return codes.
You're probably not going to hard code 400 and 404 and 14.
You're going to import the HTTP dot status module and you're going to specify the constants
from there, right?
Yeah.
Do you really want to rebind those constants by accident in your code?
Oh no.
No, but because it's been imported from a module or off a class, for instance, you're not going
to be wanting to do assignment.
You're just going to want to reference it.
So if there's a dot in the name, it automatically is just a reference.
Now, some people get really hung up on that when they think about the single binding of
a name, understandably.
But here's the thing is, well, this is a case right now where if you had just a bare
name, that's a bind where if there's a dot in it, it's actually going to be a reference
and a load to do a value check.
There is a potential in the future.
If people come back after trying out the PEP and having experience with pattern matching
to add to the language, a leading dot, which is actually used in Swift, by the way, in the
Swift community for something else.
But the key point is we can make it like a dot X to act as a load for comparison for
a local name.
That's an interesting syntactical use.
Like it's not actually coming from anywhere, but treat it as if it were.
Exactly.
Now, this was originally in the PEP and there was massive pushback from people thinking
that they would totally miss the dot.
But Corey Benfield, who used to run requests and all that and has multiple talks from PyCon,
a person who helped me start pushing sans IO development of libraries in the community.
He works at Apple now on Swift stuff and he posted something on Twitter and I asked him
like, hey, does that leading dot have any problems with Swift?
And they said, actually, the whole community is totally fine with it.
There's no readability problems.
It just totally works.
So we could potentially in the next version of Python actually make it so that that that
have it a dot in the name, whether it's just leading or not.
We could actually generalize that.
But because it's a forward compatible thing and backwards compatible, we decided not to
do that in this path and just try to just keep it simple, simple, keep it simpler than
it had to be necessary to go out and then add an opportunity.
So if I just put a bare X, it's going, will it hit it and will it bind to it and assign
the value to X?
Yes.
Okay.
Actually, that's what I expected because as I go down this little tutorial, it talks about
like, un pattern, like unpacking, which is totally cool.
So let's say you have a, like a, the example is a point object, which is like just an XY tuple.
Um, now I want to be able to, if I, in the case statements are, you know, specific points
that you're going to match to, or like, let's say you don't care what X is, but you, you want
to fix Y at zero in, in the case, in the case block, you want to know what the value of X
was.
So you do want that binding.
And that's, that's really just cool.
I just, I can't wait to play with this.
So my, my follow-up question, I'm glad you showed up here is when can I play with this?
Is this in one of the alphas now or betas?
Or do you know?
I don't, there is, I don't know if it's, I don't think it's landed yet.
Um, Bram Butcher, who's one of the coauthors of the PEP has a working implementation already,
which was, which is actually available in a Jupyter was available in a Jupyter notebook
somewhere.
Um, so there's definitely a fork somewhere where you can try this out.
Okay.
Um, but I don't, this is not landed in mainline, so it's not out in an alpha quite yet.
Okay.
Um, one thing I did want to point out about this, that's really kind of cool.
Um, with the example that Brian's showing here, right, is the match against a point argument,
as you said, that takes a two item tuple, right?
You could actually change this to also accept a single item tuple that represented X and Y
with the same value.
And that would totally match separately as well.
Right?
So once again, this is matching against structure.
So you could actually pass in tuples of different sizes and have it automatically just kind of
maybe do something different with 2d or 3d.
Yeah, exactly.
So because it's a structural thing and not a value thing, it opens those very interesting
doors.
Cool.
Interesting.
Yeah.
Cool.
It's really great to have you here to talk about all this stuff.
Uh, final comment, close this one out.
I guess, Zdoc says, I think, once good syntax highlighting lands, this will be as
natural as less comprehension.
Yeah.
And that's actually a good point.
One of the things, we had discussed was like the, the leading dot would, how hard would
that be to see with or without syntax highlighting?
And we realized that honestly, syntax highlighting will probably do it.
One thing some people were a little worried about was the reason this is even possible was
because of the new parser that landed in Python 3.9, the, new PGM parser.
Uh, it can do more contextualized parsing.
So that match, for instance, isn't going to suddenly make all your match keywords or the match
method on from the re module on match objects suddenly not work.
Uh, it contextually can tell that that match keyword is for a match statement.
So there might be a little funky coloring for some people based on how your syntax highlighting
works.
Like you might suddenly have all your match methods highlighted like it was the match keyword,
but honestly it'll be from, from, from what you're looking at in terms of the code,
it's going to be fairly obvious.
That is not a match statement.
So we weren't too worried about that kind of, haziness as it were, when it comes to
syntax.
Yeah.
No, this is cool.
I know a guy on the VS Code team.
So yeah, so do I.
You see him every morning in the mirror.
A quick plug and thank you to magic Python, which comes from, the magic Python team,
uh, magic stack, the people who do edge DB.
They actually maintain, the syntax highlighting, that we use in VS Code, as well as
I think is using sublime text and Adam, like they have a generic grammar that they use that
they just auto gen out to, various editors for their syntax, mostly text mate, format,
but, kudos to them for always maintaining that, syntax highlighting.
Cause that's actually what VS Code itself ships in the box.
That's awesome.
Yeah.
Nice.
Brian, I don't have any extras.
Do you?
I don't know.
Right.
Anything else you want to throw out there before we, make a bad joke?
No, just thanks for having me on.
Thank you for everyone listening to me rant on about, how to please try to, talk
to maintainers that help them keep their sanity.
And, that's it.
I hope, I hope people give the Python launcher a shot and it works for them.
Yeah.
That's very exciting.
Let me know.
I can't make any promises about it shipping specifically with Python, but at least it's a
tool there that I find useful.
I hope others do as well.
Cool.
I'll definitely check that one out.
All right.
You guys ready for the joke?
Uh, you know, we're.
We're all stuck at home.
And especially if you're single, it's, it's really tricky to, to get out and meet people
and you know, whatnot.
See, see what's going to make you happy.
So I got a joke along those lines to kind of help people out there.
Ready?
All right.
So there's this tweet by Christian, zoo says, if you're not happy, single, you won't
be happy in a relationship.
I mean, we've all heard this, how important it is to be just like content with yourself.
She says, no, true happiness comes from closing 100 Chrome tabs after solving an obscure
programming bug, not from other people.
Come on.
Yeah.
Anyway, I thought that was good.
And Kiki.
Are you, are you two the type of folk who have like a bazillion tabs open at any one time?
Or are you more like only keep open exactly what I'm working on.
And as soon as I'm done, I close them.
I am not a hundred tab person, but what I do sometimes I'll like leave the tabs open.
Like, oh, I'm not done with this.
And so I'll close it.
If I got to reboot the computer, the first thing I do is reopen the browser and say history
restore previous session.
Cause I'm like, there were things in there.
I don't know what I was doing, but I know they're important.
So I may abuse that a little bit.
I, my daughter came to me once and said, I need dad like finals.
And then my laptop is too slow.
I need a new laptop.
Like, okay, well, let's talk about what you're doing.
Well, she was doing like three research projects and had like a hundred tabs open.
I'm like, well, let's just try this first.
Can I, can I tell you about this cool thing called bookmarks?
And anyway, totally fixed it.
So yeah, that's awesome.
Hipster dad showing bookmarks to the youngsters.
Yeah.
Magnus says the number of tabs is a measure of how hard the problem is.
And Niels says a great rant.
Love your work, Brett.
Great to have you on the show, Brett.
Always happy to be on.
Thanks for being here.
Thanks to everyone.
Brian.
Thank you.
Thanks as always.