Transcript #187: Ready to find out if you're git famous?

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to

00:04 your earbuds. This is episode 187, recorded June 17th, 2020. I'm Michael Kennedy.

00:10 And I am Brian Okken.

00:11 And this episode is brought to you by us. There's a couple of things that we're offering that I think

00:16 are going to be great for you. We'll talk more about that later. Right now, I want you to bring

00:20 us back to our youth, Brian.

00:21 Did you ever do the Lego Mindstorm thing?

00:23 No, no. Lego was just bricks when I was a kid.

00:28 Yeah, well, yeah. Okay. I love Legos. And I'm actually, I've got like three kits halfway done

00:34 right now. One of them I've been working on for a long time. I should finish those. Anyway,

00:38 because there's a new one I want to buy. It's not out yet, but Lego announced Mindstorm Robot Inventor.

00:44 They've had different Mindstorm kits in the past for robotics, and they started in 2006,

00:50 or at least on the Mindstorm series. NXT was in 2006. They did an NXT 2.0 in 2009.

00:57 And then the EV3 was in 2013, and I was actually kind of disappointed with the EV3 because

01:02 it was weird. It was like a post-apocalyptic thing going on. It was like punk rock robots or

01:08 something. I don't know. Anyway, so I think we've got an NXT somewhere in the house. But the new Mindstorm

01:13 Robot Inventor, they finally figured out that people are using these things to try to teach in STEM

01:19 education and stuff. And so the new one, this is awesome. Drum roll. It supports Scratch and Python.

01:26 So that is super awesome. It has instructions for five different robots that do lots of different

01:33 kind of cool things like a car-like robot and an upright-like robot. And there's a bunch of sensors.

01:40 The module that it has connects to six different input-output ports for sensors and motors.

01:45 There's even a six-axis gyro and accelerometer, a 5x5 LED matrix. 5x5 is not much, but we can probably figure out.

01:54 We can hack more. Color sensor and distance sensor, of course, and Python. So one of the other neat things

02:00 about it is the other one, I'm not sure about the older ones, but they were programmable,

02:06 of course, with Windows or Mac. But this one also is going to have the ability to program it via

02:13 an Android or iOS tablet or smartphone and even some Fire OS. So like the Amazon Kindles,

02:21 some of them might be able to be used, which is pretty awesome because even though this robot

02:26 inventor is pretty expensive, if a school's helping to support it or something and a kid has a $50 tablet

02:33 at home, hopefully that'll work. So that's neat. Yeah, this is really cool. And I think being able

02:38 to program with a real programming language instead of a blocky type of programming language goes a long

02:43 ways. I think people underestimate how much kids can do with some simple text versus, you know, like,

02:50 well, it's got to be drag and dropy, so don't ever make syntax errors. And, you know,

02:55 if you look at things like codecombat.com, kids go through these dungeons and they solve, like,

03:00 challenges to open the door, make it across the bridge or whatever with code, but it's all typing

03:07 Python. But the editor is so insanely aggressive, in a good way, aggressive with autocomplete. Like,

03:15 if you type A, it'll try to autocomplete hero.attack and suggest arguments. I mean, it's like ridiculous.

03:22 And in those sorts of scenarios, I feel like, you know, don't pull the punches. Like, give the kids

03:27 a real experience. They'll adapt pretty quickly. I think people underestimate with the right tooling,

03:32 what kids can do with a text language like Python.

03:35 Yeah. And I, so I really hope, I think so too. And so it's exciting to have it. I know you can't,

03:40 there were ways to put control of the EV3 with Python, but it was extra hacky ways and not obvious

03:46 for people. And so hopefully having this supported. And I really hope that we get more of these sorts

03:51 of robot inventor things coming out from Lego. Not every seven years. Could we update maybe every

03:57 couple of years? That'd be awesome.

03:58 Yeah, for sure. Technology changes fast.

04:01 Yeah. And on a related note, I didn't do this as a full story, but I wanted to note,

04:05 I also saw a project called Microscopy or Microscope Pi, maybe. It's an IBM open source project

