Transcript #251: A 95% complete episode (wait for it)

00:00 Hey there, thanks for listening. Before we jump into this episode, I just want to remind you

00:03 that this episode is brought to you by us over at Talk Python Training and Brian through his pytest

00:09 book. So if you want to get hands-on and learn something with Python, be sure to consider our

00:14 courses over at Talk Python Training. Visit them via pythonbytes.fm/courses. And if you're

00:21 looking to do testing and get better with pytest, check out Brian's book at pythonbytes.fm slash

00:27 pytest. Enjoy the episode. Hello and welcome to Python Bytes, where we deliver Python news and

00:32 headlines directly to your earbuds. This is episode 251, recorded September 22nd? Wow. 2021. I am

00:40 Brian Okken. I'm Michael Kennedy. And I'm Brett Cannon. So do we need to introduce Brett? I mean,

00:45 thanks for being on the show, Brett. Welcome back. We can introduce my cat, Gidget, for all those on

00:50 the live stream, because she's in frame at the moment, just lounging around on a nice, comfy

00:54 blanket. Actually from Google, from when I won an open source peer bonus. You won your way

01:02 more information than anyone probably cared, but there you go. Nice. Yeah, my dog is around

01:07 here somewhere, but probably won't show up and screen. Well, let's just get started. I think

01:12 if people don't know Brett, they need to get out from under a rock. So yeah, absolutely. Live chat

01:19 real quick. Brandon, Brainerd, thanks. They gave you a cat? No. Yeah. There's a long story

01:25 about how he got Gidget, but no. Cat did not come with a blanket. Nice. So the first thing that I want

01:33 to talk about comes to us from, this is both recommended and created by Dan Lutik. So Dan,

01:39 nice work. I love these little tools that you can run against your code that will just reformat them to

01:46 be better. You know, one of the, probably the most popular and well-known one is black, right? We've

01:50 all heard of black, which is great. But there's other ones like Flint, F-L-Y-N-T is one of my favorites

01:58 that converts all the various string formattings to F-strings, which is great. So here's another one

02:03 around typing called auto-optional. And Brett, I think people maybe are using optional a little bit

02:09 wrong in the typing space in Python. What do you think? Or just not using it when they should be.

02:14 Yeah. That's definitely a thing that was actually, I think, discussed early on about, do we even need

02:21 to have the concept of optional to represent, Hey, this thing can be whatever the type is or none.

02:26 And what was the thinking there? Because, you know, languages like C-sharp, Java, C++, you can have a

02:32 thing and then it can be null. And C-sharp, there's value types, but generally most things are pointers and

02:37 they can be set to null. And you don't have to have some kind of a special type to say it's

02:41 either a user or it's null. You just say it's a user because it could be a reference type,

02:45 but also it could be null or nil or whatever. But Swift and Python have this concept of you must

02:51 explicitly say that it could not have a value.

02:54 Oh, so explicit is better than implicit, as we all know. The other thing is obviously

03:00 having none accidentally sneak in when you don't want it. As you mentioned, Michael, Swift specifically

03:06 does not let you have null. You can't have null references. You have to either declare that it

03:12 will accept null and you have to check or it won't take it at all. And it's a similar thing here. No one

03:16 likes it when they actually find out, oh, the null type's not callable because you accidentally pass

03:20 null.

03:20 What's the most common exception type is attribute or type attribute. None has no attribute, whatever the

03:28 thing is you're trying to access, right? That thing?

03:30 Yeah, I'm willing to bet. Yeah, that attribute error alone, it probably makes up like a huge portion of

03:34 people's exceptions. So that's why you have to be explicit. Like you need if you're going to be running a type checker,

03:39 let's be very explicit about what you do and don't expect.

03:42 Yeah, cool. I agree with that. I think it's nice. It did surprise me at first, but then I'm like, oh, okay, well,

03:47 that's a that's an interesting choice. But now that I know, I should use optional. So here's a case of a function.

03:53 And it's just some food bar example, but they have a bar parameter and they say colon stir equals none.

04:00 So they're giving it a default value and saying it can be a string. Well, obviously that is like in three,

04:07 three words patently wrong, right? It can't both be a string and be set to be none because it,

04:12 you know, strings and type system can't be none. They have to, that has to be optional. Right.

04:17 And so that, except for all of us know what that means. I know we all know that. Well,

04:21 so funny enough, you know what it means, but if you didn't write that, do you know what they actually

04:26 meant? Right. Like if Michael typed that and you saw it, would you go, Michael meant for that to

04:31 actually be optional and that's nullable in terms of what, how other languages write it or was that on

04:37 purpose? And that's why that's not allowed is because you don't know who screwed up. If anyone,

04:43 was that accidentally written that way and it weirdly was meant to be optional or was it on

04:48 purpose? And thus it's listed that way because you don't know intent of someone else who wrote it.

04:53 This is why we went with the explicit where you have to label something as optional.

04:57 And this is why it's awesome to have core developers on the show.

04:59 So, so the idea of this is it's a thing you install, but then you pip install it, but then

05:06 you just run it on the CLI like Flint and you just point it at a directory and it will go through

05:11 and it'll find all of these default values that are none, but don't have optional in their type

05:15 information. And then it'll just add optional, which is pretty straightforward, but you know,

05:20 it's so easy to use, right? It's like, Oh, I have this 20,000 lines of Python code. And I really wish

05:25 they were f-strings like Flint, that folder it's done. So same thing here, right? It's I've,

05:31 I've got this huge bunch of code and nobody really thought about optional. Let's just quick fix that.

05:35 It doesn't fix it everywhere. Right? Like I could say a thing takes a string without a default value

05:41 for the parameter. And then maybe it's somewhere else that's getting a none. And it's not like that

05:46 advanced. It just looks, if you're having default values that don't match the type, make them match.

05:50 Yeah. so I like it. one of the questions I have is, so if I do optional string equals none,

05:57 does that mean I still can pass none to the, to the function? Yes. Cause it's no different.

06:04 That is normal. Okay. But wouldn't that be the same as saying that I can pass stir or none?

06:09 Yes. Yes. And also that's what, on the live stream, Will McGuggan, Hey, Will says,

06:16 do you need optional now that we can have foo pipe none as a, an alternative to optional of foo?

06:23 No, but this is sort of more backwards compatible, right? Like Brett, when did that come out? Is

06:27 that three, nine? three, 10, I think three, 10. Yeah. So, so it's not even out yet officially

06:32 next month. Yeah. So give it, give it a little over a week. Right on. That's exciting. But you know,

06:38 how, how much backwards compatibility do you want? Right. So I think soon, but maybe I don't know if I

06:43 would go yet. And then Chris may says, oops, opening PyCharm to add optional to my last project.

06:48 before you go to the work to write it, just run this against it on the CLI, on the command

06:53 line and just see how it works. Right. So yeah. So it also works in VS Code. Although Zdocs does say

07:00 back in three seven, you can use from Dunder future import annotations and then get that to work. I

07:05 don't know about that personally, Brett. So what Zdocs is suggesting here is if you use the from Dunder

07:12 future import annotations, what that does is it turns all your annotations technically into strings

07:17 to Python. And so it's actually not executed because before that, what actually happened was,

07:21 is that code in your annotation actually got run and the resulting object cut bound to the code object.

07:29 What that future import does is just says, no, no, we don't want to pay that overhead, on your

