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


« Return to show page

Transcript for Episode #141:
Debugging with f-strings coming in Python 3.8

Recorded on Wednesday, Jul 24, 2019.

00:00 KENNEDY: Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is Episode 141, recorded July 24th, 2019. I'm Michael Kennedy.

00:10 OKKEN: And I'm Brian Okken.

00:11 KENNEDY: And this episode is brought to you by Datadog. Thank you Datadog for supporting the show, tell you more about them later. Brian, how you been?

00:17 OKKEN: I'm good, really good. Quite busy, how about you?

00:20 KENNEDY: Always busy, I feel like life always applies a little bit more friction to me these days. You know, a little bit more email, a little bit more paperwork, but you know, that's the world I inhabit these days so it's all right, it's all good. Last time we spoke about Flint and Flint being a library or a little utility running out your Python code, it'll rewrite your expressions into f-strings and f-strings are pretty awesome. Actually, that was maybe two times ago but you know, Flint's been updated a lot. There's been like five releases since we talked about it. You're going to kick us off here with some more f-string goodness, not to do with Flint but just f-strings.

00:53 OKKEN: You and I are both fans of f-strings. I use them all the time now, so now I consider 3.6 the bottom of the versions. One of the things that's coming in that I don't think we've talked about, we've talked about 3.8 stuff but mostly there's been a lot of attention around the Walrus operator but there's some extra debugging stuff that's coming along with f-strings that are pretty darn cool. The one I'll be using all the time is, man I always throw, it's frequent for me to throw in a print statement for a variable just to see as it changes what the value is, and it's like, you know, it's print, the variable name equals, and then the variable name in curly brackets for the f-string to locate the value. For the value, right. So there's like a little equal sign decorator, or it's a little extra thing right before the last bracket that you can do, and it'll do that automatically in Python 3.8.

01:45 KENNEDY: Yeah, so in Python 3.8, if I type, I have an f-string and I type f'{foo=}', the output will be foo= whatever the value of foo is.

01:56 OKKEN: Yeah, huge time saver, it's cool.

01:58 KENNEDY: Yeah, that's super cool. I feel like you might've been doing some low grade debugging, given all the items you're talking about this week.

02:06 OKKEN: I'm always doing low grade debugging. But along with that, we're linking to the some Python docs, but there's also a couple other things associated with that. You can, normally with f-strings you get the repr value of an object, but you can have a s decorator on it with a !s, it'll do the string operator instead and then for floating point numbers you're going to be allowed to do modifiers so if you just want two or three decimal places or something you can do that.

02:38 KENNEDY: That's really cool, so you can use this little equals thing, and then at the end stick a formatting instruction, like, :.2f or colon comma, or something like that.

02:47 OKKEN: Yeah, it's like, finally I think Python's getting to a point where it's just printing, debugging with print F. I'm a C guy. So debugging with print statements is usable now, so great.

02:59 KENNEDY: Yeah, that's really cool. There was some comment on the f-string episode, the 139 that I talked about at the beginning here, I can't remember the guy's name but at the bottom of the show page he put a comment saying, "Look, I'm an old C guy." So I had said like, I love to use f-strings but I always find myself halfway into the string, like, oh, the f goes at the front, this one I actually need to do some sort of format so I'd have to go back and do it and it's a hassle. He says, well because I'm a C guy, and you just mentioned as well, like I think printf() so I just move the parenthesis up a little bit.

03:30 OKKEN: That's a good mnemonic, yeah.

03:31 KENNEDY: Exactly, just split I like it, the printf, yeah, exactly.

03:34 OKKEN: So a lot of my team is jumping on board with the f-strings as well, so much so that often strings'll be f-strings and there's nothing in it being formatted. It's just, they're just using f by default. And I dunno if it's slower or not, but the Python part of our code isn't the slow part, so that's all right.

03:53 KENNEDY: It's sort of irrelevant and interesting. Super cool. So I got a question for you. Do you feel like you're a real software developer?

