Transcript #155: Guido van Rossum retires

00:00 Hello and welcome to python bites where we deliver python news and headlines directly to your earbuds this is episode one hundred fifty five recorded october thirtieth two thousand nineteen.

00:10 I'm brian and i'm michael kennedy and this episode is brought to you by data dog thanks data dog will hear more about them later absolutely at brian.

00:18 Happy halloween eve over right how we need spooky i big news.

00:24 It's not my big news, but I have big news to announce.

00:26 I'm on pins and needles.

00:28 Guido has retired officially from employment, which, you know, congratulations to him.

00:34 That is awesome.

00:35 The news is Guido van Rossum has left Dropbox, not for another position, but to retire.

00:41 So, you know, I think that's great to hear.

00:43 Okay.

00:43 What does that mean about his involvement in Python?

00:46 Do you know?

00:46 I can only speculate.

00:48 I don't know for sure yet, but my guess is actually that it will mean more Python involvement, not less.

00:53 Okay.

00:53 But that's just based on I've been at big companies and even when they say, yeah, you can work on whatever you want, there's meetings and there's bureaucracy and, you know, the proverbial TPS report, just like, you know what?

01:07 Okay, well, we're doing nothing today.

01:09 And so if he can work on whatever he wants, I have no idea what he's going to work on, but there's gotta be some cool creative projects.

01:15 Maybe not next week.

01:17 Maybe he needs a year just to sit on the beach and look at some sunsets, but then eventually I bet he will come back, do something.

01:23 Yeah, okay. He deserves a break.

01:26 And you're linking to an article or a post where he announced it also, right?

01:29 Yeah, so there's a link to his announcement where he wrote sort of the goodbye and all that.

01:36 His final project there at Dropbox was really to work on mypy and help them convert to 2 to 3.

01:43 I think it's kind of fitting, right?

01:44 Like one of his final things is to convert one of the largest Python codebases from Python 2 to Python 3 to kind of like close that gap.

01:52 I mean, not globally, but at least in that realm.

01:55 You have not just his announcement, but a thank you Guido from Dropbox.

02:00 That's kind of cool.

02:01 Yeah, so when I wrote this stuff down, it was just, I don't know, half an hour since that news came out.

02:07 And it was just full of responses of so many things.

02:09 So I just grabbed a couple to, I thought maybe a nice way to close out this little section is just to read some of the messages that people wrote to Guido on his Twitter announcement that link to his full post.

02:22 So, Lucili says, "Thank you for Python and helping to increase diversity "in the teams that you worked with.

02:30 "Enjoy your retirement." Daron Leal says, "Congratulations and best wishes.

02:35 "Thanks to the many contributions to open source software "and for inspiring me." Philip Guo, "Congrats and best wishes on the next era." Someone just goes by Steve.

02:44 "Thank you for your contributions to the world.

02:46 "My boy was just learning how to code Python as his first programming language, as I read this, basically.

02:52 And Freeman Crouch, "Best switches, I literally don't know what my teaching career would have been like without Python." I just want to say, thanks for everything, Guido, that's awesome.

03:02 He's really created something special and he's put a big dent in the universe, obviously.

03:07 This is a huge accomplishment of what he's done and what he's shepherded over the last 30 years and it's definitely high time for him to retire just so that he can go and just enjoy that, not stress.

03:17 Like it's cool that everything is in place that basically this is not like a oh my god, now what?

03:23 It's just like oh, okay, well, that's great for him.

03:25 Right, like we kind of went through that last year, actually.

03:28 - Yep, it's an interesting thing, and yeah, I don't know what more to add other than also thank you.

03:33 Yeah, I love the language.

03:34 - We both get to work on some really awesome stuff involving Python.

03:37 - Yeah.

03:38 - And the community because of it, so yeah, thanks.

03:40 All right, well, speaking of awesome stuff built with Python, what's next?

03:44 - Yeah, hard to transition away from that, but I could have swore we'd covered this, but I guess we haven't.

