Brought to you by Michael and Brian - take a Talk Python course or get Brian's pytest book


Transcript #192: Calculations by hand, but in the compter, with Handcalcs

Return to episode page view on github
Recorded on Wednesday, Jul 22, 2020.

00:00 Hello and welcome to Python Bytes where we deliver Python news and headlines directly to your earbuds.

00:05 This is episode 192 recorded July 22nd, 2020. Had to look that one up. I am Brian Okken.

00:14 And I'm Michael Kennedy.

00:15 And I can't believe we're heading close to 200. This is crazy.

00:18 Oh yeah. Been at this for a while. That's going to be like four years almost.

00:22 Yeah. Again, this episode is sponsored by us and we'll tell you a little bit more about other things that we're doing a little later in the show.

00:29 But first, some of the ways that people tell each other what they're up to is their personal GitHub read me on their GitHub profile.

00:38 >> That's right.

00:39 >> So I was impressed by something that I saw recently.

00:42 Simon Willison, he's the co-creator of Django.

00:46 He posted something called a blog post saying how to do a, building a self-updating profile read me for GitHub.

00:54 So at the top of it, I'm going to quote this, it says, "GitHub quietly released a new feature at some point in the past few days, profile readmes." >> This is news to me.

01:03 >> Yeah. So if you create a repository with the same name as your GitHub account.

01:08 So in Simon's case, it was Simon W, so github.com/simonw/simonw.

01:15 So you go too deep.

01:17 Then add a readme.md or readme markdown file to it.

01:21 GitHub will render the contents at the top of your personal profile page.

01:25 So that's neat. In that case, it's just one up.

01:29 So if you go to github.com/simon w you see his, but his looks really awesome.

01:34 It's got a whole bunch of cool stuff in it because he took it one step further.

01:38 It's not a static markdown file. He's got another article that talks about it, but this article here walks through exactly what he does.

01:46 And also it's all open source. So you can see his code.

01:50 He uses GitHub Actions.

01:53 There's both a button that he can push to make it happen, but there's also any post to his own Simon W. repo will cause this to happen, but the GitHub Actions run, he contributes to a lot of open source projects.

02:06 So he takes a certain set of repos that he has and pulls the latest releases and have like latest release notes using the GitHub GraphQL API.

02:17 So there's an example of that.

02:19 There's an example of using feed parser to pull blog entries off of his blog, and an example of using a SQL query to grab, I guess he's got a site called TAIL for Today I Learned, grabs a few links off of that.

02:32 So he's got a three column setup for a readme that is kept up to date using GitHub Actions.

02:39 How cool is that?

02:40 - That is awesome.

02:42 Yeah, so normally you go to your GitHub repo and you have your picture on how many followers you have and whatnot.

02:47 Some other cool stuff we'll talk about later.

02:49 but then has your pinned repositories and that greenish heat map of how frequently you contribute to various projects or just to GitHub in general.

02:59 But now you can have right at the top, you know, whatever you want to write, which that's pretty awesome. I think I might have to do this.

03:05 Yeah. I mean, you still get all that other stuff, but it's just that other stuff is below this readme info. That's pretty neat.

03:13 Yeah, very cool. And it's super simple, right?

03:15 Anyone can write a readme.md file.

03:17 Yeah, and one of the reasons why I brought this up is I think there's a lot of people trying to utilize, I mean, this day of COVID and quarantine and stuff.

03:25 I'm glad I'm not looking for a job.

03:27 And I think that if you are looking for a job, making your GitHub profile look professional and show the content that you want to show off.

03:35 And having things like, you know, blog posts on your GitHub profile, that's pretty cool.

03:40 It is really cool. And just, you know, you know that people, employers say they check people's GitHub profile accounts.

03:45 Yeah.

03:46 So how many people are going to have these unique special ones that show they care?

03:51 Right? Not too many.

03:52 Well, the people that listen to our podcast.

03:54 Exactly.

03:55 Yeah.

03:56 All the awesome people.

03:57 Okay.

03:58 So that's really cool.

03:59 I definitely didn't know about that.

04:00 Thanks for sharing that.

04:01 It looks neat.

04:02 So we got this next one from Connor Furster, and he works in engineering but also does data science-y things.

04:10 And he sent over this project that he works on that is incredibly cool.