07:34 import. You might have performance reasons. Don't do that. And it'll actually just become a string.

07:39 And then we have some stuff, to try to resolve that at runtime. This is the whole thing that came up

07:44 in Python 310 that, you all covered in a previous episode of Pydantic going, Oh God,

07:50 there's a change coming in 310 that might break us. And there's a whole kerfuffle. And anyway,

07:54 that's what that's all resolving. So technically you're right that you could write it back,

08:00 but it would break complete expectations of everyone who ever tried to use your code when you tried to run

08:06 that somewhere else. So I would advise against it unless you know, you're going to be working against

08:11 310 because for instance, someone might write code for Python 3.7 or 3.8, tell my pie it's Python 3.8.

08:18 And then it would error out saying, well, that like that syntax makes no sense.

08:21 Right. Okay. Interesting. All right. Well, yeah, pretty good one.

08:25 Pretty good one. super easy to use, not a whole lot to it, but I think it's because it's so easy to adopt.

08:30 It's kind of a nice one. yeah. Well, I want to talk about something that's not easy. It's not easy to write good documentation.

08:37 So there's an article, from Daniel Stenberg and this doesn't apply to just, Python stuff. This applies to every software, all software stuff.

08:47 there's an article called making world-class docs takes effort. And I think it's an understatement. It takes a lot of effort.

08:55 but there's, this is a nice little doc, project or article talks about, he's, he's got some gold, gold things that he looks for to get a gold star.

09:06 You must have these six items in your documentation. So let's just talk about what, what he's looking for. first of all, the documentation should be in the repositories, the code. I've got mixed feelings about this, but in general, I'm on the side of, this is a good idea just to keep the code and the docs together.

09:23 The only reason why I sometimes find it difficult is when is I'm updating my documentation possibly way more than I'm updating my code. And it looks like there's a lot of turn on the code when there's not. So I don't know. but generally I think that's a good idea.

09:39 Yeah. Most, most projects have the reverse, right? Like the documentations were edited that was edited two years ago, but there's been changes continuously. Right. Like, I don't even know if they still apply, but.

09:48 Yeah. Yeah. But it is good to try to keep these together. Also, you can make a pull request or a merge request be with both the documentation and the code together. And, and so that's a good reason for that. next up is that your docs are not extracted from code. And I know there's a lot of tools out there that can try to do this, but the comment is just think about your favorite project documentation. Is any of it generated from code and odds are not. So, yeah, I, I agree with this.

10:18 Yeah. You can usually spot it because it'll be like method login user. And then the, the method, the, the comment will be logs in user.

10:25 And you're like, honestly, I've seen the reverse too, where people have doc strings that are extremely verbose and take up pages in your terminal just to scroll through.

10:37 And because they just use that to spit out your docs, in which case it's not as convenient as when you just run help from a ripple to just go like, I was this do again.

10:44 What are the arguments? Like, I need a really clear point pointed thing directly at a developer who's just trying to double check something versus a whole ex exposition of here.

10:53 All the examples of how to use this thing. It's like, I don't need that level of detail. I just need to remember one little thing.

10:58 Right. Right. Right. Yeah. It's, it's a range. Is it inclusive or exclusive of the bound? Like something like that. Right.

11:03 One thing's the one place where I'm, I'm working on, I've got a project to try to use auto-generated documentation is I've got a really large test suite on a project.

11:13 I'm shocked. Absolutely shocked, Brian.

11:16 That I would really like to have doc strings, the encouraged developers to put doc strings in there for the reason why the test exists and what feature it's really testing.

11:25 And to be able to have an auto-generated light, like website with just all of our tests, that'd be cool, but I'm not there yet.

11:33 That makes sense.

11:34 The next thing is your docs feature examples.

11:38 And I love this because that's what people want to know.

11:42 If I, if I want to do this, how do I do it?

11:44 And so the comment is really just use examples.

11:48 If you already have examples, add more.

11:49 You probably can't have too many examples.

11:52 And test them.

11:54 Oh yeah.

11:55 Test the examples.

11:56 We covered a tool called make doc test that you could use to test your code within your documentation.

12:03 Use that.

12:04 Next is your doc, your document, document every API call you provide.

12:09 This one's a tough one to keep up on, but it's really important.

12:12 Even some great projects like typer and stuff that I've used not to, not to bash typer, but I think all projects have this problem.

12:21 They'll add a new cool feature and it's cool.

12:23 I want to use it and it's not in the docs yet.

12:25 So that's a tough one to keep up on, but please do.

12:29 One thing I'll say that is actually hard for Python is because it's so dynamic.

12:33 It's hard to actually get a static list of all the API points.

12:37 But one thing I'll say because Paul Everett says I have to bring more Rust to this podcast.

12:42 Docs.rs, which is auto-generated documentation for anything uploaded to crates.io for Rust tools, will actually give you a percentage of covered public APIs.

12:53 So you can actually see how much coverage you have in your documentation.

12:56 So that's an interesting definition of code coverage.

13:01 Yeah, it is, right?

13:01 But it's like I didn't even know about it.

13:03 And then I found it when I was just double-checking that everything built okay for a project I will mention later in my extras, extras, extras.

13:10 And I noticed it was 100%.

13:11 I was like, I thought I covered everything.

13:12 And I went back.

13:13 I was like, nope, there were actually a couple enum values that I didn't document.

13:18 And so I was able to go back, do that, and make sure I had full 100% coverage of my stuff.

13:21 It can be handy.

13:23 But yeah, it's tricky in Python, right?

13:25 Where it's like I could auto-gen my whole API and no way to know whether I covered it or not.

13:30 At runtime and never have it hit disk, yeah.

13:31 Yeah.

13:32 Last couple things.

13:34 Docs should be easily accessible and browsed.

13:38 And hopefully a search feature or something, even if you attach Google search.

13:44 That's cool.

13:44 But there was a comment in the text also to say, preferably be able to have that online.

13:52 So offline is what the comment is.

13:55 So if it's, and I'm on the fence on that.

13:58 I'm usually attached to the internet.

14:00 So looking stuff up isn't a bad thing.

14:02 And easy to contribute to, the lastly.

14:05 So yeah, documentation stuff.

14:08 There's a lot of stuff.

14:10 It's hard to get it right.

14:11 There's a lot of stuff I'd add if I was being more verbose.

14:14 But the last thing I really want to add to this is don't slam projects that don't have good documentation.

14:20 Because it's hard.

14:21 If you want to have it be better, then contribute.

14:24 Fix it yourself.

14:25 Yeah.

14:26 Brian, you're kind of blowing up the audience out here with the comments.

14:29 So I'll throw a few out that seem interesting.

14:30 Sam out there says, pro tip, keep on top of your documentation, even if it's just a cursory

14:35 doc string.

14:35 Some notes.

14:36 Otherwise, it quickly gets out of hand.

14:38 Yeah, it's definitely one of those things that if you had to sit down and write it all at

14:41 once, it would be dreadful.

14:42 But if you can kind of do little bits as you go, then for sure.

14:45 Right.

14:46 Brandon Brainer says your documentation update should be part of the ticket or even better,

14:51 your definition of done for the ticket.

14:53 Right.

14:53 Like when you estimate how much work in your sprint or something.

14:56 And then Chris has a great one.

14:58 Bonus documentation.

14:59 If a bonus, if your documentation includes animated gifts or emojis.