03:49 There's a cool project called Selenium Base.

03:52 And what Selenium is, I mean, most people know it because in the Python community or other places for testing websites and such.

04:03 You can also test APIs with it.

04:05 But the Selenium WebDriver is what people often use to access Selenium through Python.

04:13 And Selenium Base is built on top of that, and it's built in conjunction to work with, it works with other things like unit test stuff, but it works best with pytest, of course.

04:23 And it's kind of a layer on top that makes it quite a lot easier to, the Selenium WebDriver right out of the box has a lot of access.

04:31 You can control, basically you're driving a web browser through from Python.

04:36 And the Selenium base just makes it easier.

04:39 There's a lot of easier things.

04:41 Like I'm gonna link to, actually in the show notes, I've got a little snippet of code and it's really easy stuff like open a web page or open with a URL and assert that a title is there and, you know, click on elements and you can use go back and click and examine things and assert stuff.

05:00 It definitely makes for testing testing web pages a lot easier with all these utilities, but I also wanted to highlight.

05:07 There's some I was looking through it the other day and there's some other things that it does that I thought was kind of interesting.

05:13 One of the things that it has is, well, one, it has support for a lot of the major continuous integration services.

05:19 It also has a plugin built into it that you can take screenshots of test results.

05:26 So let's say you have a test that fails because, you know, something isn't in the title or something isn't present or something's wrong.

05:31 But what is there? And it's hard to describe with code, but it's not too bad with a screenshot.

05:37 So it has the ability to take a screenshot on test failures.

05:40 That's pretty cool. I wonder if you could use that as an assert itself.

05:45 If you had a screenshot of the way, you said, "This page looks right now," and if something goes crazy, like the CSS won't load or something is...

05:53 Could you assert that the pixels are the same?

05:56 I mean, that's sort of visual testing.

05:59 There is some visual testing with it.

06:01 The main component that it has with it is making sure that the DOM is essentially identical.

06:07 The DOM essentially reproduced the same thing.

06:10 I don't think it does a pixel by pixel comparison.

06:13 Maybe there's some plug-in for it.

06:15 But there is some built-in stuff to do.

06:17 Basically, it should be about the same.

06:19 Some other cool stuff, it works with Selenium Grid, which I wasn't quite sure what this was, but Selenium has built in an ability to run Selenium tests on multiple CPUs so that you can do things in parallel.

06:31 Grid computing, I want to test all these pages, and it takes a little while, so just spread it out. Okay, that's cool. I hadn't heard of that either. That's nice.

06:38 The other thing is assisted QA.

06:40 So sometimes it's really easy to have a manual procedure that basically says, you know, we want to throw this together quickly.

06:47 Just look at this page to make sure the graph is there.

06:50 Sometimes it doesn't show up, or you know, whatever, just make sure, and then pop up a little dialog box that says, yes, it's there.

06:56 There is some assisted QA, so it's like partial automation.

07:00 And that's kind of neat.

07:01 And I think people poo-poo this too much.

07:04 This is actually very powerful to have in place, and sometimes it's a matter of pragmatism of getting things done.

07:10 So this is cool. Then one of the other cool things is it has onboarding demos capability.

07:16 So since you're using it to drive a web browser, you can use it to highlight things and pop up messages, and you can essentially give an onboarding demo of how to use a web page.

07:29 So this isn't a testing thing, this is you would create a little demo to show somebody how to use some service.

07:36 So that's kind of neat.

07:37 Yeah, super cool.

07:38 This looks really nice.

07:39 I looked at the API that you got here.

07:42 If you knew the tiniest bit of programming and you knew CSS, you already understand this.

07:48 Like there's no documentation needed.

07:50 Obviously, you've got to have some documentation for real, but it's super clear.

07:54 It takes away all of like the find item by element and all those sorts of things.

07:59 You don't have to do that too much.

08:01 So anyway, cool thing for if you want to automate a web browser or test a website, make sure you check this out.

08:08 It's good.