04:01 OKKEN: Yes, when I'm not being a manager, yes.

04:04 KENNEDY: That's a different type of issue. Maybe like, other end of the spectrum. So I guess to answer the question myself, yeah, definitely, but it's interesting 'cause I did kind of like a smallish minor in computer science at best, right, so I don't have a CS degree. I was mostly self taught, I studied math, right.

04:22 OKKEN: What, you don't have a CS degree? What am I doing this podcast with you for?

04:25 KENNEDY: I know, well, it's really a fake one. I meant to tell you, like, we'll talk about that later. So, do I feel like a real software developer? I remember getting my first software development job, thinking like, oh, I'm not sure I can do this, like what do they expect from me? Maybe the expectations will be really different from what I can do. And I don't feel that way anymore, obviously, doing programming for 20 years but there's an interesting article called "Am I a Real Software Developer Yet?" by Sun-Li Beatteay and he's one of those folks kind of like me that changed careers along the way, didn't totally love what he was doing, so did something else and then came in through the sort of self taught direction and there's just all these layers of, like, hey, do I belong? Like can I call myself a software engineer or things like that, right. So it's a really interesting article kind of a journaling and charting his path through there, so it's pretty interesting. He says, look, there's a lot of folks who don't have these CS degrees who feel like it's not quite appropriate to call themselves software developers or software engineers, is the term he uses a lot in the article, and sometimes this comes up as imposter syndrome, and sometimes just people just think they're not a software developer so it's pretty interesting. He talks about how he went through like really started working on HTML and CSS and JavaScript and he wasn't really sure how to get, you know, had done some stuff, but wasn't really sure how to basically have anything to show for it, right? Like it's one thing to study CSS but to be a developer you really got to create things and have stuff to show off, right? One of the things I thought was cool from this article is he talks about how he built a portfolio site for his wife, who's a product designer.

06:06 OKKEN: Oh yeah.

06:06 KENNEDY: 'Cause I know, do people often ask you, hey, how do I get better at programming? Like I get this question all the time but often enough.

06:13 OKKEN: I don't get it enough.

06:15 KENNEDY: Yeah, I mean, people are like hey, I want to become a developer, I've taken this course or I've read that book, but do I really need to do? I think one of the key things that people can do both to have something to show in job interviews but also to just build their skills is to just create something, even if it's kind of like, not really that important for the world. Like there's this example I heard a long time ago, somebody who was friends with someone who did these pumpkin competitions, you know where you grow like the thousand pound pumpkins? And apparently that community had no website. No online place to live, I mean, maybe today it would just be Facebook, but there wasn't really a place for that so they decided, hey, I want to learn web development so I'm building a website and a community and a portal for pumpkin competitions. They didn't even care about pumpkins, but they did it so they could have a project, right and it turned out to be really good. So Sun-Li talks about basically immersing himself in podcasts and YouTube videos and all that stuff and so, okay, after that release, can I call myself a software engineer? And then then he found out on the web that people on Reddit and stuff said, "Well web development isn't real programming, that's just JavaScript, CSS, and HTML." So then he spent 18 months studying software development full time, and went so far as to quit his job and move in with his in-laws, which is pretty brave.

07:35 OKKEN: Wow.

07:35 KENNEDY: And then after awhile said, okay, after, am now I a software engineer after I got a job and I've been working for a couple of years? The internet says, "Eh, not really. You can't really be an engineer after a year or two."

07:49 OKKEN: Yeah, there's a bunch of mean people. The issue is he's hanging out in the wrong places.

07:51 KENNEDY: Yeah, I know. Yeah, I think it's Reddit. So basically he said, look, I went and I talked to a bunch of coworkers and stuff and just finally said, look, I'm really insecure about this stuff. Like, how do you guys feel? Do you feel this way, how do you deal with it? And he found that it's not that rare. I think anyone who's kind of in this stage asking themselves the question, am I a real software developer yet? They should check this out, I think it's pretty it would probably help a lot.

08:13 OKKEN: Yeah, and brave of him to put it all together. So congrats, that's cool, I got to check this out.

