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


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

Return to episode page view on github
Recorded on Wednesday, Jul 24, 2019.

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

00:04 This is episode 141 recorded July 24th, 2019.

00:09 I'm Michael Kennedy.

00:10 And I'm Brian Okken.

00:10 And this episode is brought to you by Datadog.

00:13 Thank you Datadog for supporting the show.

00:15 Tell you more about them later.

00:16 Brian, how you been?

00:17 I'm good.

00:18 Really good.

00:18 Quite busy.

00:19 How about you?

00:20 Always busy.

00:20 I feel like life always supplies a little bit more friction to me these days.

00:24 You know, a little bit more email, a little bit more paperwork.

00:27 but that's the world I inhabit these days.

00:30 So it's all right, it's all good.

00:31 Last time we spoke about Flint, and Flint being a library or a little utility running as your Python code and will rewrite your expressions into f-strings, and f-strings are pretty awesome.

00:43 Actually, that was maybe two times ago, but Flint's been updated a lot.

00:47 There's been like five releases since we talked about it.

00:50 You're going to kick us off here with some more F string goodness, not to do with Flint, but just f-strings.

00:54 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 we, 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 like 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.

01:26 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.

01:34 - For the value, right. - Yeah.

01:35 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 - Yeah, so in Python 3.8, if I type, I have an f-string and I type curly brace foo equals equals closed curly brace, the output will be foo equals whatever the value of foo is.

01:56 Yeah, huge time saver.

01:58 It's cool.

01:58 Yeah, that's super cool.

01:59 I feel like you might have been doing some low-grade debugging, given all the items you're talking about this week.

02:06 I'm always doing low-grade debugging.

02:08 But along with that, we're linking to some Python docs.

02:13 But there's also a couple of other things associated with that.

02:15 You can normally, with fstrings, you get the wrapper value of an object.

02:22 But you can have an s decorator on it with a bang or bang s.

02:26 It'll do the string operator instead.

02:29 And then for floating point numbers, you're going to be allowed to do modifiers.

02:34 So if you just want two or three decimal places or something, you can do that.

02:38 That's really cool.

02:39 So you can use this little equals thing and then at the end stick a formatting instruction like colon dot 2f or colon comma or something like that.

02:47 - Yeah, it's like finally I think Python's getting to a point where it's just printing, debugging with printf, I'm a C guy.

02:55 So debugging with print statements is usable now, so great.

02:59 - Yeah, that's really cool.

03:01 There was some comment on the fstring episode, the 139 that I talked about at the beginning here.

03:06 I can't remember the guy's name, but at the bottom of the show page, he put a comment saying, "Look, I'm a old C guy." So I had said I love to use fstrings, but I always find myself halfway into the string, and like, oh, the F goes at the front.

03:18 This one I actually need to do some sort of formatting, so I have to go back and do it.

03:21 And it's a hassle.

03:22 He says, well, because I'm a C guy-- and you just mentioned it as well-- I think print F, parentheses.

03:28 So I just move the parentheses up a little bit.

03:30 That's a good mnemonic.

03:31 Yeah.

03:31 Exactly.

03:32 I like it.

03:32 Split this-- print F. Yeah, exactly.

03:34 So a lot of my team is jumping on board with the f-strings as well, so much so that often strings will be f-strings, and there's nothing in it being formatted.

03:44 It's just they're just using F by default.

03:46 And I don't know if it's slower or not, but the Python part of our code isn't the slow part.

03:52 So that's all right.

03:53 - It's sort of irrelevant.

03:54 Yeah, interesting.

03:56 Super cool.

03:57 So I got a question for you.

03:58 Do you feel like you're a real software developer?

04:01 (laughing)

04:02 - Yes.

04:03 When I'm not being a manager, yes.

04:04 - That's a different type of issue.

04:06 Maybe like other end of the spectrum.

04:08 So I guess to answer that question for myself, yeah, definitely.

04:11 But it's interesting, because I did kind of like a smallish minor in computer science at best.

04:18 So I don't have a CS degree.

04:20 I mostly self-taught.

04:21 I studied math.

04:22 What?

04:22 You don't have a CS degree?

04:23 What am I doing this podcast with you for?

04:25 I know.