08:09 Yeah, it looks great. I love it. Nice find.

08:11 Well, and another thing that's nice is Datadog.

08:14 So this episode is sponsored by Datadog, a cloud-scale monitoring platform that unifies metrics, logs, distributed traces, and more.

08:22 Trace requests across service boundaries with flame graphs, correlate traces with logs and metrics, and plot the flow of traffic across multi-cloud environments with network performance monitoring.

08:35 Plus, Datadog integrates with over 350 technologies like Postgres, Redis, and Hadoop, and they're tracing client auto-instruments, common frameworks, and libraries like Django, Tornado, Flask, and AsyncIO.

08:47 That's cool.

08:48 Get started today with a 14-day free trial at pythonbytes.fm/datadog.

08:54 Yeah, check them out. Big support as a show. Thank you, Datadog.

08:57 Yeah, plus I love my purple t-shirt from them. It's good.

08:59 For sure.

09:00 Now, this next one, I want to start by asking you a question, Brian.

09:04 You've done a lot of C, C++.

09:05 We even talked about that last time, right?

09:07 Yes.

09:07 Is Python slow?

09:08 No. People are slow.

09:10 People are... Very good. That's a good question.

09:12 Good response. I like it.

09:13 I think the whether or not Python is slow is a really interesting question.

09:16 And people sometimes say, "Well, I did a tight loop and I added x+=1, and it was slower than if I did that on C.

09:24 And so Python is slow, right?" But then you could also say, "Well, I have a job.

09:30 somebody told me to implement this feature.

09:32 If I started in C, I would be done in 10 days.

09:34 If I did it in Python, I'd be done in six hours.

09:37 So, and it took one minute to run it in Python and 30 seconds in C.

09:41 So Python is way faster, right?

09:43 It's half a day or three quarters of a day instead of 10 days.

09:47 Yes.

09:47 That sort of analysis.

09:48 But sometimes it's interesting just to compare like directly to these things.

09:52 And we also have the C layer.

09:54 So like, yeah, sure.

09:55 It might be slower than some languages, but then if you call it like NumPy, then it's probably faster than most like there's all these interesting like angles, right?

10:02 Scython and whatnot.

10:04 But this thing that I want to talk about now is this host mortem done by Darren Moffett.

10:09 So he re implemented the list users command on Solaris.

10:14 It was originally written in C and he rewrote it in Python.

10:19 Okay.

10:20 Which is kind of an interesting thing.

10:22 Couple of stats about it.

10:24 So this is from like 19, the last time the C code was touched was like 1988.

10:30 That's 30 years ago, 31 years ago.

10:34 That's a good long while.

10:36 And the implementation of this was about 800 lines.

10:42 And it was written in a time when the number of users were small and things like that.

10:46 So it didn't have to deal with tons of data.

10:49 And it even had some bugs, right?

10:51 But it turned out that a basic implementation of what List Users does is a set manipulation.

10:57 Okay.

10:57 You know what language has really good set implementation?

10:59 Python.

11:00 Indeed.

11:01 So, he decided to try to rewrite it in Python.

11:05 And it turns out the rewrite of List Users in Python 3 was about a tenth the number of lines of code.

11:12 Instead of 800 lines of probably fairly gnarly C code, it was down to 80 lines of Python.

11:18 Wow.

11:18 That's pretty awesome.

11:19 And a lot of the reason has to do with the fact that you don't have to reimplement set.

11:23 You just say the word set and you're good.

11:26 But what's really interesting is on top of that, for 100,000 users, some tests they were doing, the Python version was 17 times, 1,700% faster than the C code as well.

11:40 Wow, that's incredible.

11:41 Pretty cool, huh?

11:42 Yeah, it's actually not surprising to me.

11:44 I'm glad we're covering it because it sure should surprise some people.

11:47 Yeah, it doesn't surprise me all that much either.

11:49 So yeah, it's pretty interesting.

11:51 That turns out that the it's source open, but not open source.