04:15 So a lot of times what people want to do is they want to take symbolic math or math that you might write out by hand, turn it into Python code through Pandas and NumPy and whatnot, Scikit-learn or Scikit in general, and then run it through Jupyter and get an answer.

04:31 But he says he works in design engineering and you have to do a lot of calculations and those have to be kept as part of legal records to show the project design history.

04:43 One thing you can do is do them by hand.

04:46 That's kind of crazy.

04:48 A lot of people use Excel.

04:49 That's a nightmare.

04:50 Like Excel is like unbounded go-tos you can't see, which is always tricky.

04:55 So you could do it with Jupyter, but then you just got this pile of code and here's the answer and so on, right?

05:00 So you want to like the theoretical view to verify the formula you're using, right?

05:05 So he created this thing called HandCalcs, Hand C-A-L-C-S, like calculus or calculations.

05:13 Anyway, HandCalcs.

05:15 And the idea is you type in Python code into a Jupyter cell, and then you can do a percent percent render from the HandCalcs project, and it will turn it into symbolic math.

05:27 - This is beautiful.

05:28 - Yeah, as if you had written it out by hand.

05:29 - Yeah, with like, as an example, in the little video demo, we've said before we like those, and everybody does.

05:36 But it has like square root symbols with a bunch of symbols underneath it, and all sorts of symbols that--

05:43 - Yeah. - Yeah, looks like--

05:44 - Like what you would have had to show if you were in math class, right?

05:47 - Yep, exactly.

05:48 - And it will show steps, like symbolic steps from step A, step B, step C, and you can say show it shorthand or expand it out longhand and show me all the steps you use to solve these problems and all kinds of cool stuff.

05:59 - Wow. - Yeah.

06:00 The reason it looks so good is it basically converts symbolic Python math over to LaTeX, And LaTeX is like the de facto math representation language for academic papers.

06:13 So, you know, you want to have like integral signs, you want to have infinite summations, all that kind of stuff.

06:18 No problem.

06:18 Oh, this is really cool.

06:20 Ain't it cool?

06:20 And then you can also use the symbolic tag to get it to do other, like show more symbolic stuff you can do longhand, shorthand, you can have it do units.

06:29 They'll put units like millimeters cubed or whatever, and it'll carry the units through the calculation in symbolically.

06:36 - Yeah, but looking at all these formulas, it's giving me nightmares.

06:40 - Don't look anymore.

06:41 - Okay.

06:42 - Well, I guess the thing you would want to think about the trade-off is, would you rather look at them in their proper mathematical form or in like programming meaning, like where you turn it into like star star, pow, instead of proper exponents and stuff?

07:01 - No, no, I was just kidding.

07:02 This is beautiful stuff, but when we got into integrals, that's where basically that's where my brain left and I never really caught it.

07:09 (laughing)

07:10 - Yeah, yeah, cool.

07:11 All right, so if people have to take programming math but they want to represent it more nicely, check out Hancocks, looks awesome.

07:20 - Yeah, nice.

07:21 Oh, I'm next.

07:22 (laughing)

07:24 Actually, I'm not.

07:26 I'd like to talk to all of us about our sponsor and our sponsor is Talk Python Training and Testing Code today.

07:34 Tell me about talkPython training.

07:36 - I'll tell you about what I'm working on.

07:37 This week I started writing a new course.

07:39 We have a couple of new courses that are fun that are coming, and the one that I started working on is called Python Memory Management and Tips.

07:47 - Tell me more.

07:47 - Yeah, so if you ever wondered what happens, like how does it free up memory, what algorithms work better with Python memory, and what algorithms can make it more expensive or slow, what are some of the tips and tricks you can do to dramatically decrease the memory consumption like two or three times with almost exactly the same code type of thing.

08:07 Well, I'm writing a course on that.

08:09 - Oh, that's neat.

08:10 - Yeah, thanks.

08:11 - Especially for people like talking about doing some more, we can get Python on smaller operating system architectures like CircuitPython and stuff, that's important.

08:20 - Yeah, that's a really good point that on the small memory constraint pieces, you might care a lot for sure.

08:26 How about testing code?

08:26 - Well, I was interviewing somebody recently, David Lord, his actual interview will come out sometime in August.