15:04 Yes.

15:06 Yeah, those are awesome.

15:07 We'll probably leave it there for that one.

15:08 But that's great.

15:09 All right.

15:09 So one interesting thing you could actually do is if you really want to push this is if

15:15 you keep your documentation in the same repository as your code, you could.

15:18 I'm going to use this from GitHub.

15:20 I'm sure GitHub has equivalents.

15:22 But you could probably set up a GitHub action.

15:24 Actually, I know you can because I've written the GitHub action to do this to actually have

15:28 your checks, your status checks on your PR fail if there are no touch docs and have

15:35 to have to opt out of that check.

15:37 Right.

15:37 I actually have a GitHub action I wrote called check for change files.

15:42 And you could write a requirement saying if you change any .py file, an equivalent .rst

15:48 or .md file must be changed somewhere in the PR.

15:51 And if it's not, have to add like a skip docs labeled to make it pass and otherwise let people

15:56 know very explicitly.

15:57 OK, we care about our docs.

15:59 You can't just opt out of it.

16:00 Please make sure everything's up to date.

16:03 There are ways to really push this pretty far if you really want to go for it.

16:06 Yeah.

16:06 Have robots be mean and say, no, you haven't finished your PR yet rather than the maintainers.

16:12 Yeah.

16:12 All right.

16:13 Tell us about this next one, Brett.

16:15 Yeah.

16:16 So once again, more rust on this podcast due to Paul Everett demanding it.

16:20 And I've noticed there's been a slight theme the last couple episodes of talking about ways

16:24 to kind of improve your shell and your general development flow, as it were.

16:28 And one thing I use here, and partially because Michael's mentioned Oh My Posh multiple times,

16:33 I believe Brian's now mentioned Oh My Zeesh.

16:35 I thought I'd just mention what I use for All My Prompts, which is Starship.

16:39 The thing I love about this is it's actually cross shell.

16:43 So what you do is basically you define, it comes with a lot of basically plugins for configuring

16:51 built in.

16:52 And what you do is you basically turn them on and off, configuring one way or the other.

16:56 And then there's a one line activation you just put in your code.

17:00 And that's it.

17:01 Configuration is done by a TML file, Starship.TML.

17:05 And then it just works.

17:06 There's no mucking about.

17:08 It doesn't matter what shell you're on.

17:11 And it just does its thing.

17:13 And the reason I really appreciate that is I'm one of these people who likes to play with

17:16 tools, right?

17:17 Which leads to me playing with different shells, right?

17:20 Probably by the time Paul Everett tries out fish, I'll be trying out new shell.

17:24 So because of that, I want to make sure that I can bring my shell with me very easily.

17:29 And Starship, for instance, has support for fish and Zeesh and Bash and all of them and new

17:33 shell.

17:33 So I can very easily try out a different shell and not feel like I'm in a foreign country

17:39 where the prompting is gibberish, right?

17:42 Like I always hate it.

17:42 It seems like, oh, my Z shell go on to Z shell and oh, my posh go on to posh.

17:48 And like you're stuck on that specific one, right?

17:51 Exactly.

17:52 And there's oh, my fish.

17:53 Like pretty much every shell has an oh, my something or other to tweak it out.

17:56 But with this, at least for my prompt, which is actually what I see the most, right?

18:00 Like I don't know about the rest of you, but my prompt is what I interact with.

18:03 More than anything in my shell, not the extra fancy stuff I put in.

18:06 It's this.

18:07 And so this is why I really appreciate this project.

18:10 I will also.

18:11 Yeah, go ahead.

18:12 I did.

18:13 Go for it.

18:14 It's just.

18:14 Well, what I like is we're seeing on the screen here.

18:17 If you go to the starship.rs site, you can see like a little animated GIF and props to

18:22 them for putting that on there.

18:23 That is fantastic.

18:24 As we just learned, it's good documentation.

18:26 Yes.

18:27 There's a lot of stuff about if you're in a GitHub branch and what branch you're on and

18:34 versioning and things.

18:35 Does it have specific stuff for Python and Python virtual environments and versioning like that?

18:40 Yes, because I don't use it, but there's built in PyPI support.

18:44 But if you use the Python launcher, I actually have an entry on it in the FAQ for the Python

18:49 launcher to tell how to use the Python launcher to automatically tell you what version of Python

18:54 is being used.

18:54 And then you can configure the Python configuration to say, what should I trigger on for it to be

19:00 considered a Python project?

19:01 And it has a default list that's pretty good, like pyproject.tom, setup.py, setup.cfg.

19:06 The things you would expect any repo or workspace or whatever to have to be a clear marker that

19:13 there is Python that I care about here.

19:15 And then the other thing is, is there's also a way that if you use PY, you can also have it set up to

19:21 auto trigger as long as you just have like a .vemv directory, for instance, that contains your

19:26 virtual environment.

19:27 And then if you happen to use the Python launcher to be the way to query for what version of Python

19:32 it is, it all magically just tells you what version your virtual environment is in.

19:36 And so I actually use this with the Python launcher because it will always tell me exactly what will

19:40 happen if I just type py.

19:41 Oh, nice.

19:43 Yeah.

19:43 Yeah, that's awesome.

19:44 And I know nerd fonts have been mentioned previously on this podcast.

19:48 You'll notice that it has nerd font support.

19:51 So if you get that installed, there's extra little fancy bits to it.

19:54 You don't have to have it installed while those things will either turn into Mojibake or you can

20:00 just turn them off.

20:00 Yeah.

20:01 But there's all sorts of stuff that this thing does.

20:03 There's even real nice little subtle details.

20:05 Like if you use Starship and if you're watching the live stream, you'll notice that the prompt

20:10 is green when the last command succeeded.

20:13 But if it fails, it turns red.

20:15 Like there's real nice little subtle touches of this tool that I really appreciate.

20:19 Yeah.

20:20 I really like it too.

20:21 It looks great.

20:21 I'm going to try to check this out because I'm I'm always using I got some tools that

20:26 I have to run from the the command prompt.

20:28 And but most of the time I'm in bash or something else.

20:32 So, yeah.

20:32 Yeah.

20:33 Very nice.

20:33 Zdocs says using multiline shell prompts and FZF are two of the better productivity improvements

20:41 I've ever done.

20:42 I I wanted I've highlighted that specifically because I really like these multiline prompts

20:47 that has all the details and then the prompt is below it.

20:50 But I can't bring myself to use them yet.

20:52 I don't know why I've just it's I'd rather have it more densely packed on one line.

20:57 Where do you stand on this?

20:59 I used to be that way.

21:00 Actually, I I used to be a Z user before I became a fish user.

21:05 And even before this, I used to use left prompt and right prompt.

21:08 And I had a consistent left prompt, which was basically just the greater than symbol.

21:13 And then I had my current working directory as my right prompt so that at least the cursor

21:18 position never shifted.

21:20 Like, I don't know about the rest of you, but I always find that that they're joking

21:22 nuts.

21:23 Like, where's the start of my prompt now after I changed my directory?

21:26 So having that as the right side was great.

21:28 But then I saw this and I was like, OK, I've never loved this, but this is so nice and set

21:34 up across the board for everything that I consistently use, like Rust, Python, NPM, whatever.

21:42 I was like, OK, I'm going to give it a shot.

21:43 And I did it and I've stuck with it and I continue to like it.