04:25 Well, it's really a fake one.

04:27 I meant to tell you.

04:29 We'll talk about that later.

04:30 So do I feel like a real software developer?

04:33 I remember getting my first software development job thinking like, oh, I'm not sure I can do this.

04:37 What do they expect from me?

04:38 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 Betye. 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 this sort of self-taught direction. And And there's just all these layers of like, hey, do I belong?

05:11 Like, can I call myself a software engineer or things like that, right?

05:15 So it's a really interesting article, kind of a journaling and charting his path through there.

05:21 So it's pretty interesting.

05:22 It 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.

05:31 It's the term he uses a lot in the article.

05:34 And sometimes this comes up as imposter syndrome, and sometimes people just think they're not a software developer.

05:40 So it's pretty interesting.

05:41 He talks about how he went through--

05:44 really started working on HTML and CSS and JavaScript, and wasn't really sure how to get--

05:49 had done some stuff, but wasn't really sure how to basically have anything to show for it.

05:54 It's one thing to study CSS, but to be a developer, you really got to create things and have stuff to show off.

06:00 One of the things I thought was cool from this article he talks about how he built a portfolio site for his wife, who's a product designer.

06:06 - Oh yeah.

06:07 - 'Cause I know, do people often ask you like, "Hey, how do I get better at programming?" Like I get this question all the time, but often enough.

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

06:14 - Yeah.

06:16 Yeah, I mean, people are like, "Hey, I wanna become a developer.

06:18 "Like I've taken this course, I've read that book, "but what 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, and also to just build their skills, is to just create something.

06:29 even if it's kind of like not really that important for the world.

06:34 Like there's this example I heard a long time ago, somebody who was friends with someone who like did these pumpkin competitions, you know, where you grow like the thousand pound pumpkins.

06:45 And apparently that community had no website, no online place to live.

06:52 I mean, maybe today it would just be Facebook, but there wasn't like really a place for that.

06:56 So they decided, hey, I wanna learn web development.

06:57 development, so I'm building a website and a community and a portal for pumpkin competitions.

07:03 They didn't even care about pumpkins, but they did it so they could have a project, right?

07:06 And it turned out to be really good.

07:07 So suddenly he talks about basically immersing himself in podcasts and YouTube videos and all that stuff.

07:15 And so, OK, after that release, can I call myself a software engineer?

07:18 And then he found out on the web that people on Reddit and stuff said, well, web development isn't real programming.

07:23 It's just JavaScript, CSS, and HTML.

07:25 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 - Wow.

07:35 - And then after a while, I said, okay, after I'm now a software engineer, after I got a job and I've been working for a couple years, internet says, "Eh, not really.

07:44 "You can't really be an engineer after a year or two." So--

07:48 - Yeah, there's a bunch of mean people.

07:50 He's hanging out in the wrong places.

07:52 - Yeah, I think it's Reddit.

07:53 So basically he said, "Look, I went and I talked to bunch of coworkers and stuff, and just finally said, look, I'm really insecure about this stuff.

07:59 Like, how do you guys feel?

08:00 Do you feel this way?

08:00 How do you deal with it?

08:02 And found out that it's not that rare.

08:04 I think anyone who's kind of in this stage, like asking themselves the question, am I a real software developer yet?

08:09 They should check this out.

08:10 I think it's pretty--

08:12 it would probably help a lot.

08:13 Yeah, and brave of him to put it all together.

08:15 So congrats.

08:16 It's cool.

08:16 I got to check this out.

08:17 I guess at the conclusion, he says, well, am I a real software engineer yet?

08:21 And said, I don't know.

08:24 I think so.

08:24 Some people might say no, then comment whatever you want.

08:27 I don't care.

08:28 I write code today.

08:29 I solve awesome problems with it, and I'm really good at it.

08:31 So I'm having fun, and that's that.

08:33 Call me what you want.

08:35 Oh, and by the way, he also is a software developer at DigitalOcean.

08:38 So that's pretty cool.

08:39 If you paid for it, man, you're a software engineer.

08:41 So the engineer part is--

08:43 I never got the software part because I had a master's in CS.

08:48 But my first job, it was doing software.

08:51 But I was surrounded by electrical engineers and mechanical engineers and people that engineer was part of their degree title.