11:56 If you want to look at the implementation, what I mean by that is the list users command is, you know, this is from Oracle, right?

12:03 Like they bought sun.

12:04 So now they have Solaris.

12:05 So on 11.4 SRU 9 or higher, you could just go to slash user slash bin slash users, and it's a Python file.

12:13 So you just look at it, right?

12:14 So you can see what they're doing and you could compare the code and and whatnot, but it's not open source and it's covered by the Oracle Solaris license.

12:22 So you can check it out, but it's not open source.

12:24 It's source open.

12:25 - This is cool.

12:26 So not only is this, somebody tried to do it and it was faster, it also is shipping now with Solaris.

12:32 - Yeah, that's pretty awesome.

12:34 And it's Python 3.

12:35 - Of course.

12:36 - Of course.

12:36 I bet there's some useful tricks in that code.

12:38 - There probably are.

12:39 Actually, I was thinking about this when you brought it up with sets.

12:43 So I admit it, I am capable of getting link baited by the occasional listicle, and this is definitely one of them.

12:50 It was 20 useful Python tips and tricks that you should know.

12:55 Now, there's some fluff in there that I don't think that's useful, but there's a whole bunch of, enough that are useful that I think it's a good thing to take a look at.

13:04 Like for one, I'm not sure if, so change assignment is one of the first ones that I looked at, and you actually don't, I don't see this in a lot of Python code, So is it bad, Python style or something, to have like x equals y equals z equals two or something?

13:22 Do you know?

13:22 - I don't know, actually.

13:24 But you're right, I remember seeing this a lot in C.

13:27 - Yeah.

13:27 - But not a lot in Python, no.

13:29 - No, but it does work in Python.

13:31 But I guess, make sure that you're not doing something that's too unclear.

13:35 I highlighted that mostly because what I do see, what I use a lot is chain comparison.

13:41 And people coming from other languages don't know you can do this.

13:44 So for instance in C, if you wanted to have, make sure that X was between two and eight, you'd have to go two is less than X and X is less than eight or something.

13:55 But with the Python, you can just chain them together and put them together.

13:58 - Right, like two less than X less than or equal to eight.

14:00 - Yeah, and you can have a whole bunch of them.

14:02 So you can have a couple variables within ranges and stuff, it's nice.

14:08 Multiple assignment, which I think of as unpacking, I guess.

14:11 - Yeah, I think of that as tuple unpacking.

14:12 Definitely that's common, right?

14:14 like if you're gonna do a four, you know, index comma value in enumerate of collection, something like that.

14:21 - Yeah, but the thing that I've been using a lot more lately is tuple unpacking with the star operator.

14:26 So like if you put a star on one of the things you're unpacking to, it takes all the leftovers.

14:33 And so if you've got a whole bunch of stuff you're unpacking but you only care about a couple of them, you can name those and then just capture all the rest of them in a star underscore or something.

14:43 - Yeah, throw away.

14:44 I know I have to have placeholder for this, but I just don't care.

14:47 - I've seen it in a couple articles, but it listed merge dictionaries, where you do star star of both dictionaries within another dictionary in brackets, and that kind of combines them.

14:58 Debate as to what you should use, but I kind of like that 'cause it's short.

15:02 - I like that one, yep.

15:04 - And then joining strings, people new to Python, it's one of those things that it's nice to, you just take a character or a string, and join all the elements in a list or any iterable.

15:16 And this is something that, for some reason, especially the people I'm familiar with that come from C or C++ to Python, this is hard for them to get around, that strings themselves have object methods on them.

15:30 - Isn't it just a character pointer or something like that?

15:32 Like char star, char star, sort of?

15:36 - Yeah, yeah, they don't think of them as objects.

15:38 - Exactly.

15:39 - This brings up, you said sets before, So if you've got a list of things and you want to get the list of unique things, well, you can just convert it to a set and then back to a list, and there you go.

15:50 Yeah, I do that sometimes. It's really nice. That's your distinct, yeah.