21:46 So I totally hear where you're coming from in terms of the density level.

21:49 But it's just turned out to be way too nice with Starship for me to care about going back.

21:55 Now, if I do go back, right, and I don't have it set up for this, I actually have like my

22:01 .files set up so that my default basher, so you know that if I end up on a random machine,

22:05 at least has that kind of prompting.

22:08 But as soon as I'm on any machine where I know I'm going to be a fully set up environment,

22:13 I just kick on Starship.

22:14 I just don't care.

22:15 I basically I get it.

22:17 But this was just too many benefits and I just let it go.

22:20 And now I just don't notice it.

22:21 Yeah.

22:22 And now you're used to it.

22:23 Right.

22:23 I think I'm going to try to embrace it.

22:25 Just just run with it.

22:26 And honestly, the resolution on all our screens are so high now compared to what it used to

22:31 be back when I picked up that habit that the lack of vertical density, maybe it's because

22:35 I'm a black user doesn't bother me so much anymore.

22:38 Yeah, that's true.

22:39 I do have a 4K monitor, I suppose that like a 32 inch 4K monitor.

22:43 I could probably fit the terminal on it.

22:44 I suspect so.

22:46 It's actually kind of nice to have the those like color stuff in your in the multi line prompt

22:53 to be able to kind of scroll up and see where the beginning of your line, your command started

22:59 because it's easier.

23:00 It's like an HR horizontal rule.

23:02 Yeah, exactly.

23:03 Or yeah.

23:04 Final thing, Jeremiah Page out there in live stream says Starship is great, but I think

23:08 you need nerd fonts for some of the plugins.

23:10 Hold that thought.

23:10 We'll be back to more nerd fonts later.

23:13 But that is correct.

23:14 Some of the things like if you're watching the live stream, there's a nice little symbol

23:18 for like a branch next to the get stuff.

23:20 If you have the power monitoring one that tells you like your battery is low, it uses nerd fonts

23:24 to show that.

23:25 But Michael's foreshadowing something coming later.

23:27 Yes, indeed.

23:28 All right.

23:29 Let's talk about James Path.

23:32 Now, Brian, one of the challenges we always have on the show is we have these acronyms for

23:36 packages and then we have to speak them.

23:39 And we've never spoken to the person who creates it or named it.

23:43 And so we always I'm sure we wreck the names of so many packages.

23:46 And let's just do a blanket apology.

23:48 But this one is called James Path.

23:50 And I know because it says J-M-E-S-P-A-T-H pronounced James Path allows you to like, yes,

23:59 this is another new thing I'm starting to really like allows you to declare to declaratively

24:04 specify how to extract elements from a JSON document.

24:07 So instead of going through and sort of going, you know, parsing up something as JSON, turning

24:13 to a dictionary and then traversing it with indexes and keys and such, there's a whole lot

24:18 of interesting things you can do to quickly get at elements.

24:22 So, for example, you can just if you had the dictionary that had key foo and then inside

24:29 there, there was another dictionary that had a key bar and then that had a value baz, you

24:34 could just say foo dot bar and it'll give you baz, which is kind of nice.

24:38 You can also do that with with arrays, although this is actually not doing anything.

24:43 It's just giving you back the list and then you're indexing into it.

24:47 So whatever.

24:48 But you can do things like star on it.

24:50 So, for example, if you had foo bar and then bar was an array, you can say like foo dot bar

24:56 a bracket star dot name and it'll give you all the names out of the sub thing, the sub dictionaries

25:03 in the list that bar points at.

25:06 So there's like these cool, like almost like SQL like things.

25:09 You can also do negative indexing into it, which is pretty nice.

25:13 You can do star like foo dot star dot name for hashes to get the values out kind of like

25:22 a set or something.

25:22 So that's pretty nice.

25:23 And yeah, it's pretty interesting.

25:25 This one comes to us from Josh Thurston.

25:29 So thanks for that.

25:31 He said he was working with all these sort of arbitrary nested JSON documents.

25:35 And it was really handy for that.

25:36 So, you know, you look at this code and I'm sure, Brett, you're thinking that's not Python, right?

25:40 No, actually, I'm wondering if the query syntax is the same as JQ.

25:45 And do people know what JQ is?

25:47 I don't know what JQ is.

25:48 Yeah.

25:48 Interesting.

25:49 So JQ is a command line tool.

25:53 So literally, it's just JQ, Juliet, Quebec, that is designed to actually take in JSON,

26:01 more or less use the same kind of syntax as the query selector and the browser for CSS selectors

26:07 and query your JSON.

26:08 I think it's meant a lot for like tools if you're using like HTTPY or curl or whatever to query

26:14 some like REST API that's going to give you back JSON and then to try to find something out of it.

26:18 And it looks pretty similar.

26:20 So I'm thinking that this is maybe kind of just a Python packaging approach to the same syntax,

26:25 which is neat because it means if you know one tool, hopefully it'll work for you.

26:28 Yeah, right.

26:29 Yeah, it could be.

26:30 So you should think of it not as syntax that you write, but more almost like a regular expression.

26:36 So you would import JamesPath and then you say expression equals JamesPath compile.

26:40 And then you give it a string, which is these things I've been describing.

26:43 And then you can tell it to like search or execute queries against things.

26:48 So a lot of neat stuff you can do there.

26:50 You can even add custom functions that can become part of this query syntax.

26:55 So if you create a class that derives from functions that comes out of that library,

26:59 you can have things like unique letters.

27:01 And what you could do in there is say, given a string, I would like to do a set on the string

27:07 and then turn it back into a string.

27:08 So it only shows you the letters involved, not necessarily, you know, with duplication.

27:14 Right.

27:14 And so then if you create that, then you can do things like when you do your search, you can do food out bar pipe, unique letters,

27:21 and you pass the parameters over.

27:23 And it'll give you, you know, basically the result of those values, but then applying these transforms and stuff to it.

27:29 Cool.

27:29 So, yeah, pretty neat.

27:31 You got a lot of traversing dictionaries and stuff like that, and you kind of want to treat them like SQL.

27:37 I feel like this is sort of along those lines.

27:40 People can check that out.

27:41 All right.

27:41 Brian, over to you.

27:43 Yeah.

27:44 I wanted to cover, this was announced last week, I think.

27:48 There's a tool called Pedalboard.

27:50 This is a library that comes from Spotify, and it's for manipulating audio files.

27:59 But in the introductory article, it says the power and speed and sound of a DAW.

28:07 I never knew how to pronounce that one either.

28:09 Digital, what is that?

28:11 Digital audio something.

28:13 Workstation.

28:13 Yeah, digital audio workstation.

28:15 A DAW, I think.

28:16 Maybe a DAW.

28:16 DAW.

28:17 I don't know.

28:18 So what do you use?

28:19 I use Logic Pro usually.

28:21 So something like that would be a DAW.

28:24 Yeah, I use Adobe Audition.

28:25 Yeah.

28:25 So there's a lot of stuff you can do that are just common things that you're going to do to all files.

28:32 So it'd be kind of neat to automate that.

28:33 So things I'm thinking about are things like a compressor, a high-pass filter, a low-pass filter.

28:38 But this thing has a whole bunch of other transforms you can do, like convolutions

28:43 and chorus and some distortions and gain if you want to make it louder.

28:48 Some reverb, a high-pass filter.

28:50 And then stuff.

28:52 I don't even know what it is.