09:00 And I didn't have any "engineer" in my education.

09:05 It was computer science.

09:07 And there wasn't much science in that either.

09:09 Right, exactly.

09:09 So it's the engineer part that I felt like an imposter for a long time.

09:13 And until a couple of years in, I was sitting down with a mechanical engineer and told him about my, I don't know if I'm comfortable with this engineer title.

09:25 And he said, well, I'm a mechanical engineer, so I solve mechanical problems using the tool set that I learned.

09:33 What do you do?

09:34 You solve problems using software.

09:37 You're an engineer.

09:38 Get over it.

09:40 So--

09:40 That's pretty interesting.

09:41 Yeah, yeah.

09:43 The engineering term is cool.

09:45 Software engineer is definitely a pretty cool title.

09:47 But I think-- I don't know.

09:50 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.

09:56 To me, engineering is applying these practices and techniques for building stuff that's really well tested most of the time.

10:05 If I'm going to build a power factory, there's a bunch of well-known examples of building factories, and I could do that.

10:14 Or if I'm going to build a bridge, The reason I build the bridge is because like 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.

10:24 If there's already thing that exactly solves that problem, you just make a copy of it and solve it with that.

10:29 You know what I mean?

10:30 Like you just, because software is replicable, we don't recreate the same thing as often.

10:36 So it's more of a creation process than it is applying the same steps to me.

10:42 That's like, that's kind of a distinction that, that I find in there, but that's That's also a bit of a diversion.

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

10:51 Yeah, okay, fair enough.

10:52 Engineering in lots of different fields means lots of different things.

10:55 Like civil engineering and all sorts of other kinds of engineering, it isn't taking one thing and making seven of them.

11:03 And even with bridges, for that matter, you don't build the same bridge in the same place.

11:07 You build a similar bridge in a different place with different wind characteristics and all that.

11:12 Yeah, all right, fair point.

11:13 All right, let's go back to debugging.

11:14 I guess in a debugging kick. So I 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 debugging. But it's kind of like if you want to be debugging without opening the debugger. And one of the things that 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.

11:53 So you can just sort of run, and if you've got standard error pipe somewhere where you can see, you can just kind of watch your code run with this.

12:01 And then there's a bunch of little extra things you can do.

12:05 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 width decorator.

12:14 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.

12:22 And it's kind of a neat tool.

12:23 - Yeah, this is super cool.

12:24 I hadn't heard of this before, and I started looking through it, and yeah, it's really nice.

12:29 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?

12:38 Like you have nice color coded bits of your code.

12:42 And then as it runs, the values are kind of like grayed into where your code is.

12:49 So it's like you're looking at your code, but then actually the values of that execution are in there.

12:53 And there's an example where it loops over something a couple of times.

12:56 And then that loop is just replicated as if you wrote it a bunch of times, but different values.

13:01 It's pretty cool.

13:02 Yeah.

13:02 And for instance, I think a cool thing would be if you've had--

13:07 especially for situations where you 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.

13:18 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 Yeah, exactly.

13:26 And there's just times where attaching a debugger doesn't make a ton of sense.

13:30 Maybe it's embedded Python, like CircuitPython or something, And you can't reasonably attach a debugger there because it's running on some device.

13:40 The best you get is like serial output.

13:42 Or it's some kind of Docker thing where it's a little bit hard to set up.

13:47 Or maybe it's even some kind of production thing.

13:49 Although I wouldn't put this in production, actually.

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

13:55 -Yeah, yeah, yeah, exactly.

13:56 Places where you don't have super easy access to setting up.

13:59 Like you might have PyCharm installed, or Visual Studio Code.

14:02 but it's not super easy to get it all put together.

14:04 Just throw this on there and see what happens.

14:06 It's pretty cool.

14:07 Also works in like Jupyter, which is kind of nice.

14:09 Oh, cool.

14:09 Yeah, this is definitely a good one.

14:10 I'm happy you covered it.

14:12 Keep it in mind for the next thing I've got to do.

14:14 All right, so before we move on to this next one, which is very, very interesting.

14:19 It's quite the controversial thing.

14:21 I want to tell you all about Datadog.

14:22 That's not nearly as controversial.