08:17 KENNEDY: I guess in the conclusion he says, well, am I a real software engineer yet? And said, I don't know. I think so, some people might say no, they can call me whatever they want. I don't care, I write code today, I solve awesome problems with it, and I'm really good at it, so I'm having fun and that's that. Right, like call me what you want. Oh, and by the way, he also is a software developer at Digital Ocean, so that's pretty cool.

08:38 OKKEN: If you get paid for it, man, you're a software engineer. So the engineer part is, I never got the software part 'cause I had a masters in CS, but my first job, it was doing software but I was surrounded by electrical engineers and mechanical engineers and people that engineer was part of their degree title and I didn't have any engineer, quote engineer in my education, it was computer science and there wasn't much science in that either.

09:08 KENNEDY: Right, exactly.

09:09 OKKEN: So it's the engineer part that I felt like an imposter for a long time until it was a couple years in, I was sitting down with a mechanical engineer and told him about my this, I don't know if I'm comfortable with this engineer title, and he said, well, I'm a mechanical engineer, so I solve mechanical problems using the tool set that I learned. What do you do? You solve problems using software. You're an engineer, get over it. So.

09:40 KENNEDY: That's pretty interesting. Yeah, yeah, you know, I also, the engineering term is cool like software engineer is definitely a pretty cool title, but I think, I dunno if someone asked me to give myself a title at that point in my career, I wouldn't necessarily choose engineer, I don't think. To me, engineer is applying these practices and techniques for building stuff that's like really well tested, most of the time. Right, like if I'm going to build a power factory like there's a bunch of well known examples of building factories and I could do that or if I'm going to build a bridge, the reason I build the bridge is 'cause the other bridges that were built are on that river and I need to put one on this river. But for software, like that's not very often done. If there's already a thing that exactly solves that problem, you just make a copy of it and solve it with that, you know what I mean? Like you just, because software's replicable we don't recreate the same thing as often so it's more of a creation process than it is applying the same steps. To me, that's kind of a distinction that I find in there, but that's also a bit of a diversion.

10:46 OKKEN: With building, what you described was a contractor, not an engineer.

10:51 KENNEDY: Yeah okay, fair enough.

10:52 OKKEN: Engineering in lots of different fields means lots of different things. Like civil engineering and all sorts of other kinds of engineering is, it isn't taking one thing and making seven of them. And even with bridges for that matter, you don't build the same bridge in the same place. You build a similar bridge in a different place with different wind characteristics and all that.

11:12 KENNEDY: Yeah all right, fair point. All right, let's go back to debugging.

11:14 OKKEN: Yeah, I guess in a debugging kick. So ran across this, a little package called Snoop and plus it's just got a fun name, but it's a set of debugging tools but it's like the printf debugging sort of stuff. It does a lot of stuff, actually to help with the debugging, but it's kind of like if you want to be the debugging without opening the debugger and one of the things it does really well is just you slap a decorator called snoop on a function and now when you run that function, run your code, whenever that function runs the lines that get run and the local variable values get printed to standard error. So you can just sort of run and if you've got standard error piped somewhere where you can see you can just kind of watch your code run with this. And then there's a bunch of little extra things you can do, like you can if you don't want to see the whole function you can focus in on just some values or a block of it with a with decorator. It is modifying your code to do that, but sometimes, if the alternative was you were going to throw a bunch of print statements in, this might save you some time and it's kind of a neat tool.

12:23 KENNEDY: Yeah, this is super cool. I hadn't heard of this before and I started looking through it and yeah, it's really nice. It's a little bit funky and I think for people to get a good sense of it, they should just jump over to the GitHub repo which we're linking to, obviously and just look at some of the pictures, right. Like you have nice color-coded bits of your code and then as it runs the values are kind of like greyed into where your code is. So it's like you're looking at your code but then actually the values of that execution are in there, and there's an example where it loops over something a couple of times and then that loop is just replicated as if you wrote it a bunch of times but different values, it's pretty cool.