08:34 But he said, "I was looking at testing code "and a lot of the recent episodes "really haven't been about testing.

08:40 "What's up with that?" And I said, "Yeah, it's and code, test and code." But yes, so there is a lot of testing focus because primarily because I think that software engineering doesn't talk about testing enough.

08:54 But I do cover a lot of stuff.

08:56 I'm gonna highlight a few of the last episodes.

08:59 I talked to Sebastian Ramirez on episode 120 about Fest API and Typer.

09:05 Talked with Brett Cannon on episode 119 about packaging and pyproject.toml and what's going on there.

09:11 121's a diversion.

09:13 It's a completely different sort of talk.

09:15 We talked to, I talked to somebody about 3D printing and finite state machines and stuff.

09:21 And it's just sort of a fun people doing Python and cool things.

09:25 - Very cool.

09:26 - And then again, talking, thinking about people possibly looking for jobs.

09:30 In episode 122, we talk about better resumes for software engineers.

09:35 So there's a lot of stuff for everybody, even if you cringe when you think about testing, please check out Testing Code.

09:41 We are still putting out episodes.

09:43 If you wanna hear more, I'd love to hear what people wanna hear about.

09:46 - Yeah, it makes our job so much easier when we get suggestions.

09:49 - Yeah, suggestions and questions and things that can flow into things.

09:53 - Yeah, like a suggestion to return the print statement so you don't have to put the parentheses.

09:57 - Yeah, so this is crazy, and I don't really have much of a comment here, but I saw the thing by Guido, and then I saw this article by Jake Edge on lwn.net.

10:08 Don't know what lwn stands for, but it doesn't matter.

10:12 Anyway, the non-return of the Python print statement.

10:14 So this is odd, I thought.

10:18 We have talked about the new peg parser in Python that's going on, but one of the things that happened with that is, I guess, one of the reasons why Python 2 to 3, they went from a print statement to a print function, was it made the parsing easier.

10:33 But with the PEG parser, you can do all sorts of crazy things and you can have functions that syntactically look like statements and have it work just work, sort of.

10:45 So as an example, we could use a print statement instead, instead of having to be, put the parentheses in, you could avoid the parentheses.

10:55 Anyway, he just put it out there as an idea and essentially people said, no, yuck.

11:01 What do you think about this?

11:02 - It's interesting.

11:03 It would be one fewer things that has to happen to move to the next stage from a two to three conversion.

11:09 But on the other hand, this looks like one of the easiest conversions for that step.

11:13 To me, I'm not a fan of having statements and functions in the language because it looks to me like functions basically solve the same problem with a little more clarity, you know, they're a little more functional.

11:25 You can span the multi-line if the arguments are super long, you need to.

11:30 Like with the print statement, you'd have to use like a continuation backslash and other weirdness like that.

11:35 So, you know, just 'cause you can doesn't mean you should.

11:38 I guess that's probably how I feel about it, but I wouldn't use it if it were in the language.

11:42 Let me put it that way.

11:44 - Yeah, I'm for the no yuck camp.

11:46 I think it's, I think that print statement shouldn't have been a statement in the first place.

11:50 And then I think Python 3 fixed it.

11:53 and having it be a function is the right thing to do.

11:55 I wish there were more statements that were functions instead.

11:58 Also, I think, I wish assert was a state, a function instead of a statement.

12:02 Because people doing, thinking that it's a function and putting a parentheses around assert causes problems.

12:09 But that's not what this is about.

12:11 It's interesting I brought it up because people should know about this weird, wacky discussion.

12:16 - Yeah, that's funny.

12:17 - I'm glad that it got thumbed down, and I don't think it's gonna happen.

12:20 - You're willing to make a statement about it?

12:22 - Yes.

12:23 (laughing)

12:24 - All right, well, I'm gonna make a statement about Flask.

12:27 I think Flask, you just had David Lord on the show, right?

12:30 That's not out yet, but pretty cool, yeah?

12:32 And he's lead maintainer of Flask these days.

12:35 So Flask is, at least at the API level, got to be the most popular web framework there is, because it's slightly more popular than Django, if you look at some of the recent surveys, but if you look at the other frameworks, many of them are Flask-esque, if you will, right?

12:53 Things that are like Responder or Scenic or whatever.

12:57 They have this idea of like sort of the same style, right?