14:24 They're supporting Python bytes, and they've done so for a long time.

14:27 So they're a cloud scale monitoring platform built by engineers for engineers, Brian.

14:32 They're tracing stuff automatically, instruments like Django, Flask, Postgres, AsyncIO, lets you visualize your application architecture and a whole bunch of other things like Hadoop and Redis to allow you to watch traces across your servers to kind of put it all together into like one view, not just what your web app is doing or what this background service is doing, things like that.

14:55 Check them out at pythonbytes.fm/datadog and you'll get a cool t-shirt.

15:00 - Nice. - Yeah.

15:01 So have you heard of this guy named Kenneth Wright?

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

15:06 - He's created a couple of libraries that are, some people use them, I heard they're interesting.

15:10 Now actually, you know, Kenneth's been on the show, and he's done a ton of cool work, right?

15:17 Like, requests is amazing, he's got a bunch of other things going on as well, you know, records, responder, and so on.

15:25 So definitely, definitely cool.

15:27 However, he recently posted this comment about a week ago.

15:32 "In the spirit of transparency, "I'd like to publicly find a new home "for all of my repositories.

15:38 "I wouldn't be able to make some contribution to them, "but I'm kind of done with being the owner "and 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 not the end of them, obviously, but that's a pretty big deal that somebody should probably address, right?

15:58 - Yeah, definitely.

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

16:09 There's a lot of people working with it and working on it.

16:12 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 - Like pallets and flask, for example.

16:25 - Yeah, exactly.

16:26 I think it's a good thing.

16:28 I don't see the controversy.

16:30 - Well, there was 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 are like, "Hey, I'll take over this," or, "I'll take requests, give that to me." It's like, wait, wait, wait, wait a minute.

16:49 Shouldn't some of these really important pieces to have some careful thought about where they go.

16:56 So there was a lot of back and forth, and some of these smaller ones, people picked up and they're taking over and so on.

17:02 But Ernest Durbin 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.

17:14 The organization recently acquired the Python Software Foundation.

17:18 The GitHub, or let me get this right, that GitHub organization was acquired by the PSF, so they can control it, rather than just some other random thing.

17:25 >> Yeah. >> And the idea is that this is to provide an administrative backstop for projects in the ecosystem.

17:31 Existing maintainers will still remain, and the PSF staff will be able to help take care of things.

17:37 >> Okay, nice.

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

17:39 >> And I think that's a good thing.

17:40 I was just saying, I wouldn't want these projects to go into just somebody else's name. >> Yes, exactly.

17:46 they should go into some group or something.

17:48 So, yeah.

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

17:59 - That's pretty cool, yeah.

18:00 I think more stuff should go in there than--

18:02 - Yeah, exactly.

18:03 Yeah, we should let people know about it.

18:05 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.

18:14 how can I somehow keep with the spirit of open source and yet somehow have a commercial license or commercial something for my project?

18:23 And this one that you pulled up here, this is pretty darn interesting.

18:26 - I think it's interesting.

18:28 My first, I didn't know what to make of it at first.

18:30 - That's how I felt as well.

18:31 I was like, what is, like, is this even real?

18:33 Is this a joke?

18:34 What is this?

18:35 - So the idea, this is from Aaron Hammer, and he's an open source developer and has created lots of things.

18:41 I didn't know about him before this article, But the article is called the Backwards Commercial License.

18:47 And he's saying that there's a lot of--

18:50 well, some widely used projects will go kind of through three phases.

18:55 First phase being it's just--

18:57 it's got one project or one company using it.

19:01 So that company or the individual person is using the use case.

19:04 They're the one developing it, of course.

19:06 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.

19:18 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.

19:28 But for the most part, what's working is working.

19:32 You can use a nine-year-old version of KShell, and it works just fine.

19:36 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.

19:44 So how do you pay for that maintenance?

19:46 And Aaron'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 maintain older versions.

20:02 I think I got that right.

20:04 - It sounds about right, yeah.

20:05 I understood it the same way.

20:06 - I think it's an interesting idea.

20:07 And I'm not sure how the licensing would work 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 to a, into a commercial license for a maintenance phase or something.

20:26 Yeah, I mean, the logistics would be a little bit tricky, right? Like, let's just say Django, right? You like, somebody has Django 0.5. And it's on two 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, they're like, we'd rather pay you $1,000 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.