04:14 to build your own modular microscope using Raspberry Pis and Lego bricks and a little bit of 3D printing.

04:23 And you can control it or like a motorized microscope, which is pretty awesome. So that's

04:28 neat too.

04:29 Yeah. Yeah. That's really cool. All right. Well, I have a theme that will become clear as I go through

04:34 my items this week. I first somehow, somehow it just landed, lined up with all the items I picked

04:39 in the same general area. So I want to start off by talking about this article from Kevin Markham

04:43 from dataschool.io. And he put together, he's been putting together lots of cool steps and guides to

04:49 help people get into stuff. His area is mostly data science, but obviously in the Python side.

04:54 So he created this thing called a step-by-step guide to contributing to GitHub.

04:59 Nice.

04:59 Yeah. So if you're new and you haven't actually yet contributed to an open source project, it's like,

05:05 here are the 17 steps in order. And some of them are obvious, like you have to have a GitHub account,

05:11 you have to fork the project. Others are not as obvious. Like I always, whenever I fork something and

05:18 I'm like, Oh, you know, I really want to get the changes from the thing I forked merged, you know,

05:23 sort of synchronize my fork with the remote fork. I'm always like, what is that command again about

05:28 like remote origins and for upstream, I got a set, you know what I'm like? And so having that stuff all

05:33 laid out in a nice little, do this, then this, then this guide is helpful even just for a couple of

05:38 those steps, if you've done it before. So, I'll just run you through the steps really quick.

05:42 People can go and see the pictures and the graphics and the explanation. But,

05:46 so I want to contribute to something. I think he contributed something back to scikit learn,

05:50 but it could be any project, right? So you start by figuring out what project you want to contribute

05:54 to. You fork it to your GitHub account and then you check it out. You clone it locally and load it up,

06:02 make some changes. And then you make sure you have your origin remote pointed back to the thing on

06:07 GitHub. And then the part I was just talking about, you can add an upstream remote, which allows you to

06:13 say, give me the changes from the source repository to my forked version. You always want to get those,

06:19 like maybe forked it a while ago, but now you want to make a change. So you want to grab the changes

06:23 from the upstream, the original repository and bring it over, create a new branch, a feature branch for

06:28 your changes. Cause you're going to use that for a PR, make changes, commit your changes, push it to your

06:33 fork, create a PR by clicking the green create PR button, review the PR, have conversations around it, maybe make

06:40 some more commits to your pull request. So it talks about like, if you submit a PR and they're like, that's great,

06:44 but you need unit tests. How could you forget the unit tests? Please add those as well. How to do that. Right.

06:50 It's a common story. I'm sure discuss it. And then once it's merged or I guess closed, even you could

06:56 delete the branch, but especially if it's merged, you don't need it anymore. So delete your branch,

07:00 synchronize again, your fork with the original project repository through the upstream link,

07:06 because once they've accepted your changes, your main branch will be out of sync with there. So you

07:13 want to do that. And then also as a nice little tips for contributing code section as well, with just

07:18 some advice on how it goes. So the pictures and like here, type this for the step. I think this is

07:22 pretty handy for a lot of folks. Yeah. People just need to do it. It seems overwhelming when you start

07:28 because it seems like, oh my gosh, this seems like so over the top. And actually, so at work, when we

07:33 switched from a different version control system to, to get, we started out with this sort of a model.

07:41 This is not an uncommon model, even within not just open source, but other projects. Originally,

07:47 I thought this is a lot of overkill. We don't really need forks and branches,

07:51 but there's a lot of benefits to doing both. And you can just kind of get used to it. And it's not,

07:56 it ends up being not that big of a deal. Yeah. One of the advantages for what you're talking about,

08:01 like inside your company, obviously it's important for open source, probably mostly because you don't

08:07 have commit rights. So you make changes to your thing and you say, accept my changes, right? But inside a

08:12 company, everyone has commit rights for the most part to their project they're working on.

08:16 But it bundles it up in documents. Like these are the changes to add this feature. These are the