13:00 So there's an article called "FastAPI for Flask Users." And I'm actually a big fan of FastAPI.

13:06 I'm hoping to have some opportunity to use it soon.

13:10 Like the APIs that I've worked on, they've been around for a while.

13:13 They predate FastAPI and I don't really want to go create a whole new site just so I could use a different framework.

13:18 That sounds like maintenance to me.

13:20 So I haven't got a chance to use it in production yet, but FastAPI looks awesome.

13:26 So there's an article called FastAPI for Flask users, and it says, look, you probably know the Flask API.

13:32 Here is the equivalent for FastAPI.

13:36 - Okay.

13:36 - Yeah, and so there's talk about some of the advantages, and they're pretty awesome.

13:41 So automatic data validation in FastAPI doesn't exist in Flask, generally speaking.

13:47 automatic documentation generation, built-in best practices like type annotations and pydantic schemas and whatnot.

13:57 It comes shipped or recommend, I guess that's in terms of like a requirement.

14:03 You have to have a ASGI server.

14:05 So it comes with uveicorn, which is one of the, it's like g.uicorn plus uvloop for async stuff.

14:12 And in a lot of ways, it's super similar.

14:14 So if you want to create a view method, instead of app.route, you would say app.get.

14:19 And so FastAPI, would you imagine the name indicates it's mostly for building APIs?

14:25 - Yes.

14:26 - All right, so when you talk about functions and what they're gonna do, you say not just here's a URL, but here's a URL and an HTTP verb.

14:34 So app.get/ or app.put/account or something like that.

14:39 Which is pretty cool.

14:41 In the route, you can specify variables.

14:43 So in Flask, you could have a user ID And in the string route, you would say int colon user ID if you want Flask to convert that to an integer, right?

14:53 It's fine, it works okay, but the rest of the tooling doesn't help you know it's an integer, just 'cause Flask knows it's gonna be an integer, right?

15:02 So in FastAPI, you put the variable up there as well.

15:05 But then in the function, you put the variable name as a type, and then it will actually convert that to an integer using the Python language tools or specification rather than the string API thing.

15:20 That's handy.

15:21 If you want a query string in Flask, you just have a URL, you can go to request.args, and you can get the value out of the query string.

15:28 In FastAPI, you just put the query string values, or sorry, the keys, as arguments, and they just get passed in.

15:35 That's pretty cool.

15:36 If you have a API that takes a JSON post, like it's accepting a JSON document, you can just say it takes a dictionary, and that gets posted in.

15:46 but you can go way, way further, which is awesome.

15:48 You can define a Pydantic model, which is a class that has types and validation on the class, right?

15:55 And then you can say my view method or my API method takes, like in the example they have is a sentence that has got like various components, nouns, verbs, and whatever.

16:04 You can say, here's a function and it has an argument called sentence and it'll take that JSON document, parse it into the Pydantic model and pass it to you pre-validated.

16:15 - That's definitely one of the benefits of FastAPI is this data validation.

16:19 - Yeah, this is like built-in data validation.

16:22 'Cause how many times do you spend effort, oh, I got a string, but I got to convert it to an integer.

16:28 I got to make sure that this value is here.

16:30 I got to make sure that this one is, you know, like whatever, like it matches some set of substrings or whatever.

16:37 Just let the framework handle it.

16:38 It also has the equivalent of blueprints, which it calls routers, and this automatic validation I talked about.

16:43 So anyway, there's a nice article that says, you know Flask, let's teach you FastAPIs real quick by just doing a this equals that.

16:53 - Yeah, I love this because there's a lot of people that have been writing APIs in Flask for a long time.

16:59 And so it's just second nature to them and having something to say, hey, I want to try FastAPI, but is the learning curves going to be a problem?

17:07 Well, with something like this, it's decoder ring and it is set up for, you can just sort of skim through and go, well, how do I do URLs?

17:15 Oh, this is how you do it.

17:16 And URL variables and different things.

17:19 It's set up really nice.

17:20 - Yeah, yep, definitely fun, definitely useful.

17:23 - So do you use Twitter?

17:24 - I do use Twitter, sometimes happily, sometimes I get dragged into stuff.

17:30 Sometimes I use it in write-only mode where I wanna make a statement, but I don't really wanna go read it.

17:34 But yeah, definitely.