28:53 A ladder filter.

28:53 I don't know what that is.

28:54 Phaser?

28:55 Phaser.

28:55 That sounds neat.

28:56 Yeah, it does.

28:58 Oh, shit, Scotty.

28:59 So I definitely want to try that out.

29:03 And if you're working with audio files, I think it would be kind of a fun thing.

29:08 We've linked to the GitHub repo for it, which is nice.

29:13 It's completely open source.

29:15 It says it also has some cool things like plugins for VST3 and audio unit, which I have no idea what those are.

29:24 But also, there's some...

29:26 One of the things with audio is it takes a while.

29:29 So there are speed enhancements in this.

29:32 So it says it really doesn't take that long to use it.

29:35 It takes advantage of your CPU cores, which is neat.

29:38 Also linking to an article to introduce it.

29:40 And I got to warn people.

29:42 There's an image at the top, which totally messed with my head.

29:48 Because, I mean, it just triggers me with all the different flashing colors.

29:52 So be careful with that.

29:54 Scroll past that quick.

29:55 But other than that, it's a good article on what it is.

29:58 Some graphics.

29:59 And I don't quite get...

30:01 There's some graphics on how it works.

30:03 And I don't quite get what the graphics mean.

30:07 Like the noise gate really doesn't tell me much.

30:09 I love the noise gate.

30:10 That's one of the biggest tricks to sound good, actually.

30:13 Yeah.

30:14 So important enough for me that I've got a hardware noise gate in my studio.

30:19 Nice.

30:20 Anyway, cool library.

30:23 Check it out.

30:23 Yeah.

30:24 So if you want to do audio transformation.

30:25 If you want to basically write Python code that does like Audition or the one you said, Brian.

30:30 Well, I mean, and especially with automation.

30:33 So if you've got like a whole bunch of files you're dealing with and you want to make sure that they're all kind of the same level,

30:38 you definitely want to automate that and not try to...

30:42 And I know there's ways to automate with some of your other tools too, but it's kind of cool to have this.

30:48 Yeah, definitely.

30:49 The only thing I have to contribute is going back to Brian's previous link about good documentation.

30:56 While you two were talking, I just submitted a PR to fix the trailing triple backticks

31:00 accidentally left in their readme.

31:02 So just to give feedback to people, trying to fix documentation is always appreciated.

31:07 And it's usually something you can do pretty quick, especially with either the pencil editor in GitHub

31:13 or just hitting the dot to use GitHub.dev if you want, if you need a little bit fancier support and just send that PR.

31:19 And I mean, most maintainers would appreciate it.

31:22 As we all know, it's hard to keep going straight.

31:25 If you submit an issue or send an email and say, this part of your docs needs this misspelling fixed

31:31 or this link has an extra trailing slash that makes it not work, that's work.

31:36 If you submit a PR, that's joy, right?

31:38 You just say, I accept.

31:40 Okay, you fixed it.

31:41 Thank you.

31:41 I'll just carry on, right?

31:42 Rather, oh, geez, I got another thing to do.

31:44 So yeah, that's great.

31:45 Nice catch.

31:46 It took me well to see that.

31:47 Yeah.

31:48 Well, I mean, some people ask me, like, how do you have so many contributions to so many repositories?

31:53 That's how.

31:54 Literally, if you just read docs, anytime you find anything a little off, just take the time to just submit that PR.

32:00 And most of them get in.

32:01 Not all of them do.

32:02 But honestly, that's enough to just kind of help out.

32:05 And honestly, you just suddenly end up contributing to, I think I'm up to 160 something repos on GitHub at this point.

32:10 Wow.

32:11 That's awesome.

32:12 Thanks.

32:14 Okay, so Michael said it was nice sometimes to have core devs.

32:18 We'll see if this doesn't cause you to regret having core devs on the podcast.

32:21 So I'm going to use this as story time and just kind of explain how processes work in terms of packaging peps.

32:28 Starting about six months ago, I took it upon myself to try to come up with a lock file format for Python.

32:35 It seemed like it was kind of a gap we had where multiple tools were trying to solve the same problem.

32:41 And that felt like something that we should try to avoid if possible.

32:44 Coming from speaking as the dev manager for the Python extension for VS Code, having each bespoke tool such as pipin, poetry, requirements.txt files, even through pip-tools, right?

32:56 Having to support each of those tools individually is a drag, right?

33:00 Like it takes a lot of time and effort to figure out what to do for each tool.

33:04 If the tools update, suddenly we break.

33:06 So it's a bit tricky.

33:08 Making calls through CLI is kind of an annoyance too because we got to make sure that they're, you know, how to use their API, what they report out is consistent, that they don't change it.

33:18 Because not all tools consider their output or their CLI part of their stable API that they maintain.

33:23 Anyway, there's a lot of drawbacks.

33:24 So I tried to decide to be silly and take it upon myself to see if I can come up with a way to get all the tools to kind of rally around something.

33:31 There's also needs for like cloud, right?

33:34 Like if you upload something to Azure Functions, they want to do the install for you, but you need to be able to tell them what you want installed.

33:41 So lock files, good thing, right?

33:43 Just in general.

33:44 So I spent six months talking behind the scenes with various people.

33:47 Originally it was me, Pratune, and Zuping from Pip.

33:52 We came up with a lock file spec.

33:54 And then we invited Sebastian and Frost from Poetry and PDM, respectively.

34:03 And they said, that's not going to work for us.

34:05 And we said, why?

34:07 And it's like, well, your lock file was defined very specifically for a certain platform, right?

34:11 Like think of wheel tags, right?

34:12 It says, well, Python version, what ABI do you support, and what OS are you on, right?

34:17 That's the platform from what I'm speaking from.

34:19 It's like, that's great, but we want platform agnostic lock files, right?

34:24 Like if you ever crack open the lock files that Poetry spits out, they actually work no matter what OS you're on.

34:29 And it was by design.

34:30 Sebastian wanted to make it so that it didn't matter.

34:32 And actually, I've heard a good example from Pratune where it's like, let's say you're doing Pi Week, right?

34:38 And you're doing a game.

34:40 You might be developing on Linux, but if you want to give it to your teammate who you're working with during Pi Week and they're on Mac,

34:47 you want a way to be consistent on what you work on.

34:49 And then if the judges are on Linux, you're on a whole other place or Windows or whatever, right?

34:54 So there is a use case there for platform agnostic lock files.

34:58 So we tried to add that back in.

35:00 We took this public to discuss stuff at Python.org where all the packaging discussions happened.

35:05 And it led to 152 comments on a thread starting July 29th.

35:11 So actually, it's more like, oh God, eight months ago.

35:15 So this led to a whole other discussion, right?

35:17 About people going like, okay, the clarification.

35:19 And it ranged, right?

35:20 All the way from the title's not clear enough to like real nitty gritty details.

35:25 And it's now led to us going back, having discussions with the same people plus some other people who participated here who made good comments

35:36 to try to come back with another approach that's a bit more from the ground up covering everything versus what we had before where it was just a platform specific lock file.

35:44 And then we kind of bolted on the agnostic bit and try and design it from scratch.

35:48 But the key point here I want to make is you hear people sometimes go on about, oh, I really want lock files, right?

35:54 Like I've talked about this publicly and I think I talked about this PyCascades, maybe I mentioned it during the steering council keynote or maybe it was PyCon.