08:22 conversations around it. And here's how it got accepted, right? It's like a nice way to go beyond

08:26 just like, here's a commit or a series of commits I did this week. I think some of them have to do with

08:31 this scrum thing I said I would do. Yeah. One of the main reasons we kept the fork model in place is so

08:36 that we can, if somebody accidentally pushes up a large executable or something that they shouldn't

08:43 have committed in the first place, it's easier to kill a fork off than a branch of a project.

08:50 I see. It's like a layer of insulation of mistakes.

08:53 Yep. Yep. Definitely.

08:55 Yeah. Cool. Well, before we get on to a new language, Python inspired language, I just wanted to talk about

09:02 a couple of things you can do to support the show. Obviously, Brian and I are both doing things outside the

09:08 podcast that we think contribute back to the community that if you want to support what we're doing, it would

09:13 be great if you could check them out and consider them as you're learning Python things. So I have courses

09:18 over at Talk Python Training. We have, I think, 170 hours of Python courses and probably a couple hundred hours

09:24 of exercises for people to do over there. So if you're looking for courses or to learn stuff with Python in general,

09:30 check out Talk Python Training. And Brian, you have some kind of book, I think.

09:34 Yeah. So I think that anybody that wants to learn how to test better should pick up a copy of Python

09:39 Testing with pytest. So the book that I wrote about pytest, it's not just, it kind of walks through all the

09:46 different sorts of things you can do in the, with pytest, but also around testing a package project.

09:52 And I think a lot of these carry over, even like switching databases and stuff, these things carry over

09:58 for all sorts of types of projects. And I've gotten a lot of great feedback and I think it's a good

10:03 thing for people to read.

10:04 Yeah. Awesome. It's a great book. And both of those things are linked at the top of the show notes. So

10:08 you all can just check it out in your podcast players. So I'm always fascinated with embedded Python

10:12 Python and things like MicroPython and CircuitPython. And you've got something along these lines, right?

10:18 Yes. I ran across this, a language called SNEK or SNEK, I think.

10:23 SNEK.

10:24 SNEK.

10:24 So it's at SNEK.org. And it's a Python inspired language for embedded devices. But my first

10:34 reaction is probably going to be yours is also, don't we already have that? Don't we already have

10:38 MicroPython and-

10:39 We already have two. I'm confused why we have two.

10:41 Yes. And CircuitPython. Well, actually, yeah, we've got lots. MicroPython and CircuitPython are

10:46 the ones that we think about a lot. CircuitPython, of course, is focused around Adafruit, but also

10:52 runs on lots of different other boards as well. But what about really small things? Even those,

10:58 they run on these small chips, but there's smaller chips that you might want also. So if you only have

11:05 a few kilobytes of Flash and RAM and you still want to run something, can you run Python? And that's

11:11 where SNEK comes in. So it's, I mean, it really runs on small processors. Even one of the things

11:18 it supports is the Lego EV3. So if you don't want to wait for the new robot inventor, you can run SNEK

11:25 on your current EV3. So that's neat. But the smallness, its goal is it's not Python. So most SNEK

11:33 programs will run in Python, but not the other way around. You can't run most Python in it. So it's got

11:40 a limited language. But part of that is an educational purpose. So a smaller language footprint,

11:46 as Python's adding more and more new features, it may be overwhelming for some people when they're

11:52 just starting out. So having a smaller language is kind of a neat thing. But all of that learning can go

11:57 towards your, if you're learning SNEK, you will can transfer that to Python projects later.

12:03 Right. It's easy to level up to Python because it's, it's like going from C to C++. There's stuff to

12:09 learn, but it'll kind of work. Yeah. Yep. There's even like a dedicated, a new board called the SNEK

12:15 board that you can, that is available. It was through a crowdfunding process, but it runs both

12:22 CircuitPython and SNEK. So yeah, one more thing to be able to run little small chips with Python-like

12:28 language. So this is neat. Yeah. It's really cool. And the very, very small devices, I think it's going

12:34 to mean, you know, Python can appear in more places, right? On incredibly small IoT things and whatnot.