15:53 Yeah, the only thing left that I wanted to mention was using--

15:56 this was something that was difficult for me to get my head around, was the zip function, mostly because I was familiar with using zip on the command line to actually zip files.

16:07 So no, Zip is completely different.

16:09 It kind of pair-wises up all a bunch of lists of things.

16:13 And I use it all--

16:16 I don't really-- it's hard to explain when you use it, but when you do need it, it's really handy.

16:20 Yeah, I feel like the inner tool stuff just has so many things.

16:24 It's always something new to me.

16:27 You know?

16:28 Yeah, so I--

16:29 I don't know all this stuff.

16:30 Those are the things I thought were good, and it was less than 20.

16:33 The rest of the 20 wasn't that useful to me, but these were neat.

16:36 Yeah, no, those are really cool.

16:39 A lot of times with these listicle type things, or like this top ten, or like, I don't know, some of these are cool, like these all look really great. Yeah, I like it.

16:46 Cool. So let's talk about waterfalls.

16:49 Now, we've talked a little bit about code complexity on different things. I think we've covered Wiley from Anthony Shaw, which is a code complexity analysis tool.

16:58 So, here's an article write-up sent over by Arem Aref.

17:04 from the article is by somebody named Nikita Sobolev.

17:09 And it's called Complexity Waterfalls.

17:11 Pretty interesting.

17:12 It kind of talks about the origins of complexity in our code and just the challenges of how that sneak in.

17:18 And nobody starts out with the intention of writing like bad, hard to understand code.

17:24 You may know you're going down that path.

17:26 He's like, "I don't know what I'm doing here." But most of the time, it's with good intentions that everything starts out.

17:32 At some point it becomes this mess, right?

17:35 - Yes.

17:36 Some people are really good at it too.

17:38 - They do have a special skill.

17:40 So this article highlights some of the types of complexity that you might find, how you might address them, some of the tools to actually automatically discover them.

17:51 Two of the core ideas are things that I think will resonate with you, Brian, are continuous refactoring and architecture on demand from using things like tests and continuous integration and whatnot.

18:04 So basically, instead of trying to dream up this perfect architecture, just write stuff in a simple way, and as it gets more complex, run some tools, discover the problems, use your unit tests to let you refactor, and grow the architecture out of it.

18:18 What do you think of that?

18:19 - Yeah, I definitely like that a lot, and more and more I'm warming to the idea of using complexity measurements as part of your tools to tell you where to refactor.

18:29 Yeah, so one of the things they use in here to talk about the complexity and measure it is this thing called wemake-python-styleguide, which is actually a linter, not just a guide.

18:41 Like it's a thing you could run, I believe.

18:43 It actually outputs stuff, it's not just a guide.

18:46 And it does pretty interesting stuff.

18:49 So you can run it on your code and it'll say, you know, you're missing white space between your type definition and your type, your variable definition and your type annotation, or between a comma, or there's a bunch of different things.

19:03 And it brings in some of these complexity measures.

19:07 I've heard of, you've heard of psychomatic complexity.

19:09 I know we've talked about that, right?

19:11 - Yes.

19:11 - We've definitely spoken about lines of code, right?

19:14 Like when, so the article talks about, hey, here's how individual lines of code become complex.

19:21 Here's how functions become complex, or classes, or modules, or packages, and so on.

19:27 And obvious measures or metrics would be if your function is 5,000 lines long, it's wrong.

19:35 I don't know what it does, I've never seen it, but I can tell you already, it's broken, right?

19:39 These sorts of things are pretty obvious.

19:43 But one that I don't know that I've ever really paid attention to is something called the, I think it's the Jones, Jones metric?

19:51 Yeah, Jones complexity?

19:52 - No, I've never heard of this.

19:53 - Yeah, so here's the idea.

19:55 If you had a line that was 80 lines long, Like says, the example they give in the, Nikita gives in the article is, by print three long variable names.

20:04 Yeah, first long name with meaning, second long name with meaning, the third one, and that's 80 lines.