13:02 OKKEN: Yeah, and for instance, I think a cool thing would be if you had, especially for situations where you've actually have tried to debug it with a debugger, and you're running with a multi-threaded system or something and you just can't capture the time where you're seeing the error so you can possibly turn this on and throw it into your continuous integration and pipe the output somewhere and be able to capture it.

13:26 KENNEDY: Yeah, exactly, and there's just times where attaching a debugger doesn't make a ton of sense, right. Maybe it's embedded Python, like CircuitPython or something and that doesn't, you know, you can't reasonably attach a debugger there because it's running on some device. The best you get is serial output or it's some kind of docker thing where it's a little bit hard to set up, or maybe it's even some kind of production thing, although I wouldn't put this in production, actually.

13:52 OKKEN: Yeah, but you could throw it in a staging environment, though, so.

13:54 KENNEDY: Yeah, yeah, yeah. Exactly, places where you don't have super easy access to setting up, you know, like you might have PyCharm installed or Visual Studio Code, but it's not super easy to get it all put together. Just throw this on there and see what happens, it's pretty cool. Also works in Jupyter, which is kind of nice.

14:09 OKKEN: Oh, cool.

14:09 KENNEDY: Yeah, this is definitely a good one. I'm happy you covered it. I'm going to keep it in mind for the next thing I got to do. All right, so before we move onto this next one, which is very, very interesting, it's quite the controversial thing, I want to tell you all about Datadog. That's not nearly as controversial. They're supporting Python Bytes and they've done so for a long time, so they're a cloud scale modern platform built by engineers for engineers, Brian. They're tracing stuff automatically, instruments like Django, Flask, Postgres, asyncio, and lets use visualize your application architecture and a whole bunch of other things like you could even read us, to allow you to watch traces across your servers to kind of put it all together into one view, not just what your web app is doing or what this background service is doing, things like that. Check them out at pythonbytes.fm/datadog and you'll get a cool t-shirt.

15:00 OKKEN: Nice.

15:00 KENNEDY: Yeah. So have you heard of this guy named Kenneth Wright?

15:04 OKKEN: Yeah, we've covered him a few times.

15:06 KENNEDY: He's created a couple libraries that are some people use them, I heard they're interesting. Actually, Kenneth's been on the show and he's done a ton of cool work, right, like Requests is amazing, he's got a bunch of other things going on as well. You know, Records, Responder, and so on. So definitely cool. However, he recently posted this comment about a week ago. "In the spirit of transparency, I'd like to publicly find a new home for all of my repositories. I want to be able to make some contribution to them, but I'm kind of done with being the owner and being the BDFL of these things." So that's kind of a pretty big statement. Like hey, Kenneth, who's in charge of all these things kind of just said I'm done with them which is, you know, not the end of them, obviously but that's a pretty big deal that somebody should probably address, right?

15:58 OKKEN: Yeah, definitely. Actually a lot of these projects, it's interesting, if they were any the communities around them, because they're not just one person, the communities around them have built up especially with things like Requests, there's a lot of people working with and working on it. Some of these are projects that have reached a size that most projects have already moved off of, moved into a group repo setting instead of staying with one owner setting.

16:23 KENNEDY: Like Pallettes and Flask, for example.

16:25 OKKEN: Yeah, exactly. I think it's a good thing, I don't see the controversy.

16:30 KENNEDY: Well there was like, some of the controversy a little bit was, if you go and look at that you'll see a bunch of people who may be super involved in Python, some people who are not very involved in Python at all, who are like, hey, I'll take over this or I'll take Requests, give that to me. It's like, whoa, whoa, whoa, wait a minute. Shouldn't some of these really important pieces have some careful thought about where they go? So there was a lot of back and forth and some of the smaller ones people picked up and they're taking over and so on but Ernest Dervin jumped in and said hey, you know, the Python Software Foundation would like to accept transfer of these repositories into the PSF GitHub organization. Apparently this is a new thing, the organization recently acquired the Python Software Foundation the GitHub, or, let me get this right. The GitHub organization was acquired by the PSF so they can control it rather than just some other random thing.