12:39 Like even if you have larger though, I like the idea of people saying Python is just kind of a great

12:45 syntax. If we strip some of the things out that full Python has, it's still a usable language with a lot

12:53 of it stripped out. So I think it's a good thing. Well, that whole idea, I mean that we could go on and

12:57 on about that, but the whole idea is pretty interesting because as we see things like Python moving to web

13:03 assembly and running on the front end and talking about maybe having a Python on mobile,

13:08 as well as the traditional CPython that we know and Python on chips, like having this concept of a

13:14 smaller focused subset of Python that is universal. That's pretty interesting anyway. And it sounds like

13:21 that's a little bit of the philosophy here. Yeah. It is interesting. What are the things we see like

13:26 this coming up in the future? That's right. So we spoke about Git before and forks and using

13:32 forks as insulation, but have you ever made a mistake with Git? Like every day? Yeah. Yeah.

13:37 You're like, why did it, that thing get checked in? I told it to ignore it and now it's in there,

13:43 right? Yeah. Stuff like that. So Andrew Simon sent over a link and recommended a zine, a little small

13:51 book. A zine. A zine. Yeah. A zine by Julia Evans. She has a bunch in the programming and DevOps space.

14:00 And she created one called, Oh Shit, Git. And it's like, I'm learning Git and oh my gosh, something's gone

14:09 wrong. What have I done? It's cool, right? This is great. Yeah. So I want to be clear. This is a paid thing.

14:15 It costs $10. We have no affiliation with it, but I just liked the idea of it. So I thought I would

14:19 feature it. So basically it's this really short little zine book thing that explains Git fundamentals,

14:27 like what's a Shaw and why don't you call it an SHA? I don't know. Stuff like that. Right. And then it

14:33 goes into a bunch of how do I fix common mistakes? Like I committed to the wrong branch and other

14:38 fundamental problems or I have a merge conflict or I committed the wrong file or I ignored a file,

14:46 you know, and going back in time, right? Like we wrote the wrong code. The server is down. Everyone

14:53 is yelling at me. I know it worked yesterday. How do I get the server or something to go back and say,

14:59 just go back to the way it was. And we'll deal with it in a minute when things calm down. So like all

15:04 those kinds of stuff. So I thought this was kind of a cool one. And people who are like getting started

15:08 with Git, but they're, you know, they run into these things and it's a big deal. It's like,

15:12 oh no, it's a merge conflict. Now what? I'm stuck. Right. Or like I said, committed to the wrong file

15:18 or to the wrong branch or whatnot. I think this would be pretty helpful for folks.

15:22 I love that the titles of the different sections are the thing that went wrong. Like I committed to

15:29 the wrong branch. Exactly. Yeah. I tried to run a diff and nothing happened. I've emerged conflict.

15:34 I want to split my commit into two commits. I want to undo something, five commits.

15:38 And so on.

15:39 I got to make sure that this isn't a violation of my human resources things to buy this for

15:46 all of my employees, because I think everybody needs this. These things are great.

15:51 Yeah. Just put a little bit of black electrical tape on top of that middle word and then you

15:55 can hand it out.

15:56 It's a PDF. Maybe I, you know, get by five licenses and printed it five times.

16:01 Yeah, no, it's pretty good. It's like, I did something terribly wrong. Does Git have a time

16:07 machine? Yeah. So, it sounds interesting. Thanks Andrew for recommending it and Julia.

16:12 Cool work on the creative way to address Git issues.

16:15 Yeah, definitely.

16:16 So, what's the story with versioning? You guys got a beef with it?

16:22 Well, you know, I've kind of always had a beef with it, but I didn't really think about it. So Brett Cannon

16:27 actually asked a question on, it was interesting. He wrote an article that I read

16:33 recently called, why I don't like Semver anymore. Semver being semantic versioning.

16:38 That's the 2.1.0 style. Yeah. And like, like, as opposed to calendar versioning or, or, or what we

16:47 were, we talked about this earlier of zero ver. Zero ver is like a, a, even more negative version of