20:09 Or if you say print three calculations, right?

20:13 Like you actually compute three or four things, right?

20:16 Multiply, divide, whatever, multiple things in each of those print, you're still printing three values, but somehow they feel more complex.

20:25 So with the Jones complexity, What it measures is, it's like, if I were to take this line of code and parse it into an abstract syntax tree, how many nodes would there be?

20:35 Oh, wow.

20:36 The first one, there's four.

20:37 We have print, and then there's the three things we're printing.

20:39 The other one is 21 different things are participating in this one line.

20:45 Yeah.

20:46 The reason I bring that up is, for example, the WeMake thing, I believe, will tell you this has too high of a Jones complexity.

20:54 Yeah.

20:55 It's a little line that yeah, it says, it'll say things like we found a line with a high Jones complexity of 15.

21:02 This is an error.

21:02 What should you do?

21:03 And what should you, you should break those out into different variables, right?

21:08 You should take those expressions and turn them into three variables and then print them like three variables, one on each line and then print them.

21:14 So there's a lot of concrete little steps about how do you go through and see this complexity?

21:19 What do you do about it?

21:21 And like, how do you kind of evolve your architecture through it?

21:24 So I don't want to go through all the details in there, but it's a pretty interesting read, and it comes up with some good ideas, including pointing out this WeMake Python Style Guide.

21:36 - One of the things I want to highlight when we're talking about this is that a lot of times it is shifting complexity.

21:42 So you'll have a very complex bit of something, and that's a danger field, but to eliminate it, you're going to add complexity somewhere else.

21:51 Because like the example of a 5,000 line function, that's bad, but so is 5,000 two-line functions that are 5,000 functions deep.

22:01 Sure. Yeah, if you were to break it into 10 lines, you might end up with a module with 500 functions.

22:07 That's also a bad thing.

22:08 Right. And so that's one of the things that I like about these tools is that you can break things out the way you think it's better and then measure it again.

22:16 And also, please have tests in place to make sure that you're not breaking your code while you're refactoring.

22:21 Yeah. So one of the things that Nikita talks about is this iterative, continuous refactoring stuff. Like, okay, we fix the Jones complexity of this, but now we've actually changed the complexity of, say, the module. How do we fix that? Right? Like, keep doing it until it gets better. Right?

22:38 Yes and I love this because the idea maybe some people can just think of the right architecture that they're going to need at the end but I never can.

22:47 So starting small and building up and refactoring where needed that's the only way I know how to work.

22:53 Well usually the challenges you don't have a perfect understanding of the problem you're solving until you're halfway through it.

22:59 Right well usually not until I'm completely through it.

23:02 Yeah, for sure. So even if you try to think like, well, maybe I should be more patient. I'm going to really think through this. Well, maybe, but the way you figure out what the solution should be is by going through that step. And then there's this iterative fixing process.

23:17 I never understand why some coders and developers think that they really can architect the right solution to begin with.

23:25 It's like expecting a novelist to not write a first draft.

23:28 To just come up with the final draft at the end.

23:31 It just doesn't work.

23:32 Yeah, even if it can be done, it's probably not the most efficient way to do it, right? You just stare at the wall for a week. You're like, you know what? I wrote it badly in three hours, I fixed it in one, I went to lunch, right? We're good.

23:42 Exactly.

23:43 For sure. Cool, well, If you care about code complexity and this kind of stuff, this is a pretty good write-up and definitely some of the tools mentioned are interesting.

23:51 There's usually advice at each level, like, "Here's what you do to make a line less complex.

23:55 Here's what you do to make a function less complex." I think the advice is generally good, but it can't be taken absolute.

24:03 Absolutely, right?

24:03 Like, it talks about, "Well, if I have a function, fewer arguments is better.

24:08 If I have a class, fewer methods and fewer fields is better." But if you push that to its extreme, you say, well, all my classes have only one field and one public function. Like, well, okay.