17:25 OKKEN: Oh yeah.

17:26 KENNEDY: And the idea is that this is to provide an administrative backstop for projects in the ecosystem, existing maintainers will still remain and the PSF staff will be able to help take care of things.

17:37 OKKEN: Okay, nice.

17:38 KENNEDY: That's a pretty good outcome, right?

17:39 OKKEN: And I think that's a good thing. I was just saying, like I wouldn't want these projects to go into just somebody else's name.

17:45 KENNEDY: Yes, exactly.

17:46 OKKEN: They should go into some group or something, so yeah.

17:49 KENNEDY: Yeah, and you know, I think the biggest news here is not that Requests is moving somewhere but that, hey, the PSF has a GitHub organization whose job it is to take over projects like this.

17:58 OKKEN: That's pretty cool, yeah. I think more stuff should go in there, then.

18:02 KENNEDY: Yeah, exactly. Yeah, we should let people know about it. So, I get the question also every now and then like, I have this project, it's open source but I'd kind of like to make it more of my job. How can I somehow keep with a spirit of open source and yet somehow have a commercial license or commercial something for my project? And this one that you pulled up here, this is pretty darn interesting.

18:26 OKKEN: I think it's interesting. I didn't know what to make of it at first.

18:30 KENNEDY: That's how I felt as well. I was like, is this even real? Is this a joke, what is this?

18:35 OKKEN: So the idea, this is from Eran Hammer and he's an open source developer and has created lots of things. I didn't know about him before this article, but the article is called "The Backwards Commercial License" and he's saying that there's a lot of, well some widely used projects will go kind of through three phases. The first phase being it's just got one project or one company using it, so that company or the individual person is using the use case. They're the one developing it, of course. But as things grow, if it becomes popular it'll go through a stage where you have active community members contributing features, there's a growing audience, and a lot of people are using it, and then later a lot of the people, the third stage is a lot of people kind of think it's done, and there's a few security fixes or bug fixes or minor features added, but for the most part what's working is working. You know, like you can use a nine year old version of K Shell and it works just fine. That sort of thing, at that point that's when it's not really that exciting to work on it, but a lot of people depend on it so how do you pay for that maintenance? And Eran's thought is at that done phase basically don't support old versions, only support the latest and greatest but have another name for something that's identical under a commercial license for maintained older versions. I think I kind of got that right?

20:04 KENNEDY: It sounds about right, yeah. I understood it the same way.

20:06 OKKEN: I think it's an interesting idea, and I'm not sure how the licensing would work 'cause you essentially have code developed by lots of people under an open source model. You'd have to have a different open source license to allow this, because all of the code would then be transferred into a commercial license for a maintenance phase or something.

20:26 KENNEDY: Yeah, I mean the logistics would be a little bit tricky, right, like let's just say Django, right. Like somebody has Django 0.5 and it's on 2 now, and they don't want to upgrade their code but they want some change done to it or there's a security fix or something and they're like, we'd rather pay you a thousand dollars a year so if a security problem is found in it, it just gets fixed rather than us having to do that migration to Django 2. Something like that, right? You'd have to somehow fork that into a private repo and then have some other channel for releasing that, right like some private authenticated thing that people can log into. I don't know exactly how it'd work. I don't know, how do you feel about it?

21:07 OKKEN: I think it seems like a reasonable way, if you set up the license ahead of time so people, for new projects, people knew about it, they know it's going to happen, and they know if you want to keep the current one and make sure that it always works with your code and keep testing it, you can do that for free. But if you want to be able to set and forget and say, oh no, this is doing enough for me, I'll just use it now and I don't want to deal with new stuff, yeah, maybe you should have to pay for that.

21:36 KENNEDY: It's pretty interesting. My first thought was it was kind of weird but the more I think about it, I'm not really super against it.