16:53 Semver. Yeah. So the interesting question is it's not straightforward as to what, so there's often,

17:00 it's like the first digit, like if we say X dot Y dot Z X is some major thing. So like some crazy new

17:07 feature, it's either a crazy new feature or it's a incompatibility with the old one. Like we're going

17:12 to change the interface. Right. When Django went from one dot something to two dot O they dropped support

17:17 for Python two, for example. And that was indicated partly there. Yeah, exactly. So what constitutes an

17:23 interface break? And that's what a lot of people think about. Well, what about if you add a

17:29 deprecation warning to something that you're planning on taking out in the next version?

17:35 Is that adding an extra warning? Is that a major thing or a bug fix or a minor thing? And that's

17:43 part of the discussion of most of us, I think would think that the, maybe that's a, either that's just

17:48 a bug fix or a minor thing. That's not a major thing. Right. And to me, it makes, it makes like no

17:53 different, there's no new functionality. Nothing stopped working. That seems like a super minor,

17:58 like it should change the very last number because it doesn't even add or change a functionality.

18:04 But it is adding a warning. So if I have come, if I'm, I'm running Python with, with the flag that

18:10 turns all warnings into errors, or if I'm running my tests such that, that, and that's like normal with

18:17 running tests is you turn all your warnings into failures so that you find them. Now you've, you

18:23 really did change the interface because I, to get rid of that warning, I have to go and either I need to

18:29 change to not, I need to not look at that warning or I need to change my use of that thing. So it is

18:37 kind of an interface break. Yeah, for sure. So that's part of his discussion is that it's not really

18:42 straightforward to say that what is a major, minor, or micro change, what that really is. It's a gray area.

18:48 There's discussion. And then also really what the observation that the, the three digits kind of makes

18:56 sense if you are maintaining three or more branches. So if you're maintaining a current branch, plus the

19:03 features you're working on the next one, that's a, another branch, plus you're doing bug fixes to the

19:08 current production one. So you've got like development going on in one branch and fixes in the other one.

19:16 And then, you know, minor things going on, you might have like even more branches that you're

19:20 maintaining at once for a large project with lots of people on it. That totally makes sense for small

19:26 projects and side projects and things where you're really, you're not maintaining a bunch of stuff.

19:30 You're it's one branch and you fix bugs. You're not planning on adding new features or if you are,

19:36 you know, well, I don't know. It's so infrequent that doesn't matter. Maybe two digits is enough,

19:41 just X dot Y, or maybe just one digit, because there's a whole, one of the reasons why a whole

19:46 bunch of people are at zero for is they're trying to not be backwards incompatible and they're,

19:51 and they're not going to add any major new features. It's a simple tool or something.

19:55 The other thing Brett brings up is basically you shouldn't depend on this stuff because it's nebulous

20:03 and wishy-washy. You shouldn't depend on the numbering semantic versioning to see whether or

20:10 not what versions of a new of a dependent project you're using. You should rely on continuous integration

20:16 and testing. So do a minimum version for the project you're using, but don't do a max and use your

20:22 testing to find out if there's any problems. Always do the latest one in that the version doesn't

20:28 really matter. You're going to keep ahead. And if your CI breaks, then you might have to pin your dependency

20:34 to earlier one. But also you should always pin your dependencies to specific versions and just use your

20:40 CI and testing system to see if you can move forward.

20:43 Yeah, absolutely. And if you use something like depend a bot or pi up or something like that,

20:47 it'll automatically look at your repository, increment those versions, run some CI if you have it set up,

20:54 and you'll know if it's acceptable or not. So you can get the system to tell you, hey, you should

20:59 update this pinned version and click here to allow it.

21:02 Yeah, I love systems like that. And it totally makes it so you can review it and go, yeah, that's good.

21:08 Often those just show up as a merge request that you just accept, right?

21:13 That's right. Yeah, very nice.

21:14 Yeah. So a good discussion about thinking about whether semantic versioning really is appropriate

21:19 for your project.

21:20 Yeah. So do you remember what the recommendation was? I scanned it and I didn't see like a super

