Transcript #251: A 95% complete episode (wait for it)
Return to episode page view on github00:00 Hey there, thanks for listening.
00:01 Before we jump into this episode, I just want to remind you that this episode is brought to you by us over at TalkBython Training and Brian through his pytest book.
00:10 So if you want to get hands on and learn something with Python, be sure to consider our courses over at TalkBython Training.
00:17 Visit them via pythonbytes.fm/courses.
00:21 And if you're looking to do testing and get better with pytest, check out Brian's book at pythonbytes.fm/pytest.
00:28 Enjoy the episode.
00:29 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
00:34 This is episode 251, recorded September 22nd, 2021.
00:40 I am Brian Okken.
00:41 I'm Michael Kennedy.
00:42 And I'm Brett Cannon.
00:43 So do we need to introduce Brett?
00:45 I mean, thanks for being on the show, Brett.
00:48 Welcome back.
00:49 I'm going to introduce my cat, Gidget, for all those on the live stream, because she's in frame at the moment, just lounging around on a nice comfy blanket.
00:56 from Google from when I won an open source peer bonus.
01:00 You won your way more information than anyone probably cared, but there you go.
01:05 Nice. Yeah, my dog is around here somewhere, but probably won't show up in screen.
01:08 Well, let's just get started.
01:11 I think if people don't know, Brad, they need to get out from under a rock.
01:15 So, yeah, absolutely.
01:18 Live chat real quick.
01:20 Brandon Branner. Thanks.
01:22 They give you a cat.
01:23 No, the, yeah, there's a long story about how we got Gidget, but no, cat did not come with the blanket.
01:29 So the first thing that I want to talk about comes to us from, this is both recommended and created by Dan Lutic.
01:38 So Dan, nice work.
01:40 I love these little tools that you can run against your code that will just reformat them to be better.
01:46 You know, one of the, probably the most popular and well-known one is black, right?
01:50 We've all heard of black, which is great.
01:53 But there's other ones like Flint, F-L-Y-N-T is one of my favorites that converts all the various string formattings to F-strings, which is great.
02:02 Here's another one around typing called auto-optional.
02:06 Brett, I think people maybe are using optional a little bit wrong in the typing space in Python. What do you think?
02:12 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 to have the concept of optional to represent, hey, this thing can be whatever the type is or none.
02:27 >> Yeah, what was the thinking there?
02:28 Because languages like C#, Java, C++, you can have a thing and then it can be null.
02:34 In C#, there's value types, but generally most things are pointers and they can be set to null.
02:39 You don't have to have some special type to say it's either a user or it's null.
02:43 You just say it's a user because it could be a reference type, but also could be null or nil or whatever.
02:47 But Swift and Python have this concept of you must explicitly say that it could not have a value.
02:54 - So explicit is better than implicit, as we all know.
02:58 The other thing is obviously having none accidentally sneak in when you don't want it.
03:03 As you mentioned, Michael, Swift specifically does not let you have null.
03:08 You can't have null references.
03:10 You have to either declare that it will accept null and you have to check or it won't take it at all.
03:14 And it's a similar thing here.
03:16 No one likes it when they actually find out, oh, the null type's not callable 'cause you accidentally passed none.
03:21 - What's the most common exception type is attribute or type attribute.
03:26 None has no attribute, whatever the thing is you're trying to access, right?
03:29 That thing?
03:30 - Yeah, I'm willing to bet, yeah, that attribute error alone, it probably makes up like a huge portion of people's exceptions.
03:35 So that's why you have to be explicit.
03:37 It's like, you need, if you're gonna be running a type checker, let's be very explicit about what you do and don't expect.
03:42 - Yeah, cool.
03:43 I agree with that.
03:44 I think it's nice.
03:45 It did surprise me at first, but then I'm like, oh, okay, well, that's an interesting choice, but now that I know, I should use optional.
03:52 So here's a case of a function, and it's just some foobar example, but they have a bar parameter, and they say colon str equals none, so they're giving it a default value, and saying it can be a string.
04:04 Well, obviously, that is, like, in three words, patently wrong, right?
04:09 It can't both be a string and be set to be none, because strings and type system can't be none.
04:15 They have to, that has to be optional, right?
04:17 And so--
04:18 All of us know what that means.
04:20 - I know, we all know what that means.
04:21 - Well, so funny enough, you know what it means, but if you didn't write that, do you know what they actually meant, right?
04:27 Like if Michael typed that and you saw it, would you go, "Michael meant for that "to actually be optional and thus nullable "in terms of how other languages write it?" Or was that on purpose?
04:37 And that's why that's not allowed, is 'cause you don't know who screwed up, if anyone.
04:43 Was that accidentally written that way and it really was meant to be optional?
04:47 or was it on purpose and thus it's listed that way?
04:50 Because you don't know intent of someone else who wrote it, 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.
05:00 So the idea of this is it's a thing you install, but then you pip install it, but then you just run it on the CLI like Flint and you just point it at a directory and it will go through and it'll find all of these default values that are none, but don't have optional in their type information and then it'll just add optional, which is pretty straightforward, but it's so easy to use, right?
05:22 It's like, oh, I have this 20,000 lines of Python code and I really wish they were f-strings, like flint that folder, it's done.
05:28 So same thing here, right?
05:30 It's I've got this huge bunch of code and nobody really thought about optional, let's just quick fix that.
05:36 It doesn't fix it everywhere, right?
05:37 Like I could say a thing takes a string without a default value for the parameter and then maybe somewhere else it's getting a none And it's not like that advanced.
05:46 It just looks, if you're having default values that don't match the type, make them match.
05:50 Yeah.
05:50 so I like it.
05:52 one of the questions I have is, so if I do optional string equals none, does that mean I still can pass none to the, to the function?
06:02 Yes.
06:03 Cause it wouldn't be different.
06:04 That is normal.
06:05 Okay.
06:06 But it wouldn't that be the same as saying that I can pass stir or none?
06:09 Yes.
06:10 Yes.
06:11 And also that's what, on the live stream, Will McGugan.
06:15 Hey, Will says, do you need optional now that we can have foo pipe none as an alternative to optional of foo?
06:23 No, but this is sort of more backwards compatible, right?
06:26 Brett, when did that come out?
06:27 Is that three nine?
06:29 - Three 10, I think.
06:30 - Three 10, yeah.
06:31 - So it's not even out yet officially.
06:32 Next month.
06:33 - Yeah, so.
06:34 - Give it a little over a week.
06:36 - Right on.
06:37 That's exciting.
06:38 But you know, how much backwards compatibility do you want, right?
06:41 So I think soon, but maybe, I don't know if I would go yet.
06:44 And then Chris May says, "Oops, opening PyCharm "to add optional to my last project." Before you go to the work to write it, just run this against it on the CLI, on the command line, and just see how it works, right?
06:56 So, yeah.
06:57 - Should also work in VS Code.
06:59 - Although ZDocs does say, back in 3.7, you can use from dunder future import annotations, and then get that to work.
07:05 I don't know about that personally, Brett?
07:08 - So, what ZDocs is suggesting here is, if you use the from dunder future import annotations, What that does is it turns all your annotations technically into strings to Python.
07:18 And so it's actually not executed.
07:19 Because before that, what actually happened was that code in your annotation actually got run and the resulting object got 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 import.
07:35 You might have performance reasons.
07:36 Don't do that.
07:37 And it'll actually just become a string.
07:39 And then we have some stuff to try to resolve that This is the whole thing that came up at Python 310 that you all covered in a previous episode.
07:49 Pydantic going, oh God, there's a change coming in 310 that might break us, and there's a whole kerfuffle, and anyway, that's what that's all resolving.
07:56 So technically, you're right that you could write it back, but it would break complete expectations of everyone who ever tried to use your code when you tried to run that somewhere else.
08:07 So I would advise against it, unless you know you're gonna be working against 310, because for instance, someone might write code for Python 3.7 or 3.8, tell my Py is Python 3.9, and then it would error out saying, well, that syntax makes no sense.
08:21 - Right, okay, interesting.
08:23 Well, yeah, pretty good one.
08:25 Super easy to use, not a whole lot to it, but I think it's because it's so easy to adopt, it's kind of a nice one.
08:32 - Yeah, well, I wanna talk about something that's not easy.
08:35 It's not easy to write good documentation.
08:38 - Definitely not.
08:39 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:48 There's an article called "Making world-class docs takes effort." I think it's an understatement.
08:54 It takes a lot of effort.
08:55 But this is a nice little project or article.
09:01 Talks about he's got some gold things that he looks for.
09:05 To get a gold star, you must have these six items in your documentation.
09:09 Let's just talk about what he's looking for.
09:12 First of all, the documentation should be in the repositories of the code.
09:16 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 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.
09:36 But generally, I think that's a good idea.
09:39 >> Most projects have the reverse.
09:41 The documentations that was edited two years ago, but there's been changes continuously.
09:46 I don't even know if they still apply.
09:48 >> Yeah. But it is good to try to keep these together.
09:51 Also, you can make a pull request or a merge request with both the documentation and the code together.
09:58 That's a good reason for that.
10:00 Next step is that your docs are not extracted from code.
10:03 I know there's a lot of tools out there that can try to 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 agree with this. Yeah, you can usually spot it because it'll be like method login user and then the method the comment will be logs in user and you're like on it. 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 because they just use that to spit out your docs.
10:39 In which case, it's not as convenient as when you just run help from a REPL to just go like, what does this do again?
10:45 What are the arguments?
10:46 I need a really clear pointed thing directly at a developer who's just trying to double check something versus a whole exposition of here are all the examples of how to use this thing.
10:55 It's like, I don't need that level of detail.
10:56 I just need to remember one little thing.
10:58 - Right, right.
10:58 It's a range.
10:59 Is it inclusive or exclusive of the bound?
11:02 Something like that, right?
11:03 >> One place where 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. I'm shocked, Brian.
11:16 >> That I would really like to have docstrings.
11:19 They encouraged developers to put docstrings in there for the reason why the test exists and what feature it's really testing.
11:25 To be able to have an auto-generated website with just all of our tests, that'd be cool.
11:32 but I'm not there yet.
11:33 >> That makes sense.
11:34 >> The next thing is your docs feature examples.
11:38 I love this because that's what people want to know.
11:42 If I want to do this, how do I do it?
11:45 The comment is really just use examples.
11:48 If you already have examples, add more.
11:50 You probably can't have too many examples.
11:52 >> Test them.
11:54 >> Oh, yeah. Test the examples.
11:56 We covered a tool called MakeDocTest that you could use to test your code within your documentation, use that.
12:04 Next is, "Do you document every API call you provide?" This one's a tough one to keep up on, but it's really important.
12:13 Even some great projects like Typer and stuff that I've used, not to bash Typer, but I think all projects have this problem.
12:22 They'll add a new cool feature and it's cool, I want to use it, and it's not in the docs yet.
12:26 That's a tough one to keep up on, but please do.
12:30 One thing I'll say that is actually hard for Python is because it's so dynamic, it's hard to actually get a static list of all the API points.
12:37 But one thing I will say, because Paul Everett says I have to bring more Rust to this podcast, 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:52 So you can actually see how much coverage you have in your documentation.
12:57 So--
12:58 >> That's an interesting definition of code coverage.
13:01 >> Yeah, it is. But I didn't even know about it.
13:03 Then I found it when I was just double-checking everything, built okay for a project I will mention later in my extras.
13:10 I noticed it was 100 percent.
13:11 It's like I thought I covered everything and I went back.
13:13 It's like, nope, there were actually a couple enum values that I didn't document.
13:18 I was able to go back, do that, and make sure I had full 100 percent coverage of my stuff.
13:22 It can be handy, but yeah, it's tricky in Python, where it's like I could auto-gen my whole API, and no way to know whether or not--
13:29 >> At runtime and never have it hit disk, yeah.
13:32 >> Yeah.
13:32 >> Last couple of things, docs should be easily accessible and browsed, and hopefully a search feature or something, even if you attach Google search, 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:56 I'm on the fence on that.
13:59 I'm usually attached to the Internet, so looking stuff up isn't a bad thing.
14:03 Easy to contribute to, the lastly.
14:06 >> Yeah.
14:07 >> Yeah, documentation stuff.
14:09 There's a lot of stuff, it's hard to get it right.
14:11 There's a lot of stuff I'd add if I was being more verbose, but the last thing I really want to add to this is, don't slam projects that don't have good documentation because it's hard.
14:21 If you want to have it be better, then contribute, fix it yourself.
14:25 - Yeah, 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 doc string and some notes, otherwise it quickly gets out of hand." Yeah, it's definitely one of those things that if you had to sit down and write it all at once, it would be dreadful, but if you can kind of do little bits as you go, then for sure, right?
14:47 Brandon Brainer says, "Your documentation update should be part of the ticket or even better, your definition of done for the ticket." Right, 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, if, bonus if your documentation includes animated GIFs or emojis.
15:04 Yes.
15:05 Yeah, those are awesome.
15:07 We'll probably leave it there for that one, but that's great.
15:09 All right.
15:10 - So one interesting thing you could actually do is if you really want to push this, is if you keep your documentation in the same repository as your code, you could, I'm going to use this from GitHub.
15:20 I'm sure GitHub has equivalents, but you could probably set up a GitHub action.
15:24 Actually, I know you can, 'cause I've written the GitHub action to do this, to actually have your checks, your status checks on your PR fail if there are no touch docs and have to opt out of that check, right?
15:37 - Yeah, interesting. - I actually have a GitHub action I wrote called check for changed files, and you could write a requirement saying if you change any .py file, an equivalent .rst or .md file must be changed somewhere in the PR, and if it's not, have to add a skip docs labeled to make a pass and otherwise let people know very explicitly, "Hey, we care about our docs.
15:59 You can't just opt out of it.
16:01 Please make sure everything's up to date." >> Fantastic.
16:03 >> There are ways to really push this pretty far if you really want to go for it.
16:06 >> Yeah. Have robots be mean and say, "No, you haven't finished your PR yet," rather than the maintainers.
16:12 Yeah. All right. Tell us about this next one, Brett.
16:15 >> Yeah. Once again, more rest on this podcast due to Paul Everett demanding it.
16:20 I've noticed there's been a slight theme the last couple of episodes of talking about ways to 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, and I believe Brian's now mentioned Oh My Zeesh, I thought I'd just mention what I use for all my prompts, which is Starship.
16:40 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 built-in.
16:52 And what you do is you basically turn the model off, configure them one way or the other, and then there's a one line activation you just put in your code, and that's it.
17:01 Configuration's done by a TOML file, starzip.toml, and then it just works.
17:07 There's no mucking about.
17:08 It doesn't matter what shell you're on, 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 tools, which leads to me playing with different shells.
17:20 Probably by the time Paul Everett tries out Phish, I'll be trying out New Shell.
17:24 So because of that, I wanna make sure that I can bring my shell with me very easily.
17:29 And Starship, for instance, has support for Phish, and Zeesh, and Bash, and all of them, and New Shell.
17:33 So I can very easily try out a different shell and not feel like I'm in a foreign country where the prompting is gibberish, right?
17:42 Like I always hate it whenever--
17:42 - It seems like, oh, my Z Shell go onto Z Shell, and oh, my Posh go onto Posh, and you're stuck on that specific one, right?
17:51 - Exactly, and there's oh my fish, pretty much every shell has an oh my something or other to tweak it out, but with this, at least for my prompt, which is actually what I see the most, I don't know about the rest of you, but my prompt is what I interact with more than anything in my shell, not the extra fancy stuff I put in, it's this.
18:08 And so this is why I really appreciate this project.
18:10 - Yeah, go ahead.
18:14 - Go for it, it's just--
18:15 - Well, what I like, we're seeing on the screen here, if you go to the starship.rs site, you can see like a little animated GIF and props to them for putting that on there.
18:23 That is fantastic.
18:25 - 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 versioning things.
18:35 Does it have a 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 PyM support.
18:44 But if you use the Python launcher, I actually have an entry on it in the FAQ for the Python launcher to tell it how to use the Python launcher to automatically tell you what version of Python's being used.
18:55 And then you can configure the Python configuration to say, what should I trigger on for it to be considered a Python project?
19:01 And it has a default list that's pretty good, like pyproject.toml, setup.py, setbox.cfg, the things you would expect any repo or workspace or whatever to have to be a clear marker that there is Python that I care about here.
19:15 And then the other thing is, is there's also a way to, if you use PY, you can also have it set up to auto trigger as long as you just have like a .vim directory, for instance, that contains your 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 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 'cause it will always tell me exactly what will happen if I just type PI.
19:42 Oh nice, yeah, yeah, this is awesome.
19:45 - And I know nerd fonts have been mentioned previously on this podcast.
19:49 You'll notice that it has nerd font support, so if you get that installed, there's extra little fancy bits to it.
19:55 You don't have to have it installed, a lot of those things will either turn into mojibake or you can just turn them off.
20:01 - Yeah.
20:02 - But there's all sorts of stuff that this thing does.
20:04 There's even real nice little subtle details, like if you use Starship, and if you're watching the live stream, you'll notice that the prompt is green.
20:12 when the last command succeeded, but if it fails, it turns red.
20:16 Like there's real nice little subtle touches to this tool that I really appreciate.
20:19 - Yeah, I really like it too.
20:21 It looks great.
20:22 - I'm gonna try to check this out 'cause I'm always using, I got some tools that I have to run from the command prompt, but most of the time I'm in Bash or something else.
20:33 - Yeah, very nice.
20:34 ZDocs says, "Using multi-line shell prompts "and FZF are two of the better productivity improvements I've ever done.
20:42 I've highlighted that specifically 'cause I really like these multi-line prompts.
20:47 It has all the details and then the prompt is below it, but I can't bring myself to use them yet.
20:52 I don't know why.
20:53 I'd rather have it more densely packed on one line.
20:58 Where do you two stand on this?
20:59 - I used to be that way.
21:00 Actually, I used to be a Zs user before I became a Phish user.
21:05 And even before this, I used to use left prompt and right prompt, and I had a consistent left prompt, which was basically just the greater than symbol.
21:14 Then I had my current working directory as my right prompt.
21:17 That at least the cursor position never shifted.
21:20 I don't know about the rest of you, but I always find that.
21:22 That there's something nuts like where's the start of my prompt now after I changed my directory.
21:26 Having that as the right side was great.
21:28 But then I saw this and I was like, okay, I've never loved this, but this is so nice and set up across the board for everything that I consistently use like Rust, Python, NPM, whatever.
21:42 I was like, okay, I'm gonna give it a shot.
21:44 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, 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 my dot file set up so that my default Bash or C and all that, if I end up on a random machine, at least has that kind of prompting, But as soon as I'm on any machine where I know I'm going to be a fully set up environment, I just keep on Starship. I just don't care. Basically, I get it, but this was just too many benefits and I just let it go. Now I just don't notice it. It just doesn't bother me.
22:22 >> Yeah, now you're used to it.
22:23 >> I think I'm going to try to embrace it, just run with it.
22:26 >> Honestly, the resolution on all our screens is so high now compared to what it used to be back when I picked up that habit that the lack of vertical density, maybe it's because 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.
22:40 I suppose that like a 32 inch 4K monitor, I could probably fit a 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 to be able to kind of scroll up and see where the beginning of your line, your command started.
22:59 Because it's like an HR, a horizontal rule.
23:02 Yeah, exactly.
23:04 - Yeah, final thing, Jeremiah Page out there in live stream says, "Starship is great, "but I think you need nerd fonts for some of the plugins." Hold that thought, 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 for like a branch next to the get stuff.
23:20 If you have the power monitoring one that tells you like your battery's low, it uses nerd fonts to show that, but Michael's foreshadowing something coming later.
23:27 - Yes, indeed.
23:29 All right, 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 packages and then we have to speak them and we've never spoken to the person who creates it or named it.
23:43 So we always, I'm sure we wreck the names of so many packages and let's just do a blanket apology.
23:49 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, this is another new thing I'm starting to really like, allows you to declaratively 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 to a dictionary and then traversing it with indexes and keys and such, there's a whole lot 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 a key foo and then inside there, there was another dictionary that had a key bar and then that had a value baz.
24:34 You could just say foo.bar and it'll give you baz, which is kind of nice.
24:38 You can also do that with arrays, although this is actually not doing anything.
24:44 It's just giving you back the list and then you're indexing into it, 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.bar a bracket star.name and it'll give you all the names out of the sub thing, the sub dictionaries 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 a negative indexing into it, which is pretty nice.
25:13 You can do star, like foo.star.name for hashes to get the values out, kind of like 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 and it was really handy for that.
25:37 So you look at this code and I'm sure, Brett, you're thinking that's not Python, right?
25:41 - No, actually, I'm wondering if the query syntax is the same as JQ.
25:45 And do people know what JQ is when I mention that?
25:47 - I don't know what JQ is, yeah, interesting.
25:49 - So JQ is-- - Yeah, go ahead.
25:51 - 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, more or less use the same kind of syntax as the query selector and the browser for CSS selectors, and query your JSON. I think it's meant a lot for like tools if you're using like Httppy or curl or whatever to query some like REST API that's going to give you back JSON and then to try to find something out of it. And it looks pretty similar, so I'm thinking that this is maybe be kind of just a Python packaging approach to the same syntax, which is neat because it means if you know one tool, hopefully it'll work for the other.
26:28 - Yeah, right, 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, and then you give it a string, which is these things I've been describing, and then you can tell it to 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, you can have things like unique letters.
27:02 And what you could do in there is say, given a string, I would like to do a set on the string and then turn it back into a string.
27:08 So it only shows you the letters involved, not necessarily, you know, with duplication, right?
27:15 And so then if you create that, then you can do things like when you do your search, you do food up bar pipe, unique letters, and you pass the parameters over, and it'll give you, you know, basically the result of those values, but then applying these transforms and stuff to it.
27:28 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, people can check that out.
27:41 All right, Brian, over to you.
27:43 Yeah.
27:44 I was, wanted to cover, this was announced last week, I I think there's a tool called pedal board.
27:51 This is a library came from that comes from Spotify.
27:55 And it's for manipulating audio files.
28:00 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 A DAW.
28:17 >> I don't know. What do you use?
28:19 I use Logic Pro usually.
28:22 Something like that would be it.
28:24 >> Yeah, I use Adobe Audition.
28:26 >> 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 It'd be neat to automate that.
28:34 Things I'm thinking about are things like a compressor or a high-pass filter, low-pass filter.
28:38 But this thing has a whole bunch of other transforms.
28:41 You can do convolutions and chorus, and some distortions, and gain if you want to make it louder, some reverb, a high-pass filter.
28:51 Then stuff, I don't even know what it is, a ladder filter, I don't know what that is.
28:54 >> I don't know what that is.
28:55 >> Phaser, that sounds neat.
28:57 >> I don't know what that is.
28:58 >> Scotty.
29:00 >> I definitely want to try that out.
29:04 If you're working with audio files, I think it would be a fun thing.
29:08 We've linked to the GitHub repo for it, which is nice, it's completely open source.
29:14 It says it also has some cool things like plugins for VST3 and Audio Unit, which I have no idea what those are.
29:23 But also, one of the things with audio is it takes a while.
29:29 There are speed enhancements in this.
29:32 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, and I got to warn people.
29:43 There's an image at the top which totally messed with my head.
29:48 Because it triggers me with all the different flashing colors.
29:53 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:59 Some graphics and I don't quite get.
30:02 There's some graphics on how it works 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 sounding good, actually.
30:13 >> Yeah. So important enough for me that I've got a hardware noise gate in my studio.
30:19 >> Yeah. Nice.
30:20 >> Anyway, cool library. Check it out.
30:23 >> Yes. If you want to do audio transformation, if you want to basically write Python code that does like audition or the one you said, Brian.
30:31 >> Well, I mean, and especially with automation.
30:33 So if you've got a whole bunch of files you're dealing with, and you want to make sure that they're all the same level, You definitely want to automate that and not try to, and I know there's ways to automate with some of your other tools too, but it's 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 I accidentally left in the readme.
31:02 Just to give feedback to people, trying to fix documentation is always appreciated, and it's usually something you can do pretty quick, especially with either the pencil editor in GitHub or just hitting the dot to use github.dev 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 That as we all know, lots of docs is 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 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:39 He's just saying, I accept.
31:40 Okay, you fixed it.
31:41 Thank you, 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, it took me a while to see that.
31:48 - Yeah, well, I mean, some people ask me, like, how do you have so many contributions to so many repositories?
31:53 That's how, 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, not all of them do, 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:11 - Wow, that's awesome.
32:12 - 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:22 So I'm gonna 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 lock file format for Python.
32:36 It seemed like it was kind of a gap.
32:37 We had where every multiple tools were trying to solve the same problem, and that felt like something that we should try to avoid if possible.
32:45 Coming from speaking as the dev manager for the Python extension for VS Code, having each bespoke tools such as pip and poetry requirements of text 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, 'cause we gotta make sure that they're, we know how to use their API, what they report out is consistent, that they don't change it, 'cause not all tools consider their output of 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, decided 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:32 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:48 Originally it was me, Pradyun and Zuping from PIP.
33:52 We came up with a lock file spec, and then we invited Sebastian and Frost from Poetry and PDM respectively.
34:03 And they said, "That's not gonna work for us." And we said, "Why?" And it's like, "Well, your lock file "was defined very specifically for a certain platform." Like think of wheel tags, right?
34:12 It says what 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." 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, Sebastian wanted to make it so that it didn't matter.
34:33 And actually, I've heard a good example from Produne where it's like, if let's say you're doing PyWeek, right?
34:38 And you're doing a game.
34:40 If you're, you might be developing on Linux, but if you want to give it to your teammate who you're working with during PyWeek, and they're on Mac, 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 nother place or Windows or whatever, right?
34:54 So there is a use case there for platform agnostic log files.
34:58 So we tried to add that back in.
35:00 We took this public to discuss.python.org where all the packaging discussions happened 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 nother discussion, right?
35:17 About people going like, okay, the clarification, 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, 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, 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 wanna make is, you hear people sometimes go on about, oh, I really want lock files, right?
35:54 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:04 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 was so positive." I'm like, "Okay, cool." It's surprisingly hard to make this stuff work.
36:14 Everyone thinks it's a snap your finger, someone has an idea, you just get it done.
36:19 But there's a lot of use cases here, and especially with packaging.
36:22 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:28 Brian's been really great about having me and other people come on testing code for instance specifically to talk about this past packaging stuff to keep people up to date.
36:36 There's a lot going on, but 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:46 Everyone's got their own workflow at this point.
36:48 30-year-old language that's had some form of packaging for like over 20 of it.
36:53 Everyone's got the way they want to work and no one likes to have it changed on them, especially your workflow.
37:00 Try telling someone who's using VS Code, yeah, we don't think you're doing it the right way.
37:05 Does not fly.
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 in Python.
37:17 Not only is Python challenging on its own due to the amount of C code, Fortran code, All the crazy stuff that people used.
37:23 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 asked for, 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:38 Please try to be understanding on Twitter or wherever else you're going.
37:42 Oh my God, packaging Python so bad.
37:44 >> The places where outreach was really hard.
37:47 >> Yeah. That's what really here.
37:49 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 >> These will be independent of things like Poetry and pip and just pip and stuff like that?
38:03 >> If we're lucky. The key point here is we can't require this, 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 all packaging tools must use this.
38:19 The idea with all this has to be, what's the carrot for the tools?
38:23 How are we making things better both for the community but for the tools themselves?
38:26 Now, 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:35 It's trying to make the tools happy because then eventually the users also become happy.
38:38 We'll have something.
38:40 At worst, my suspicion is, at absolute worst, we'll have platform-specific log files come out with this pep.
38:45 But my hope is being a 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:53 >> Nice.
38:53 >> But the key point here is, it's being worked on, it's taken a long time, it's going to take even longer.
38:59 Understand that when people say, "Oh, why can't packaging get better faster?" It takes a long time.
39:05 Literally, I've been working on packaging as my focus for Python stuff for years now.
39:10 It's not a fast process because there's a lot of people involved, a lot of projects, everyone has their needs.
39:16 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. 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:31 Sorry, I couldn't resist.
39:35 No, I think things are getting better and I like the direction.
39:40 >> Yeah. 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 same after that.
40:06 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, and I've just been trying to plug it.
40:20 This is probably the last one, because more or less this takes care of the pip tools, pipm, poetry, 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, 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 >> 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 C, Python interpreter distribution kind of solution.
40:53 So is the new pep going to be 666 or was that already taken?
40:57 No, it, actually 666 is taken.
41:02 Okay.
41:03 It's been taken for over a decade.
41:05 It, it was purposely done to be immediately rejected.
41:08 Cause it said you should be a low mixed tabs and spaces.
41:10 So that was written to make people stop asking for that.
41:12 and got rejected immediately.
41:14 - Okay, okay.
41:15 - But no, I'll just, since this didn't get accepted, I'm just gonna rewrite it in place.
41:21 The goals are the same.
41:22 There's no need to have to do yet another pep.
41:25 So since it's draft, I'm just gonna basically just get it and redo it.
41:28 And since the goal's the same, I'm just gonna reuse the number.
41:31 - Okay. - Nice.
41:32 Well, thanks for working on this 'cause it definitely is important.
41:35 - Yeah, 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 wanna lock things.
41:42 -Brian, back to you. -Back to me?
41:44 -Oh. -For extras.
41:46 -Oh, for extras. -You got any extras?
41:48 Yeah, so I've got one. I'll throw it up.
41:51 So, 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. -Or three, even.
42:03 -Exactly. -So, there's an article on ZDNet.
42:08 Python is on the verge of another big step forward.
42:11 >> The big step forward apparently is the Tyobi index.
42:18 Let's see is the number one language, but Python only needs 0.16 percent more to become the number one language, according to this index.
42:28 >> So are they arguing that if we got to the top of Tyobi that would cause another spike in usage?
42:34 >> I have no idea. No, another spike in the usage would cause this to happen maybe, I don't know.
42:39 Oh, I don't know.
42:40 Yeah. Yeah.
42:41 So I think historically, only C and Java have ever had that designation.
42:46 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, one more thing.
42:53 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:02 And the 404 has the cheese sketch embedded in it.
43:05 Yes, the cheese shop sketch is at the bottom.
43:07 And piece of history, PyPI was originally supposed to be named the Cheat Shop. It was actually originally supposed to be, it was actually originally cheatshop.python.org, but people were too concerned that managers wouldn't take Python seriously if the package index was named after a mighty Python sketch. So it got its name changed.
43:24 - Yeah.
43:24 - Cool.
43:26 - Right, looks like you got some extras as well.
43:28 - Yeah, well, I mean, this is Python Bytes, so we couldn't go an episode without mentioning Will, although I think wills out in the live stream.
43:35 So this is also more of the Paul lovefest on here.
43:40 So Paul had, will go on to an episode to talk all about textual and rich and how it's all structured, mainly textual.
43:48 I believe Will tweeted that he got a haircut for this and everything.
43:52 I actually haven't watched it, but as I said, it's not Python by itself, well, it doesn't get mentioned.
43:55 So I just want to make sure we all got called out.
43:58 I will also say that it has been 30 episodes I was last on, which I thought was kind of a nice round number. But on that episode, I mentioned that I was working on the Python launcher for Unix. And since over the last 30 episodes, I've actually wanted to mention that I had launched version one. And thanks to Brian and Michael for feedback, because actually, one of their feature requests got into it. The one thing I did want to call it that actually did happen recently is the launcher is now actually in Fedora. So one of the first things that got contributed was someone actually put Arch, it was actually Bernat Gabor of Talks fame, got it into Arch via AUR. I don't know how Arch does community versus not, there's a whole thing, but you can install it via Arch. But just the other week, managed some very nice folks from Fedora were nice enough to get it in. So you can actually now use DNF to install the launcher on Fedora. And then all the previous tarballs are all there as well. 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:05 Congratulations.
45:06 - Thank you.
45:07 - Good work.
45:08 - One of the, I'm pulling out Michael extra, extra, extra, extra at the end.
45:12 I will say that my syntactic sugar series is still going on.
45:17 When it's done, I'll probably have a wrap up thing.
45:19 And this is probably gonna be what my next set of talks will be all about, but they're still happening.
45:24 One interesting thing, I actually just did two, just in the last two days.
45:28 They were short.
45:29 Actually, oh God, I didn't realize I published three in a week.
45:32 That's a lot for me.
45:33 I did have one that didn't work.
45:36 So if anyone's any curious what happens when I can't unravel a piece of syntax, you can read that blog post to see how I put in all the effort to do it and then realize the day after, oh yeah, that's not gonna work.
45:45 - I did enjoy that.
45:47 - Oh good, yeah, yeah.
45:49 Assignment expressions continuously break me in various ways.
45:52 So there's a bunch of syntax I can never undo 'cause of assignment expressions.
45:54 They're handy, by the way.
45:55 I've used them since the month after we approved them, but they do make unraveling our stuff hard.
46:01 Then for Brian, I just wanted to call out that in our last release for the Python system for VS Code, we completely redid our UI.
46:12 VS Code now actually launches with a built-in UI for testing, and we integrated directly into it.
46:21 Now you have consistent UI for testing.
46:24 like a test tree result type of navigation thing.
46:27 That's yeah, well, and we had that before actually, but it was bespoke to our extension 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 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:46 There's some extra niceties to it as well in terms of updates and all that.
46:51 It's really snappy.
46:53 We'll probably we are also going to rewrite all the code behind this and how it runs to make it a bit more performant, more stable and all that.
47:00 So if you've had UI problems before with testing with VS Code for Python, please give another try. If you've had more discovery run problems, we are going to be working on that, so that's coming up as well.
47:11 And then when that's all done, will be bugging Brian about this to make sure he gets the Bryant.
47:16 Stamp of approval. Yeah, you know, I charge for that, But 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 and I'm excited to see the discovery changes as well.
47:33 Yeah, well, we reached out to the Pytest team directly actually and asked them like what would you 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 unit test.
47:47 UnitTest is UnitTest.
47:48 Unfortunately, we had to drop no support due to this, but honestly, it was extremely low used anyway.
47:55 But we did have Let It Go.
47:56 But we still have UnitTest by default.
47:58 >> People shouldn't use it anyway.
48:00 >> You heard it from Brian. Don't send me the hate mail.
48:04 But yeah, that's it.
48:05 >> Nice. Those are all great ones.
48:07 I now have banners to separate my sections.
48:10 >> Oh, that's awesome.
48:11 >> Nice.
48:12 >> All right. I'll be quick.
48:13 I do have a couple of things.
48:14 I just want to go back and sort of talk more about nerd fonts 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 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:33 So you go over and check these out.
48:36 They all, 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, although they freaked me out when I first saw them.
48:44 I'm definitely a fan.
48:46 I'm actually a fear code user.
48:50 Exactly, yeah.
48:51 Although the new literature support for infinite arrow length throws me a bit sometimes to the point that I actually have turned it off and I use Cascadia code the nerd fought version for Starship in my terminal.
49:04 So I actually have a separate font for terminals in here.
49:07 Yeah, cascade right there.
49:09 Cascadia Cove here.
49:11 It's Cascadia code on the official.
49:15 So yeah, I use Cascadia for my terminal and then I use Fira code for my editing, although I'm contemplating actually buying a font called Mono Lisa, M-O-N-O-L-I-S-A, and using that, but I haven't pulled the trigger yet.
49:33 I'm not against buying fonts if they're amazing.
49:35 Yeah, neither am I. It's $100.
49:37 Armand Rohnacker actually uses it.
49:39 That's partially how I came across it.
49:41 And someone else recommended it somewhere.
49:43 Kushal Das, based 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:51 And it does have a lot of shared support.
49:52 - Good, yeah.
49:53 All right, 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'm not using nerd fonts.
50:05 If people are just listening, there's just tons of squares where there 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, actually I guess is what it 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 if you're just a, yeah, just use whatever Mono thing is built in.
50:38 Yeah, the nerd funds are cool.
50:40 All right, let's see what's next.
50:42 Oh, did a article interview, this company in Russia interviewed me if people are interested.
50:48 I wanna 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:54 Moreshell, Henry Schreiner III shared with us, here's my setup process for setting up a new Mac.
51:04 And there's all these cool scripts and brew setups and all sorts of things, including all the fish shell and Vim setups that you might need.
51:13 So if you wanna follow up, we talked a little bit about that last time, 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 if you use Codespaces, GitHub, and you check a box, Codespaces will automatically clone your dot files repo and load them up into your Codespaces.
51:32 - Ooh, that's nice. - Ooh.
51:33 - Yeah, 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 in this podcast, but when your laptop accidentally gets grabbed by someone else and ends up in Dubai and it gets shipped to you to a core dev sprint in London later and you feel the need to wipe it for security purposes, it's very convenient to have all your stuff in the cloud and have your dot files in a repo, so it's just a clone run and you're done.
52:01 Yeah, 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. A couple of 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.
52:19 But I basically everything that I have some kind of terminal command for is I've almost entirely set up some 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:38 >> All right. Well, I think that's it for extras.
52:41 >> 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:47 >> Nice.
52:48 >> I hope this is not as funny as the joke, but you all will be the judge.
52:52 >> Okay.
52:53 All right, so this is going back to a solid place.
52:56 Geekandpoke over at geek-and-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 re-installing everything, right?
53:08 So this is the last 5%--
53:09 I know where this is going.
53:10 For corporate IT made easy, make sure that the new developers notebooks or computers aren't only 95% provisioned.
53:18 So there's a senior woman developer helping a new one who can't seem to compile the project or run it or something says, I had the same problem, but I barely remember somewhere in a wiki or on a file server, there was a certificate or something like that, and I had to copy it to some folder on my machine.
53:36 It's just entitled the last 5 percent.
53:39 >> It's like anytime someone onboards under your team at work.
53:42 >> Yes, exactly.
53:43 >> Go read with the last person five years ago or two years ago, or however often you get a new person come on.
53:48 Did it, and by the way, process of all change. So yeah, chances does not work.
53:52 Yeah, just scroll back two years in Slack or Teams and find that message where we talked about it.
53:56 Yeah, it's a little.
53:57 You just have to hire people more often so that they update the wiki at least every few years.
54:04 Yeah, but the question then becomes, is it because your head counts growing or because your turnover is so high and that you're just a bad manager and this everyone keeps quitting the team?
54:11 Yeah, I'd rather just have a stable number of people who, by the way, told me they were going going to be on the live stream and I didn't see Michael let any other comments by so I wonder if they actually showed up.
54:20 So hello to my team if they showed up.
54:22 And if she did, you know, 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:35 Definitely.
54:36 Cool. Well, that's it.
54:37 So thanks a lot, Brett, for showing up.
54:39 Of course.
54:40 It's great to have you.
54:41 Thank you to my cat for taking a nap during the entire podcast and let's not distract 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:50 >> Perfect.
54:51 >> It's great to have you here. Thanks everyone. Thanks Brian.
54:55 >> Thanks guys.
54:56 >> Thanks for listening to Python Bytes.
54:58 Follow the show on Twitter via @PythonBytes.
55:01 That's Python Bytes as in B-Y-T-E-S.
55:04 Get the full show notes over at PythonBytes.fm.
55:06 If you have a news item we should cover, just visit PythonBytes.fm 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 live stream 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 Aukin, this is Michael Kennedy.
55:29 Thank you for listening and sharing this podcast with your friends and colleagues.