21:42 OKKEN: This isn't his first idea, though. Also in the article he talks about how he used to a lot of the projects were paid for by corporate sponsors but it wasn't very many of them, it was a handful of companies paying for something and then hundreds of companies getting it for free and then as more and more of those companies move into, it's good enough for us now, their support drops off.

22:07 KENNEDY: Yeah, I definitely feel like companies out there just get way more benefit from these types of projects than they're willing to give back. Even if that company, say, hires and employs some core developer of a project, but they're, like, let's just say a bank and this powers their trading engine that does a hundred billion dollars of revenue. Right, surely more than a hundred thousand dollars should go back to that project. Like surely some kind of larger contribution is reasonable to keep the ecosystem going. So I don't know, I feel like stuff that sets up a framework for companies to pay money legitimately to help keep open source going, I don't see a lot of great setups like that so this is something down the path that's worth considering.

22:51 OKKEN: Yeah, I think so. Interesting, cool.

22:53 KENNEDY: Well, also interesting is this next article that comes to us from Gi Bi on Twitter, I think it is. And did you know that Guido van Rossum had a Medium account and he's blogging there now?

23:04 OKKEN: No, well, just with this one.

23:08 KENNEDY: Yeah, well, now that it's here, right? So I don't know, actually, I didn't look at his other posts to see how long he's been doing this but this is the first I know about it. So he wrote an article called something, it's not the title I put here. It was "PEG Parsers," P-E-G parsers, and he talks about how the parser that actually parses syntax in Python in .py files, that code is some of the very first code that he wrote for Python thirty years ago.

23:36 OKKEN: Interesting, okay.

23:37 KENNEDY: Yeah, and it uses this LL1 parsing mechanism which is the right thing probably for thirty years ago but probably not the best thing now and so the one moniker there implies that as you're going through the tokens and parsing them in the syntax, you're looking ahead only one of them at a time, and so this actually limits the grammar rules that Python is allowed to have because the parsing is actually really limited. So he didn't say this in his article, but let me give you an example. Like in the C# language, they have the exact same concept as we have with yield, but their mechanism, their syntax does, say I want to yield something, is to say yield return the value. So yield is still a valid word in C# but yield return, those two combinations of separate statements, actually mean something different because in this context, this is a keyword but in a different context it's not.

24:40 OKKEN: Oh, weird.

24:41 KENNEDY: Yeah, so I think things like that are just not around in Python partly because the parsing just didn't deal with it. So anyway, he talks about the history of the parser and this idea of using this thing called a PEG parser which is more like a depth-first parsing thing that has an infinite look ahead buffer and it goes through and it basically parses the entire file. Well, it reads through the entire file, understands it, and then goes and does the parsing. So you can have infinite look ahead, you can go back as far as you want, and so on using something called packrat parsing which is kind of interesting. So basically before when memory was really cheap, like this was really expensive, really limited, this was a problem. Like the decimal module, like decimal.py or underscore decimal.py or whatever it's called is like 220K and actually loading that entire Python file to parse it turned out to be some kind of issue in the early days whereas, like, who cares about loading 200K now? Yeah, so I'm basically saying like look, it might be time to replace this super old but really polished and limited parser, that he calls PGEN, with something using PEG and packrat parsing and the way it works with abstract syntax tree might be able to have some interesting optimizations that actually make it use less memory anyway.

26:00 OKKEN: Oh yeah, that'd be interesting.

26:01 KENNEDY: Yeah, so this article's kind of interesting. It's interesting in a couple ways, it's interesting just hearing Guido think about the history and where it's come and you get a real good look at his thought process of should we change the language, should we not? Why did it come this way, how did we get to where we are? And also it's just cool that he's blogging.

26:20 OKKEN: Yeah, definitely. One of the benefits of him not having to do everything.

26:25 KENNEDY: Yeah, exactly, for sure. All right, well that's it for our main items. What else we got?