20:52 Something like that, right?

20:52 - Yeah.

20:53 - You'd have to like somehow fork that into a private repo and then have some other channel for releasing that, right?

21:01 Like some private authenticated thing that people can log into.

21:05 I don't know exactly how it worked.

21:06 I don't know.

21:06 How do you feel about it?

21:07 I think it seems like a reasonable way, if you set up the license at a time, so people--

21:12 for new projects, people knew about it.

21:14 They know what's going to happen.

21:16 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.

21:24 But if you want to be able to set and forget and say, no, this is-- it's doing enough for me.

21:30 I'll just use it now.

21:32 And I don't want to deal with new stuff.

21:34 - Yeah, maybe you should have to pay for that.

21:36 - It's pretty interesting.

21:37 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 - This isn't his first idea, though.

21:44 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.

21:53 It was a handful of companies paying for something and then hundreds of companies getting it for free.

22:00 And then as more and more of those companies move into it's good enough for us now, their support drops off.

22:07 - 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.

22:16 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 $100 billion of revenue, surely more than $100,000 should go back to that product.

22:34 Surely some kind of larger contribution is reasonable to keep the ecosystem going.

22:39 So I don't know.

22:40 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.

22:49 So this is something down that path that's worth considering.

22:51 - Yeah, I think so.

22:52 Interesting.

22:53 - Cool, well, also interesting is this next article that comes from us from Gibi on Twitter, I think it is.

23:00 And did you know that Gita Van Rossum had a Medium account, and he's blogging there now?

23:05 - No, well, just with this one.

23:08 - Yeah, well, now that it's here, right?

23:09 So I don't know, actually, I didn't look at those other posts to see how long he's been doing this, but this is the first I know about it.

23:14 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 and .py files, That code is some of the very first code that he wrote for Python 30 years ago.

23:36 - Interesting, okay.

23:37 - Yeah, and it uses this LL1 parsing mechanism, which is the right thing probably for 20 years, 30 years ago, but probably not the best thing now.

23:49 And so the one moniker there implies that, like, as you're going through the tokens and parsing them in the syntax, you're looking at only one of them at a time.

23:58 And so this actually limits the grammar rules that Python is allowed to have because the parsing is actually really limited.

24:05 So he didn't say this in his article, but let me give you an example.

24:08 Like in the C# language, they have the exact same concept as we have with Yield, but their mechanism, their syntax to 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 it can more complicate, like in this context, this is a keyword, but in a different context, it's not.

24:40 - Oh, weird.

24:41 - Yeah, so I think things like that are just not around in Python, partly because the parsing just didn't deal with it.

24:48 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 lookahead buffer.

24:59 And it goes through and it basically parses the entire file.

25:02 Well, it reads through the entire file, understands it, and then goes and does the parsing.

25:07 So you can have infinite lookahead, you can go back as far as you want, and so on, using something called pack-wrap parsing, which is kind of interesting.

25:15 So basically before, when memory was really cheap, like this was really expensive, really limited, this was a problem.

25:22 Like the decimal module, like decimal.py or underscore decimal.py, whatever it's called, is like 220K.

25:31 And actually loading that entire Python file to parse it turned out to be some kind of issue in the early days.

25:38 Whereas, who cares about loading 200K now?

25:41 - Yeah.

25:42 - Yeah, so I'm basically saying, look, it might be time to replace this super old but really polished, limited parser that they called PGEN with something using PEG and PacREC parsing the way it works with the abstract syntax tree might have some interesting optimizations that actually make it use less memory anyway.

26:00 Oh, yeah.

26:00 That'd be interesting.

26:01 Yeah, so this article is kind of interesting.

26:03 It's interesting in a couple of ways.

26:04 It's interesting just hearing Guido think about the history and where it's come.

26:10 And you get a real good look at his thought process of, should we change the language?

26:15 Should we not?

26:16 Why did it come this way?

26:17 How did we get to where we are?

26:19 Also, it's just cool that he's blogging.

26:21 Yeah, definitely.

26:23 - One of the benefits of him not having to do everything.

26:25 - Yeah, exactly, for sure.