17:35 - Yeah, well, I have a, this is probably common, sort of a love-hate relationship with Twitter.

17:41 I use it a lot and like keeping track of other people, but sometimes I don't really like that it's a pain to delete old stuff, 'cause I think of it as a current conversation.

17:52 I don't really look at what somebody wrote a year ago, and I don't really care what I wrote a year ago.

17:59 So I have used Twitter deletion tools before.

18:04 They seem kind of weird that I have to go out and give my credentials to some other website or something though, but I know how to do it.

18:10 I'm sure that'll be fine. It'll be fine. Don't worry about it.

18:13 Yeah, anyway, but there's APIs, so you could use the Twitter API, but how?

18:18 And so I thought it was really cool that Chris Alban is somebody that tweets about data science a lot.

18:24 And he posted a little snippet that he said he uses, at least he did it first at one point.

18:33 But it's a cool little example of using a library called Tweepy to interact with Twitter and to delete old tweets for your account.

18:44 So it's just this really short little Python script, but it deletes tweets.

18:49 There has defaults, but you can change those.

18:52 Obviously, it's just a Python script, so you can change whatever you want.

18:55 But it's set up to delete tweets that are older than 62 days and that have likes less than 100 people and that you haven't liked yourself.

19:06 So the idea being, If you go through some of your old tweets and the ones that you, you're like, oh yeah, that was cool.

19:12 I want to keep that around.

19:13 Just like it, like your own tweets and then run this script and it'll delete some old stuff.

19:19 I would definitely have to change that hundred count to something else because I don't think I've ever had a tweet liked by a hundred people.

19:26 That's a big number.

19:27 You know, Twitter used to show how many tweets you actually had and I don't think it shows it anymore.

19:33 On my profile, at least, I don't see it immediately how many tweets I had.

19:37 followers and following and likes and stuff like that.

19:40 But yeah, pretty cool.

19:43 It's like keep the highlights, right?

19:46 Just keep my highlights.

19:47 I don't need every random thing of, oh, I went out and had a hamburger today.

19:52 People don't need that as a piece of history.

19:54 - Yeah, and you don't know what's gonna stick and what's gonna not.

19:58 And I was actually reading an article recently about Twitter, about what that says to you if somebody, like for instance, you're trying to get a job.

20:07 and somebody looks at your Twitter account, having the junk in there that nobody really related to, having that automatically called out and just having the highlight reel, that's not a bad idea for some of the old stuff.

20:21 - Yeah, and you could turn it way down.

20:22 You could say, look, if there's no likes or no retweets, just drop it.

20:26 - Yeah, yeah, it might even be good for me just to go back a couple days.

20:31 But if nobody's liked it in a couple days, maybe just take it away.

20:34 - That didn't happen, right?

20:36 - Yeah, that didn't happen. (laughs)

20:38 - So people could end up clinging to their old tweets, but they probably shouldn't.

20:42 - Right. - Yeah.

20:43 So I wanna talk about an article by Itamar Turner-Trowering.

20:48 Now, we spoke about him, sort of, not by name, I don't think, but we talked about Phil, the data science memory profiler a little while ago.

20:57 - Okay, right.

20:58 - So he's the guy who wrote that.

20:59 I actually had him on Talk Python on episode 274 as well, talking about that.

21:03 So that was pretty cool.

21:04 But he, independent of that, he wrote this article that I came across that I liked called "Clinging to Memory, How Python Function Calls Can Increase Your Memory Usage." And this is part of my research for working on that course that I was talking about, that memory, Python memory management stuff.

21:21 So he talks about, like, hey, we're going to have this thing, it's going to load up some NumPy data, and then it's going to pass it to a function, the function is going to make some changes, take the return value of that, pass it to another function, it's going to make some more changes. So basically three steps and said, look, we'd expect that we've loaded two gigs of memory. And yet when you run fill against it, you end up with three gigs of maximum memory usage, which is a little bit weird. And the reason is those initial like intermediate values that you're working with on step one and step two, the way Python decides a variable goes out of scope is in this case, the function returns not like it's never used again, but it's just the function returns, in which case it's going to hang on to all the intermediate copies all the way to the end.

22:10 Interesting.

22:11 Right?

22:12 Like some languages, they determine that and they get rid of it.