24:18 It's kind of, you know, now you have a thousand, you can't push it to its logical extreme, right? It's kind of a give and a take, but it's, you know, it points in the right direction, I would say.

24:27 I only have one argument to every function. It happens to be a variable length tuple, but...

24:32 Exactly.

24:34 That's called tuple complexity.

24:36 Tuple complexity. Yeah. Is that in the list?

24:39 No, it's not, but it is now. I'm adding it.

24:41 Have we ever talked about GUIs on this podcast?

24:44 We should totally cover that because Python needs to have more cool GUIs.

24:48 I think so.

24:49 So this one came up recently.

24:50 It's-- I don't know how to pronounce it.

24:53 P-L-Y-N-T-H.

24:55 Plinth?

24:55 Plynth?

24:56 I'm going to go with Plynth.

24:57 Plynth.

24:58 I could be wrong.

24:58 And I don't mean to make fun of you, Plynth.

25:01 I think what it's cool.

25:02 What it is is cool.

25:03 So it's a GUI framework for building cross-platform desktop applications with HTML, CSS, and Python.

25:10 "Hey, we asked for this." But it looks pretty cool.

25:13 It integrates with the standard CPython implementation and the Chromium's rendering engine.

25:20 And you can basically run Python, runs JavaScript and Python all together with Python.

25:26 And it's kind of hard to explain without looking at it, but it's sort of a thing that's just starting out.

25:32 And it's not an open source thing.

25:34 It's a group doing this.

25:36 They're gonna do it for money, but it's not expensive.

25:39 It's free for individuals and including commercial use for individuals.

25:44 And there's a bunch of tutorial videos.

25:46 Now I'm watching some of the tutorial videos watch you kind of like one of them is like implementing a calculator and one of them is like implementing a spinning cubicle or cubicle.

25:55 No, spinning cube, but it's spinning cubicle.

25:58 That'd be cool.

25:59 Somebody should do that.

26:00 Now they clearly know what they're doing when they're writing this and it might be that I'm just not a JavaScript person because the code they're writing doesn't seem obvious to me.

26:09 But it isn't that much, so a handful of code, a handful of little bits of code and stuff, and you can implement something like a calculator on your web browser if you want.

26:18 It's pretty interesting.

26:19 So yeah, there's a visual calculator.

26:21 I see that, and it looks like a desktop app.

26:24 But obviously, we know it's basically the Python equivalent of Electron, right?

26:28 Like HTML and JavaScript and Node.

26:31 What kind of surprises me here is, at least the calculator example, is integrated with view.js, which is kind of actually super cool. So you define a Python class in the Dunder init, it sets up the view class. And if you've ever done view, that looks really familiar, you would say, here's the element that is the root of the app. Here's some of the bound data, here are some of the methods. And then you just point you basically just set the function to the various Python functions like they clicked on the number they clicked in an operator. I like it. This is actually pretty cool.

27:09 Yeah, I think it looks neat. And it sounds like what they're doing is they're having some way to automatically convert existing JavaScript libraries to Python modules.

27:19 So you can call them from your Python or hook up to them or something.

27:23 And it's available, it looks like it has development kits available right now for Python 3.6 and 3.7.

27:29 And anyway, for somebody wanting to play with GUIs for Python, I think this is something to pay attention to.

27:36 I wish him luck. I'm not a zealot for open source only.

27:40 I make money on this by going to work, so some, these people can too as well.

27:44 And I'm over here looking at the pricing. Free for individuals, for commercial use, academic it's free, company enterprise, developer license, $599 per developer per four years.

27:57 Like that is, honestly, they should put another zero on that, and I think it would still be okay, because that's totally reasonable.

28:05 It's not like they're saying, "Oh, it's $1,000 per year per developer," right?

28:09 It's not much.

28:10 So I'm happy to talk about it.

28:11 It looks great to me.

28:12 - Yeah, looks neat. - For sure.

28:14 Well, what do you got on the extras for us, Brian?

28:16 Anything else you want to throw out there?