36:03 And my wife, Andrea, who said she might actually be in the live stream, said, oh my God, all the comments about when you mentioned lock files were so, so positive.

36:11 Like, okay, cool.

36:12 It's surprisingly hard to make this stuff work, right?

36:14 Like everyone thinks it's a snap your finger.

36:16 Someone has an idea.

36:18 Do you just get it done?

36:19 But there's a lot of use cases here, right?

36:21 And especially with packaging, you constantly hear people go like, Oh, packaging in Python is so bad.

36:25 Well, first of all, most people are out of date.

36:27 Like Brian's been really great about having me and other people come on testing code, for instance, directly, specifically to talk about this past packaging stuff to keep people up to date.

36:36 So there's a lot going on, but if you need to try to keep up.

36:41 But on top of that, it's just hard to make any changes because there's so much legacy out there.

36:45 Everyone's got their own workflow at this point, right?

36:48 Like 30, 30 year old language that's had some form of packaging for like over 20 of it.

36:54 Everyone's got the way they want to work.

36:55 And no one likes to have it changed on them.

36:57 Especially your workflow, right?

36:59 Like try telling someone who's using VS Code, like, yeah, we don't think you're doing it the right way.

37:04 Does not fly, right?

37:06 It just does not work.

37:07 Everyone wants to work the way they want to work, which is totally fine.

37:09 But it also makes trying to come up with a standard really hard.

37:12 So the point I'm trying to make here is try to be understanding when you work with packaging Python.

37:16 Not only is Python challenging it on its own due to the amount of C code, Fortran code, all the crazy stuff that people used thanks to us being the glue code, the glue language of the world.

37:26 But on top of that, there's a lot of legacy.

37:28 Everyone has something they ask for.

37:30 And people are working very diligently to continue to try to improve it.

37:34 But do understand that there's a lot of work going on to try to make it better.

37:37 So please try to be understanding on Twitter or wherever else you're going.

37:42 Oh, my God.

37:42 Packaging Python is so bad.

37:44 The places where outrage must be expressed.

37:46 Yeah, yeah.

37:47 So that's what really here.

37:49 So A, lock files are hopefully coming.

37:51 I am working on a V2 of this PEP.

37:53 Probably go public with that.

37:56 I'm going to guess sometime next month.

37:57 And these will be independent of things like poetry and pip-inf and just pip and stuff like that?

38:03 If we're lucky, right?

38:04 Like the key point here is we can't require this.

38:09 But the hope is whatever solution we come up with will be good enough for those tools to rally behind.

38:14 None of this is like an edict from on high to say like all packaging tools must use this.

38:19 The idea with all this has to be what's the carrot for the tools, right?

38:23 How are we making things better both for the community but for the tools themselves?

38:26 Now, it can be we make it so great from the community that the tools feel pressure to support it.

38:30 But when you're talking from this perspective, the first thing you're dealing with is the tools.

38:34 So it's trying to make the tools happy because then eventually the users also become happy.

38:38 So we'll have something.

38:40 At worst, my suspicion is at absolute worst, we'll have platform-specific.

38:43 Specific lock files come out with this path.

38:45 But my hope is we can get platform agnostic and get all the other tools on board so that everyone gets what they want and need and we can service everyone's needs.

38:52 Nice.

38:53 But the key point here is it's being worked on.

38:56 It's taken a long time.

38:57 It's going to take even longer.

38:58 So understand that when people say, oh, why can't packaging get better faster?

39:03 It takes a long time, right?

39:05 Like literally, I've been working on packaging as my focus for Python stuff for years now, right?

39:11 It's not a fast process because there's a lot of people involved, a lot of projects.

39:15 Everyone has their needs.

39:16 So people just need to be patient.

39:18 But do understand things are getting better consistently.

39:20 That ends my rant to hopefully not make you all regret having me on.

39:23 No, that's great.

39:24 I love the insight.

39:25 The only thing with packaging that I want to bring up is I wish it didn't change all the time.

39:30 Sorry.

39:34 I couldn't resist.

39:35 No, I think things are getting better and I like the direction.

39:39 So, but cool.

39:41 Yeah.

39:41 I mean, my grand unified goal when I got involved with packaging really was to try to drive everything towards standards and specs, right?

39:49 Like I have a project called Mouse Bender after the clerk from the cheese sketch, right?

39:55 If you don't know the Monty Python sketch, it's when one of them walks in and just starts to ask for every cheese they can think of and they don't have any in the cheese monger shop.

40:05 So, anyway, I created an outline of what does it take to go from I want to install Django 3.2.7 down to actually getting files on desk.

40:14 And I figured out where there was a spec and where there was a library back in that spec and where the gaps were.

40:19 And I've just been trying to plug it.

40:20 And this is probably the last one, right?

40:22 Because more or less this takes care of the pip-tools, pip m poetry kind of give me a set of locked things and let me be able to reproduce my environment.

40:31 After this, I think I'm more or less kind of I'm personally probably going to be done with packaging.

40:36 After this is moving on to WebAssembly, which hopefully make Michael happy.

40:41 Oh, yeah.

40:41 And then probably that'll lead into is there a way to potentially start distributing like a self-contained binary for Python or just try to help with Python as a Python, CPython interpreter distribution kind of solution.

40:53 So is the new PEP going to be 666 or is that already taken?

40:57 No, actually 666 is taken.

41:02 Okay.

41:03 It's been taken for over a decade.

41:05 It was purposely done to be immediately rejected because it said you should be able to allow mixed tabs and spaces.

41:10 So that was written to make people stop asking for that and it got rejected immediately.

41:14 Okay.

41:14 Okay.

41:15 But no, I'll just since this didn't get accepted, I'm just going to rewrite it in place.

41:20 The goals are the same.

41:22 There's no need to have to do yet another PEP.

41:24 So since this draft, I'm just going to basically just gut it and redo it.

41:28 And since the goal is the same, I'm just going to reduce the number.

41:31 Okay.

41:32 Nice.

41:32 Well, thanks for working on this because it definitely is important.

41:35 Yeah.

41:35 You're welcome.

41:36 Hopefully it'll lead to something.

41:37 Otherwise, I've had a lot of interesting conversations about how people do and don't want to lock things.

41:41 Brian, back to you.

41:43 Back to me?

41:44 Yeah.

41:44 For extras.

41:45 For extras.

41:47 You got any extras?

41:48 Yeah.

41:49 So I've got one.

41:50 I'll throw it up.

41:51 So it looks like Python's popular.

41:56 I've heard that.

41:57 I bet it would be popular enough to have a podcast about it.

42:01 With lots of pop-ups.

42:02 Or three, even.

42:03 Exactly.

42:04 So there's an article on ZDNet.

42:07 Python is on the verge of another big step forward.

42:11 And the big step forward, apparently, is the Ti...

42:15 I'm going to get this wrong.

42:17 Tiobi Index.

42:18 List C is the number one language.

42:21 But Python only needs 0.16% more to become the number one language, according to this index.

42:29 So are they arguing that if we got to the top of Tiobi, that would cause another spike in usage?

42:33 I have no idea.

42:35 No, another spike in usage would cause this to happen, maybe.

42:39 I don't know.

42:39 Oh, I don't know.

42:40 Yeah.

42:40 Yeah.

42:41 So I think, historically, only C and Java have ever had that designation.

42:45 And so it's kind of big news.