22:15 Like in C#, the JIT compiler will notice like, okay, a variable is not used after half the way, so we're going to make it eligible for GC, basically, unless it's in debug mode, then keep it around in case somebody sets a breakpoint and they want to see it.

22:28 So there's a lot of the tricks that things can do.

22:30 Python doesn't do them.

22:32 So it's gonna stick around for this length of the function.

22:35 So what can you do to make it not stick around as long?

22:39 'Cause maybe you only have two gigs and you don't wanna use three gigs or whatever.

22:42 Right, so he talks about three different solutions.

22:45 One is to don't hold onto the intermediate variables and just chain into one massive function call like pass the results of one to two to step two, pass the results of step two to three, and there's no variables holding on, so they'll be gone.

22:58 Right, that's an option.

22:59 Another one is to iteratively change the variable, say like data equals load data from first step.

23:07 Data equals step two of processing of data.

23:10 Data equals step three of processing of data.

23:13 And that way you're dropping the reference count to the first, to the intermediate steps along the way.

23:20 Right, so that's an option.

23:21 And then there's a third one that's more complicated about creating like a sort of a ownership management type of thing that people can check out as well.

23:28 But I just thought it was interesting to think about, how long do these things stick around and what techniques might you use that are incredibly simple, like just reuse the variable name, problem solved, in terms of having too much memory usage.

23:42 - Interesting. - Yeah?

23:43 - When I look at these, they all look kind of like the same, but having the answer be that they use different amounts of memory is not obvious.

23:50 - Right, it's not obvious at all.

23:52 But you could easily look at this one where you're iteratively changing the variable and say, oh, you shouldn't do that, you should name it more clearly 'cause maybe the type is changing along the way and it would be weird.

24:02 But you could say, yeah, but this one works 'cause it will fit into RAM and the other one won't.

24:08 So we're willing to accept this like slightly imperfect code because it works better.

24:15 Anyway, there's a lot of interesting trade-offs you can make here, but I just, it's only the tip of the iceberg for things like this you could do, I think.

24:22 But it's interesting to just put it on your radar.

24:24 Yeah, that is interesting.

24:27 Yeah, actually, like we said, I think that more and more as we start using Python for other applications or non-desktop kind of things, like when we're in non-server things, if we're using it for, there's a couple ends of it.

24:40 If you're using small devices, like in CircuitPython or something, you're gonna care about this stuff.

24:47 But also if you're using very large datasets, then we care about it again.

24:51 And it doesn't matter how much memory your computer has, having multiple copies of gigabytes of data when you don't have to will slow things down.

25:00 Yeah, for sure. Or even if it's like an API and you just happen to be doing, it's not that extreme, but you happen to be doing a thousand of them at a time. Same story.

25:10 Yeah, exactly. And as we use Python more and more in more applications, we're going to start caring about that again.

25:16 Yeah, absolutely.

25:17 That's the end of our six.

25:19 I actually have been just so swamped with stuff, I don't have anything extra to talk about.

25:24 Do you have any extra items?

25:25 - I do, and this is just a follow-up email we got from a listener named Adam.

25:30 Thank you, Adam.

25:31 And you had talked about pickling things.

25:34 Apparently you're a fan of dill pickles, and, no wait, pickled strings, pickled lists, pickled dictionaries.

25:41 No, we were talking about pickling and how it didn't make sense most of the time, but there might be some use cases, and you're like, what might be a use case that we really need, right?

25:49 So Adam said, hey, I got a use case that worked for us.

25:53 I worked on an API that spoke to a third party service that was wonky and it was over raw sockets.

26:00 So you'd have to create these byte arrays and send them along.

26:04 And the thing was also not available 24/7.

26:07 It would sometimes crash, things like that.

26:09 So what they would do is they could set a flag in their app and it would pickle all the messages that it would have sent.

26:17 And if the site comes back, it can like rehydrate those things and then ship them along, or you could pull them up for debugging and look at their details and whatnot.

26:25 So it was like, oh, we got to save this exactly as we would have sent it.

26:30 Let's just pickle it.

26:31 - That's pretty cool.

26:31 - Yeah, it seems like a pretty good one.

26:33 And there was a feature flag they could turn on and off, which was kind of cool.

26:36 Yeah, they could also do that for the messages they got from the service.