26:30 OKKEN: One of the things I wanted to bring up, sometimes we have a couple quick things that we didn't have huge topics on but Phillip Bauer works on Plone and he contacted us and said hey, Plone 5.2 is out and I'm like, okay, I don't use Plone but yeah, maybe we'd cover it. No, this is a big deal. So it's 5.2 is a multi-year effort, it was a really huge amount of work and Plone is a content management system built on top of Zope, which is a web application server framework, and a lot of this was in the early days targeting newspapers and things like that. But there's still a lot people using it, and 5.2 now supports all of the threes. At least 3.6, 7, and 8 which is super cool. And Zope 4 apparently supports Python 3 and it's all up to date now. And then if you want to read all about it we've got a link to the release announcement and also an interview with Phillip about some of the transitions.

27:30 KENNEDY: Multi-year effort, that's pretty intense. So another major project comes along and now is Python 3 only, that's awesome. Hey, do you think it's interesting that so many of these CMS's came from newspapers? Right, like Django also came from a newspaper in Lawrence, Kansas which, by the way, is where I went to college. So you know, who knows where Flask comes from.

27:52 OKKEN: Namedropping.

27:55 KENNEDY: Well Lawrence, Kansas is not a big place, so not a big name, but yeah. I had no idea till recently that it was from there. But yeah, it's just interesting that these Python web frameworks are coming from newspapers.

28:06 OKKEN: Yeah, it is interesting. Well, I guess it makes sense. You got a lot of people writing, adding content to stuff so CMS's, probably all the CMS's came from newspaper stuff.

28:16 KENNEDY: Yeah, that's probably true. Alright, well I have another one for you. This one is way less serious, and about a year and a half ago this probably would've been all just super cool, hip stuff. Now it's a little bit dated in some of the actions but there's this project called building Dab and T-pose controlled light, and Dab is like this...

28:37 OKKEN: This is pretty interesting, though. I mean, yeah, Dab might not be the current dance move of the day, but controlling your lights with dance moves, that's pretty neat.

28:49 KENNEDY: Someone built this thing with Python, this thing called Make Art with Python and you come in and you do a Dab move, which if you don't know what it is just click the link, there's like a little animated video, you'll totally see it right away. You do a Dab, that turns off the lights and then whenever you want to turn them on you do like a T, you just put your arms straight out and hold still for a second, and boom, the lights are on.

29:07 OKKEN: What I find super interesting about the article is the amount of effort that went into this. I mean, not by this person, he's utilizing a database of people movement and all that stuff so this is standing on the shoulders of giants to change a light bulb.

29:23 KENNEDY: Yes, exactly. How many computer vision specialists does it take to change a light bulb? I dunno. Could be a joke of some sort, but anyway this is pretty funny, people thinking of what they can do with Python and Computer Vision and yeah. Check it out.

29:38 OKKEN: Yeah, cool.

29:39 KENNEDY: All right, so I got a couple of jokes for you. These are quick ones, so I put two in here and they're related. Alright, so the first one, we both talked a little bit about C and what not. What is a whale's favorite programming language?

29:49 OKKEN: Well, C, but you just gave away the answer at the beginning of the...

29:55 KENNEDY: All right, well then, tell me why do Pythons live on land?

29:58 OKKEN: Why?

29:59 KENNEDY: Because it's above C level.

30:02 OKKEN: Yeah, okay.

30:03 KENNEDY: Yeah, well the first one comes to us from Eric Nelson, the second one from Jesper Sorensen. So thank you guys for sending those in.

30:08 OKKEN: Yeah, nice.

30:08 KENNEDY: I thought those were amusing, let's say amusing. I'm not going to go as far as saying funny, but amusing.

30:13 OKKEN: Yeah. Some levity.

30:14 KENNEDY: Cool. Yep, exactly. All right, well, good chatting with you as always.

30:19 OKKEN: Thanks, bye.

30:20 KENNEDY: Yep, see you. Thank you for listening to Python Bytes. Follow the show on Twitter via @PythonBytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at pythonbytes.fm. If you have a news item you want featured, just visit pythonbytes.fm and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian Okken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.

Back to show page