26:27 All right, well, that's it for our main items.

26:28 What else we got?

26:30 - One of the things I wanted to bring up, sometimes we have a couple of quick things that we didn't have huge topics on, but Philip 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 cover it." No, this is a big deal.

26:48 So it's 5.2 is a multi-year effort.

26:52 It was a really huge amount of work.

26:54 And Cologne is a content management system built on top of Zope, which is a web application server framework.

27:01 And a lot of this was in the early days targeting like newspapers and things like that.

27:07 But there's still a lot of people using it.

27:09 And 5.2 now supports all of the threes, at least 3.6, 7, and 8, which is super cool.

27:15 And Zope 4 apparently supports Python 3, and it's all up to date now.

27:20 And then if you want to read all about it, we've got a link to the release announcement and also an interview with Philip about some of the transitions.

27:30 - Multi-year effort, that's pretty intense.

27:33 So another major project comes along and now is Python 3 only, that's awesome.

27:38 - Yeah.

27:39 - Do you think it's interesting that so many of these CMSs came from newspapers, right?

27:43 Like Django also came from like a newspaper in Lawrence, Kansas, which by the way, it's where I went to college.

27:50 So just, you know, who knows where that's coming from.

27:53 - Name dropping.

27:53 (laughing)

27:55 - Well, Lawrence, Kansas is not a big place, so not a big name, but yeah.

27:59 I had no idea until recently that it was from there.

28:01 But yeah, it's just interesting that these Python web frameworks are coming from newspapers.

28:06 - Yeah, it is interesting.

28:07 Well, I guess it makes sense that you got a lot of people writing, adding content to stuff, so CMSs, probably all the CMSs came from newspaper stuff.

28:16 - Yeah, that's probably true.

28:17 All right, well, I have another one for you.

28:19 This one is way less serious.

28:20 And about a year and a half ago, this probably would have been like all just super cool hip stuff.

28:26 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.

28:36 And dab is like this--

28:37 - This is pretty interesting though.

28:39 I mean, yeah, dab might be the, not might be the current dance move of the day, but controlling your lights with dance moves, That's pretty neat.

28:49 Someone built this thing with Python, this thing called Make Art with Python.

28:53 And you come in and you do a dab move, which if you don't know what it is, just click the link.

28:56 There's a little animated video.

28:58 You'll totally see it right away.

28:59 You do a dab.

29:00 That turns off the lights.

29:01 And then whenever you want to turn them on, you do a T.

29:03 Just put your arm straight out and hold still for a second, and boom, the lights are on.

29:06 What I find super interesting about the article is the amount of effort that went into this.

29:12 I mean, not by this person.

29:14 He's utilizing a database of people movement and all that stuff.

29:19 So this is like standing on the shoulders of giants to change a light bulb.

29:23 - Yes, exactly.

29:24 How many computer vision specialists does it take to change a light bulb?

29:29 I don't know.

29:30 Could be a joke of some sort.

29:31 But anyway, this is pretty funny.

29:33 People thinking of what they can do with like Python and computer vision.

29:35 And yeah, check it out.

29:38 - Yeah, cool.

29:39 - All right, so I got a couple of jokes for you.

29:41 These are quick ones, so I put two in here and they're related.

29:43 - Okay.

29:44 when we talked, we talked a little bit about C and whatnot. What is a whale's favorite programming language? C, but you just gave away the answer at the beginning of the...

29:52 All right. Well then, tell me why do pythons live on land?

29:58 Why? Because it's above sea level.

30:00 Yeah. Okay. 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. Yeah, that's where...

30:09 Nice. Let's say amusing. I'm not sure I'm going to go as far as saying funny, but amusing.

30:13 Yeah, some levity.

30:15 Cool.

30:15 Yep, exactly. All right. Well, good chat with you as always.

30:19 Thanks. Bye.

30:20 Yep. See ya.

30:21 Thank you for listening to Python Bytes. Follow the show on Twitter via @PythonBytes.

30:25 That's Python Bytes as in B-Y-T-E-S. And get the full show notes at pythonbytes.fm.

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

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

30:38 On behalf of myself and Brian Okken, this is Michael Kennedy.

30:42 Thank you for listening and sharing this podcast with your friends and colleagues.

Back to show page