42:47 JavaScript's never gotten up there?

42:49 I don't think so.

42:50 Oh.

42:50 Okay.

42:51 One more thing.

42:52 Brett mentioned the cheese sketch.

42:56 And if you go to PyPI.org and type, like, anything that's silly, you'll probably get a 404.

43:01 And the 404 has the cheese sketch embedded in it.

43:05 Yes.

43:05 The G-shop sketch is at the bottom.

43:07 And a piece of history.

43:08 PyPI was originally supposed to be named the G-shop.

43:11 It was actually originally supposed to be, it was actually originally cheese shop.python.org.

43:15 But people were too concerned that managers wouldn't take Python seriously if the package index was named after a mighty Python sketch.

43:21 So it got its name changed.

43:24 Yeah.

43:25 Cool.

43:26 Brett, looks like you got some extras as well.

43:28 Yeah.

43:29 Well, I mean, this is Python Bytes.

43:31 So we couldn't go an episode without mentioning Will.

43:33 Although I think Will's out in the live stream.

43:34 So this is also more of the Paul love fest on here.

43:41 So Paul had Will go on to an episode to talk all about textual and rich and how it's all textured, mainly textual.

43:48 I believe Will tweeted that he got a haircut for this and everything.

43:51 I actually haven't watched it.

43:53 But as I said, it's not Python Bytes that Will doesn't get mentioned.

43:55 So I just want to make sure Will got called out.

43:57 I will also say that it has been 30 episodes since I was last on, which I thought was kind of a nice round number.

44:05 But on that episode, I mentioned that I was working on the Python launcher for Unix.

44:09 And since over the last 30 episodes, I've actually wanted to mention that I had launched version one.

44:14 And thanks to Brian and Michael for feedback because actually one of their feature requests got into it.

44:19 The one thing I did want to call out that actually did happen recently is the launcher is now actually in Fedora.

44:26 So one of the first things that ever got contributed was someone actually put Arch.

44:30 It was actually Burnout Gabor of Tox fame.

44:35 Got it into Arch via AUR.

44:38 I don't know how Arch does community versus not.

44:40 There's a whole thing.

44:40 But you can install it via Arch.

44:43 But just the other week managed some very nice folks from Fedora were nice enough to get it in.

44:50 So you can actually now use DNF to install the launcher on Fedora.

44:53 And then all the previous tarballs are all there as well.

44:57 So it's still available.

44:58 But yeah, version one, no bugs so far.

45:01 So it seems nice and stable and meeting people's needs pretty much.

45:04 Awesome.

45:04 Congratulations.

45:05 Thank you.

45:06 I'm pulling on Michael extra, extra, extra, extra at the end.

45:11 I will say that my Syntactic Sugar series is still going on.

45:16 When it's done, I'll probably have a wrap up thing.

45:19 And this is probably going to be what my next set of talks will be all about.

45:21 But they're still happening.

45:23 One interesting thing.

45:24 I actually just did two just in the last two days.

45:28 They were short.

45:29 Actually.

45:30 Oh, God.

45:30 I didn't really.

45:30 They published three in a week.

45:31 That's a lot for me.

45:33 I did have one that didn't work.

45:35 So if anyone's curious, what happens when I can't unravel a piece of syntax?

45:38 You can read that blog post to see how I put in all the effort to do it.

45:41 And then realize the day after.

45:43 Oh, yeah.

45:44 That's not going to work.

45:45 I did enjoy that.

45:47 Oh, good.

45:47 Yeah.

45:48 Yeah.

45:48 Assignment expressions continuously break me in various ways.

45:52 So there's a bunch of syntax I can never undo because of assignment expressions.

45:54 They're handy, by the way.

45:55 I've used them since the month after we approved them.

45:58 But they do make unraveling our stuff hard.

46:01 And then for Brian, I just wanted to call out that in our last release for the Python

46:07 extension for VS Code, we completely redid our UI.

46:12 VS Code now actually launches with a built-in UI for testing.

46:18 And we integrated directly into it.

46:21 So now you have consistent UI for testing.

46:23 Like a test tree result type of navigation thing.

46:27 Yeah.

46:28 Well, and we had that before, actually, but it was bespoke to our extension.

46:31 And so there was some wonkiness to it and all that.

46:34 But now that this is actually built into VS Code, if all the language, I suspect, will eventually

46:40 move over to this.

46:41 So by having that, learning it for one tool, one language means it'll work for another language.

46:45 And there's some extra niceties to it as well in terms of updates and all that.

46:51 It's really snappy.

46:52 We'll probably, we are also going to rewrite all the code behind this and how it runs to

46:59 make it a bit more performant, more stable and all that.

47:01 So if you've had UI problems before with testing with VS Code for Python, please give

47:06 another try.

47:06 If you've had more discovery run problems, we are going to be working on that.

47:09 So that's coming up as well.

47:11 And then when that's all done, we'll be bugging Brian about this to make sure he gets the Brian

47:15 Okkens stamp of approval.

47:17 Yeah.

47:19 You know, I charge for that.

47:20 But no.

47:21 I thought that was just coming on the podcast was the fee.

47:24 No, I definitely, I tried this out and I like the changes.

47:30 And I'm excited to see the discovery changes as well.

47:33 Yeah.

47:33 Well, we reached out to the pytest team directly actually and asked them like, what would you

47:38 want us to do?

47:39 And they gave us some feedback of how they think it should be done and all that.

47:42 So we're hoping to incorporate that and use that as the basis of how we do pytest and then

47:46 UnitTest.

47:46 UnitTest is UnitTest.

47:48 Unfortunately, we had to break, we had to drop no support due to this, but honestly, it was

47:52 extremely low used anyway.

47:55 But we did have a lot of gum, but we still have UnitTest by Test support.

47:58 People shouldn't use it anyway.

47:59 You heard it from Brian.

48:01 Don't send me the hate mail.

48:03 But yeah, that's it.

48:05 Nice.

48:05 Those are all great ones.

48:06 All right.

48:07 I now have banners to separate my sections.

48:09 Oh, that's awesome.

48:11 Nice.

48:12 All right.

48:12 I'll be quick, but I do have a couple of things.

48:14 I just want to go back and sort of talk more about NerdFonts a little bit at nerdfonts.com.

48:19 People can check this out.

48:20 So it takes all these different things and puts them together like a bunch of font, awesome

48:24 fonts, dev icons, weather icons, and to a bunch of things.

48:29 And then the ones that I really like is the developer fonts, right?

48:34 So you go over and check these out.

48:36 A lot of them have font ligatures.

48:38 Brett, I don't know how you feel about font ligatures, but I'm actually a fan.

48:42 Although they freaked me out when I first saw them.

48:44 I'm definitely a fan.

48:46 I'm actually a fear of code.

48:49 Yeah, exactly.

48:50 Yep.

48:50 Although the new ligature support for infinite arrow length throws me a bit sometimes to the

48:58 point that I actually have turned it off and I use Cascadia code, the NerdFont version

49:03 for Starship in my terminal.

49:04 So I actually have a separate font for terminals in here.

49:07 Yeah.

49:08 Cascadia right there.

49:09 Cascadia Cove here.

49:11 It's Cascadia code on the official.

49:14 Gotcha.

49:15 So yeah, I use Cascadia for my terminal and then I use Fira code for my editing.

49:23 Although I'm contemplating actually buying a font called Mono Lisa, M-O-N-O-L-I-S-A and