28:17 - Yeah, I want to bring up a couple of things.

28:19 I wanted to thank you for the excellent search feature that we have on Python Bytes.

28:24 - You're welcome.

28:25 - Because every week, believe it or not, I got to come up with, like, three items to talk about, and sometimes we've already covered it, And that was the case this time. I ran across another reference to a tool called Cerberus, which is a adjacent schema validation tool.

28:43 Yeah, that's a cool one. I love it. It comes from Nikola. He built that as part of the EVE framework.

28:47 Okay, well, it's really pretty neat.

28:49 And it has a lot of extensibility features that I haven't seen in other validation tools.

28:54 But we covered it in episode 70.

28:56 So, and I found that out through your search feature.

28:59 Awesome.

28:59 The other thing I wanted to bring up was this A funny thing happened. I put some the other day I put use data classes in some test files test modules Because we've converted to python 3 7 at least i'm using we're slowly converting to python 3 8 But a colleague of mine looked at my code and said, oh these data class things look cool. How did you learn about them?

29:21 I'm, like well kind of my job It's awesome I didn't say, "Well, you should listen to Python Bytes," because it seems weird to encourage my coworkers to listen to it.

29:31 Send him my way. I'll tell him to listen to it.

29:33 Learn on my coworkers. I can tell them.

29:35 How about you? Got anything extra for us?

29:38 Just something super quick. I ran across this article. It's not directly related to Python, so I didn't make it its main item.

29:45 But there's this project from Google where they've been working on the upstream Linux kernel using what they have called sanitizers.

29:55 And basically these are like C linter type things that go and find problems with the code.

30:01 So they had an address sanitizer for finding memory corruption and undefined behavior for certain code and other issues.

30:08 And then they've come up with this one called the KCSAN.

30:13 I don't know.

30:14 The kernel concurrency sanitizer.

30:16 And they then turned it on the latest Linux kernel.

30:21 And what they found is in a two day period, they found over 300 unique race conditions and deadlocks and stuff within the mainline kernel of Linux.

30:28 Wow.

30:29 Anyway, there's some comments and stuff about this and links back to what they're doing. And it's kind of interesting. The codes on GitHub.

30:35 Are they fixing them or just, you know, pointing out problems?

30:38 Well, to point out a problem like a concurrency problem like that is one thing. But to fix it, I think is a whole entirely another without, you know, causing two more deadlocks somewhere else. So I don't know.

30:49 Okay.

30:50 Maybe they're just making people nervous.

30:51 So making people nervous, maybe this joke might a little bit, probably not.

30:55 But after the one last week, I don't know, man, we're pushing the boundaries.

30:59 So let me ask you a question.

31:01 When you talk about a link on the internet and it's, you know, HTTP, this or that, you call it a URL or an URL.

31:08 Well, I call it a URL.

31:09 Yeah.

31:09 Some people call it URLs.

31:11 That what's the URL for that?

31:12 So people say URL.

31:13 I, anyway, whatever.

31:14 So there's this, this joke that comes from 18 Barry.

31:18 Right.

31:18 What's a web developer's favorite T?

31:21 - Well, it'd be Earl Gray or URL Gray.

31:25 - Of course it would, of course it would.

31:27 Awesome.

31:28 - I love that joke.

31:29 I laughed way too hard when I read that joke the first time, so.

31:33 - Yeah, me too, me too.

31:34 It's written, it's even better, so check out in the show notes.

31:36 All right, Aiden, thank you for sending that in.

31:39 That's great.

31:39 - Thank you.

31:40 - Yep, thanks, Brian.

31:41 Catch you later.

31:42 See you.

31:43 - Bye.

31:44 Thank you for listening to Python Bytes.

31:44 Follow the show on Twitter @PythonBytes.

31:46 That's Python Bytes, as in B-Y-T-E-S.

31:49 And get the full show notes at pythonbytes.fm.

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

31:57 We're always on the lookout for sharing something cool.

31:59 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.