21:24 clear like do this instead.

21:26 No, the end, there's a kind of a summary that I kind of like cribbed and put in our show notes.

21:33 Essentially, it's the try to pin the lowest version or pin your versions, of course, but have a low end,

21:40 but don't have an upper end and just test. As for using dependencies for your own version,

21:47 it really was, it should match your branching strategy really. So if you're really not supporting

21:52 three branches, three digit semantic versioning doesn't make sense. You can do two digit or one

21:59 digit versioning.

21:59 Yeah. Yeah. Pretty cool. All right. Carrying on with my theme, you want to talk about Git?

22:04 Oh, we haven't covered Git for a while, so that'd be good.

22:07 Yeah, for sure. So there's famous, like, you know, rock star famous, Julie Roberts movie star famous.

22:16 There's like maybe a step down, but still pretty cool. There's geek famous, right? Like on the

22:22 regular street, nobody would recognize you, but at a conference, you're kind of cool. I think probably

22:25 Gita Van Rossum definitely fits geek famous, right?

22:28 Yeah.

22:29 And then apparently there's Git famous.

22:30 Oh, is that, is that when you have like your pixelated face as your Git history?

22:36 It's really complicated, but if you time it just right, you can, yeah. No. So there's this project,

22:41 Bjorn Olson sent this over and said, Hey, you should check this out. It's, it's quick and fun and kind of

22:45 useful. If you want to go to a project and answer the question, who kind of created this or who mostly

22:51 worked on this? And I have this all the time. When I go look at these projects that we're

22:56 researching and covering, maybe I want to talk to the person about a question or something. I'm like,

23:00 all right, well, if I can go to the contribution thing and GitHub, maybe it'll show me, but that's

23:04 more of an over time and who's recently worked on it and stuff. So it's not super good. And if you're

23:09 not on GitHub, then obviously it doesn't help. So there's a thing called get fame, which is a Python

23:15 library. And the idea is you pip install get fame and then associate it with get, you have a new

23:21 command. You say, get space fame and it will go through and it'll like, look at all the commits

23:26 and all the people and how many lines of code were changes, changed and files and whatnot by everyone.

23:31 And then it'll give you a ranking of these are all the people who've contributed and here's how many

23:36 files they've changed, how many lines of code they've changed and so on. It's pretty cool. And it sorts them

23:42 by most popular, most largest contribution downward. That's cool. Yeah. And it's super easy. It's super easy.

23:49 Like pip install, get fame, get config and set an alias to fame to run the Python command. And they just type

23:56 get fame and it just goes and it uses the TQDM. I think that might be the right order. Progress bar,

24:03 you know, to show you its progress. I ran it on a somewhat large, somewhat large project,

24:09 small to medium project, I guess, in terms of regular software. And it found 596 commits and it

24:15 took seven seconds to do that. And it processed 76 files a second. That's pretty good.

24:20 Yeah. I totally like the idea, especially around a very useful for us when we want to talk to one of

24:26 the people that's really involved with it. Yeah, exactly.

24:28 Yeah. And like you said, often some of the most recent ones are valued, of course, but not major

24:34 changes to the library or something. Right. Exactly. So it's a little bit hard to know. So this kind of

24:39 gives you the historical view of who's really contributed to this project and how many lines

24:43 of code have they changed and so on, which is not always a great measure, but you know, it's still

24:47 interesting. Yeah. I totally missed the, my guess. I, my guess was it was an alias to rewrite get

24:53 blame because blame is so, I don't know why they named it that. I know. credit, maybe get credit.

25:00 It should be called credit. There's positive and negative credit, right? Yeah. Yeah. So it basically

25:06 runs get blame over and over and over on each file and then analyzes the file, the result of get blame,

25:12 and then builds out this, this history based on that. That's pretty cool. Yeah. Yeah. Pretty cool.

25:16 super easy to use if you're into it. And, that wraps up all of our items, Brian,

25:21 got any extras you want to share with folks? I wanted to thank everybody that's supporting

25:25 the show through Patreon because I went in and took a peek today and we have 26 supporters. And if you