26:39 Pretty cool.

26:39 Real quick, Python 384 is out.

26:42 I've already brew upgraded mine, so that's all good.

26:45 And big news, big news.

26:47 I can't believe it, I've been selected.

26:49 I, if I go to my GitHub repo, I don't have the cool read me thing that you're talking about, but under my picture, it says I have a pro account 'cause I had to pay for some stuff, but I noticed that I am an Arctic Code Vault contributor.

27:03 So remember we spoke about the Arctic Code Vault where GitHub is taking a bunch of the popular projects and then sticking them over in some vault in Norway or somewhere like that, Greenland, to preserve it.

27:18 And if the code that you've contributed to GitHub was selected, then now you get this cool little highlight that's like a snowflake that says Arctic Code Vault Contributor, and you can hover over it and it'll say why.

27:29 So yeah, I've contributed apparently to a couple of things, and you might be as well.

27:33 - Well, yeah, you the listener might, but I just checked mine and I am too, so that's neat.

27:38 - Yeah, awesome.

27:39 - Neato.

27:40 - Yeah, so.

27:41 - I think we covered that once.

27:43 The code vault thing.

27:44 - Yeah, we definitely covered the code vault, but yeah, I think this you are a contributor thing, little badge is new, and I don't know, it makes me happier than it probably should.

27:52 (laughing)

27:54 Yes, it's so cool.

27:56 - It's neat. - You know what else is cool?

27:59 Yeah. - Star thing.

28:00 - Yeah, it's super neat.

28:02 Testing is cool.

28:02 - I love testing.

28:03 - And having good code coverage is cool.

28:05 So I've got a joke for you.

28:07 A cartoon, if you will.

28:09 from this place called Geek and Poke.

28:11 They have all sorts of good stuff there.

28:13 And you can click on the picture and it'll take you to the actual comic.

28:18 So there's two people, a woman developer and a man developer, staring at each other.

28:23 And the woman is the more senior one.

28:25 They're looking at each other and it says, QA best practices.

28:29 She's looking at the guy and says, "Never just remove a failing test." The guy stares back blankly for a second.

28:36 Says, "Only remove the assert statements?" - Yup.

28:39 (laughing)

28:41 So how does this stay in a decent code coverage?

28:45 - Yeah, you can fix a test.

28:46 You can make a test not fail.

28:48 Remove those hurt statements.

28:49 It's good.

28:50 - Yeah, that's funny.

28:51 You said you actually like test for failure though, on yours, that they potentially could fail.

28:55 - Yeah, well, I think that's one of the reasons why we do code coverage on all, or not code coverage.

29:00 We do code coverage, but we also do--

29:02 - Code review.

29:03 - What's that word again?

29:03 - Review?

29:04 - Yes, code reviews.

29:05 Yes, we do code reviews on tests because we have had tests show up before that exercise.

29:12 We, you know, with test equipment, we do a lot of complicated things.

29:15 You set up everything, run some stuff, and then we often have people forget to check anything at the end.

29:22 And so it is important to look at the end to see, is there any way this can actually fail?

29:29 Is it, or is it just exercising things?

29:31 I mean, actually exercising things isn't a bad thing because you can get asserts in your code or accept--

29:38 - Or an exception, yeah.

29:40 You still test something, but you're not testing very much.

29:43 - Yeah. (laughs)

29:46 - You're testing it runs, basically.

29:48 - Yeah, so.

29:49 - Awesome, well, yeah, just never remove a failing test, only the search statements.

29:53 (Michael laughs)

29:54 - It's terrible.

29:55 We should not give that idea to people.

29:57 - No, we should totally delete this joke.

29:58 It didn't happen, it wasn't funny.

30:00 - Yeah, it wasn't funny.

30:01 Thanks a lot, Michael.

30:03 - Yeah, you bet, great to see you, as always.

30:04 Thank you for listening to Python Bytes.

30:06 Follow the show on Twitter @pythonbytes.

30:09 That's Python Bytes as in B-Y-T-E-S.

30:12 And get the full show notes at pythonbytes.fm.

30:15 If you have a news item you want featured, just visit pythonbytes.fm and send it our way.

30:20 We're always on the lookout for sharing something cool.

30:22 This is Brian Okken, and on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast with your friends and colleagues.

Back to show page