49:31 using that.

49:31 But I haven't pulled the trigger yet.

49:33 I'm not against buying fonts if they're amazing.

49:35 Yeah.

49:35 Neither am I.

49:36 It's $100.

49:37 Armin Roenacker actually uses it.

49:39 That's partially how I came across it.

49:41 And someone else recommended it somewhere.

49:43 Kuchel Doss.

49:44 Yeah.

49:44 Paced on me tweeting about it, bought it and actually thanked me for using it.

49:48 So multiple people I know use it and actually appreciate it.

49:50 Yeah.

49:51 And it does have ligature support.

49:52 Good.

49:52 Yeah.

49:53 All right.

49:53 So one more shell thing.

49:54 So here is my power, my Microsoft terminal running Oh My Posh on my computer.

50:00 Look how dreadful that looks, right?

50:02 That's because I, that's because I'm not using nerd fonts.

50:05 If people are just listening, there's just tons of squares where there should be, where there

50:10 should be symbols and stuff.

50:11 And it says like, you know, username, square, square, folder name, square, square, get information.

50:17 But if you go and install the nerd fonts, pretty much any of them, the terminal or Oh My Posh,

50:22 actually, I guess is what it is, is, is tested against all the nerd fonts to work.

50:26 So if you install that, then you end up with beautiful terminal, right?

50:30 So definitely something nice to look into.

50:34 If you're just a, yeah, just use whatever mono thing is built in.

50:38 Yeah.

50:38 The nerd fonts are cool.

50:39 All right.

50:40 Let's see what's next.

50:41 Oh, did a article interview.

50:44 This company in Russia interviewed me and people are interested.

50:48 I want to give a quick shout out to that.

50:50 It was kind of fun to talk about some of the history of the podcast and stuff over there.

50:53 More shell Henry Schreiner third said, shared with us, here's my setup process for setting

51:03 up a new Mac.

51:03 And there's all these cool scripts and brew setups and all sorts of things,

51:07 including all the fish shell and Vim setups that you might need.

51:13 So if you want to follow up, we talked a little bit about that last time.

51:16 People can follow up with that.

51:17 I'll also say one convenient thing about committing all of your dot files, at least on GitHub is

51:23 if you use code spaces, GitHub, and you check a box, code spaces will automatically clone your

51:28 dot files repo and load them up into your code spaces.

51:32 Ooh, that's nice.

51:33 Yeah.

51:33 That's very nice.

51:34 And so I've actually published my dot files and done somewhat of a similar thing.

51:39 The other nice thing is obviously when your machine, I don't know if I ever told the story

51:43 in this podcast, but when your laptop accidentally gets grabbed by someone else and ends up in

51:48 Dubai and it gets shipped to you to a core dev sprint in London later and you feel the need

51:54 to wipe it for security purposes.

51:55 It's very convenient to have all your stuff in the cloud and have your dot files in a repo.

51:59 So it's just a clone run and you're done.

52:01 Yeah.

52:02 I would want to wipe it too.

52:03 Someone had physical possession of your laptop for a while.

52:07 Yeah.

52:08 All right.

52:09 A couple other things, Brian.

52:10 Last time I said I was using the editor to just jump between projects and stuff.

52:15 And one thing I didn't point out is like I'm on the terminal all the time as well, but I basically,

52:20 everything that I have some kind of terminal command for is I've almost entirely set up some

52:24 kind of bash alias.

52:25 So that actually uses the specific virtual environment as part of the command in the alias.

52:31 So it doesn't matter what I have activated or where I am or anything like that.

52:35 So anyway, just a quick follow up on that.

52:37 Cool.

52:37 All right.

52:38 Well, I think that's it for extras.

52:40 Do you have a separator for our joke also?

52:43 I have a laughs.

52:44 I have a separator for our laughs.

52:45 Yes, of course.

52:48 Nice.

52:48 I hope this is not as funny as the joke, but you all, you all will be the judge.

52:52 Okay.

52:53 Okay.

52:53 All right.

52:54 So this is going back to a solid, solid place.

52:56 Geek and poke over at geek dash and dash poke.com.

53:00 This one is called the last 5%.

53:02 And Brett, your comment was perfect about setting up a new computer or reinstalling everything.

53:08 Right.

53:08 So this is the last 5%.

53:09 I know where this is going.

53:10 Or corporate IT made easy.

53:12 Make sure that the new developers, notebooks or computers aren't only 95%

53:17 provisioned.

53:18 So there's a senior woman developer helping a new one who can't seem to compile the project

53:24 or run it or something that says, I had the same problem, but I barely remember somewhere

53:29 in a wiki or on a file server, there was a certificate or something like that.

53:32 And I had to copy it to some folder on my machine.

53:35 And it's just entitled the last 5%.

53:38 It's like anytime someone onboards onto your team right at work.

53:42 Yes, exactly.

53:43 Oh yeah.

53:43 Go read with the last person five years ago or two years ago or how often you get a new

53:47 person come on.

53:48 Yeah.

53:48 Did it.

53:48 And by the way, the processes have all changed.

53:50 So yeah, chances of it does not work.

53:52 Yeah.

53:52 Just scroll back two years in Slack or Teams and find that message where we talked about

53:56 it.

53:56 Yeah.

53:57 You just have to hire people more often.

54:00 So they update the wiki at least every few years.

54:03 Yeah.

54:04 But the question then becomes, is it because your headcount's growing or because your turnover

54:07 is so high in this, you're just a bad manager in this, everyone just keeps quitting your

54:11 team.

54:11 Yeah.

54:12 I'd rather just have the stable number of people who, by the way, told me they were

54:15 going to be on the live stream and I didn't see Michael let any of the comments by.

54:19 So I wonder if they actually showed up.

54:20 So hello to my team if they showed up.

54:22 And Andrew and my wife, if she did.

54:25 Yeah, I hope they did.

54:25 And Chris May has a final parting thought for us.

54:29 This comic hits too close to home or work or work from home.

54:32 Yeah, definitely.

54:34 Definitely.

54:35 Cool.

54:36 Well, that's it.

54:37 So thanks a lot, Brett, for showing up.

54:39 Of course.

54:40 It was a joy to have you.

54:40 Thank you to my cat for taking a nap during the entire podcast and let's not distract

54:44 me in the middle of it.

54:45 We'll put it on our calendar to make sure to invite you about every 30 episodes then.

54:49 Perfect.

54:50 Yeah, it's great to have you here.

54:52 Yeah.

54:53 Thanks.

54:53 Thanks, everyone.

54:54 Thanks, Brian.

54:55 Thanks, guys.

54:56 Thanks for listening to Python Bytes.

54:57 Follow the show on Twitter via at Python Bytes.

55:00 That's Python Bytes as in B-Y-T-E-S.

55:03 Get the full show notes over at Pythonbytes.fm.

55:06 If you have a news item we should cover, just visit Pythonbytes.fm.

55:10 and click Submit in the nav bar.

55:12 We're always on the lookout for sharing something cool.

55:14 If you want to join us for the live recording, just visit the website and click Livestream

55:18 to get notified of when our next episode goes live.

55:21 That's usually happening at noon Pacific on Wednesdays over at YouTube.

55:26 On behalf of myself and Brian Okken, this is Michael Kennedy.

55:29 Thank you for listening and sharing this podcast with your friends and colleagues.