25:32 want to, we have links in the show notes and also links on our site, if you want to help out the show

25:37 through Patreon, but you can also go to patreon.com slash Python bites and many people donate a dollar a

25:44 month. And that is awesome. Thank you. And if you go above and beyond and contribute a little bit more,

25:49 so I wanted to do a special shout out to those that are contributing more than a buck. So thank you,

25:56 Brent Kintzer, Brian Cochran, Bert Raymakers, Richard Stonehouse, and Jeff Kiefer all donating more than a

26:04 dollar. So thank you very much. Awesome. Yeah. Thank you guys. That really does help support cover,

26:09 things like editing and transcripts and all that kind of stuff. Now I have a quick follow-up for,

26:15 last time we spoke about dunder py packages and things like that to where you could set up,

26:22 I think it was pyflow we were speaking of, where if you interact with Python through pyflow,

26:27 basically it will use this node JS like behavior that is really still coming hopefully in PEP 5.8.2.

26:35 So after that, someone, it was Paul Everett who sent over a message and said, Hey,

26:40 did you know Kushal Das, who is one of the folks core developers working on this whole idea has a

26:46 little Python example, just a single Python file that you can use to basically implement this. And it

26:52 says, this would probably be really great for like trainers and students and teachers and stuff like

26:57 that to kind of sidestep the whole virtual environment story. Okay. That's cool. I got to try this out.

27:03 Yeah. So a quick little link to a working version. That's not just a whole overhaul like pyflow,

27:09 but a simpler thing. All right. Now this last one, Brian, this joke here, you know, wrap it up with a joke

27:14 as always, you've got to open it up because it's an animated GIF. Okay. First, let me ask you what shell

27:18 to use on your Mac. Bash. Bash. Okay. So I'm a, oh my Z shell kind of guy because I love like the history and

27:26 it keeps a really good track of all the stuff I've done. And sometimes I'll type like one or two letters.

27:30 I'll try to go back and I'm like, no, no, that's not, instead of just typing out the stupid thing,

27:34 I'll just go back and back. And so here's like this clear, like super bearded guy. Who's some kind

27:41 of sysad man, Linux exaggerated person, I guess you would say. And it's an animated GIF, right? The guy's

27:47 just clicking his finger, clicking his finger up, up, up, up, up, up, up, up, up. Shows him doing that,

27:51 doing it some more. Now he's got a drink. He's clicking on, he's drinking his drink,

27:55 clicking up. And then finally, he's so excited. Oh, finally. What does he say?

27:59 I knew I had that some, that LS somewhere in my history.

28:03 And eventually it just says, yeah, LS, right? He's up arrowed until like forever to just

28:07 soon enough to type LS.

28:09 Oh man.

28:10 Have you ever been there?

28:11 No. Cause I, what kind of key binding? Do you use VI key bindings?

28:14 No.

28:15 Okay.

28:15 Do you like a backward search or something like that?

28:17 Yeah. You can just search through your history to find the, find them.

28:21 But then you have to press more than just the up arrow. Anyway, people, this has got a cool,

28:27 a cool little animation cartoon thing. So I just linked over to comicstrip.com where,

28:33 where the title is definitely not lazy.

28:36 Yeah, definitely. You know, I was thinking about it. I don't even remember the key sequence to do

28:41 the searching. I would have to do it. I just, it's one of those built in muscle memory things now.

28:46 So that's right. Yeah. I was trying to remember it today and I couldn't remember it. I'm like,

28:50 whatever, up arrow, up arrow, up arrow. So yeah, pretty funny. All right. Well,

28:55 thanks for bringing all these items and sharing with everyone. Great to chat with you as always.

28:59 Thank you. Bye.

29:00 Thank you for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's

29:05 Python Bytes as in B-Y-T-E-S. And get the full show notes at pythonbytes.fm. If you have a news item

29:12 you want featured, just visit pythonbytes.fm and send it our way. We're always on the lookout for

29:16 sharing something cool. On behalf of myself and Brian Okken, this is Michael Kennedy.

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