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 #132:
Algorithms as objects

Recorded on Wednesday, May 22, 2019.

00:00 KENNEDY: Hello, and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is Episode 132, recorded May 22nd, 2019. I'm Michael Kennedy.

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

00:12 KENNEDY: And this episode is brought to you by DigitalOcean. Check them out at pythonbytes.fm/digitalocean. More about that later. Brian, how've you been?

00:00 OKKEN: I'm good, but I'm giggling right now, 'cause I've been looking up jokes, but we'll get to those later.

00:23 KENNEDY: Yeah, I always look forward to the jokes, and I think a lot of people out there seem to appreciate them. So, yeah, we won't disappoint this time. We got more lined up, as always.

00:30 OKKEN: Yeah, okay.

00:31 KENNEDY: I mean, like in the past, you maybe, you just have to come up with these but we have the internet.

00:36 OKKEN: Yeah, I know.

00:37 KENNEDY: It's beautiful.

00:37 OKKEN: It's easy to be a dad now.

00:39 KENNEDY: That's right. All right, you wanna kick us off with a little embedded Python?

00:42 OKKEN: Yeah, I was really excited to watch this. So I did meet, so the first one I've got up is the history of CircuitPython. And, this was actually on the PSF blog, and I think that Jesse Jiryu Davis put it up. But anyway, it's about the history of CircuitPython, and Adafruit, and Scott Shawcroft. Which, I met Scott at PyCon, and I knew he was involved with CircuitPython, but I guess I didn't realize he's the CircuitPython guy. So, what happened was, and I always kinda wondered about this, like the relationship between MicroPython and CircuitPython.

01:17 KENNEDY: Right, I knew about MicroPython being for embedded devices. And I'm like, oh, there's now CircuitPython, like, are they friends, are they frenemies? Like, one is a specialization of the other? What are they?

01:28 OKKEN: So, what happened was Adafruit thought MicroPython was a pretty cool thing, and hired Scott to port it to their, I guess their SAMD21 chip that's used on many of the boards. So, he did it. He's working on it. And, at first it was just a fork, but now it's a fairly big changed fork. There's a lot of differences. But, Scott said it's a friendly fork, so he works closely with the MicroPython people too, and they share code back and forth. So there's no hard feelings there. But it's focused on the Adafruit boards. But it's also, MicroPython is also focused really just on embedded stuff, whereas CircuitPython is focused on beginners. And, one of Scott's quotes is, "Our goal is to focus on the first five minutes someone has ever coded." That's a strong, lofty goal. But watching some of their demos with the CircuitPython, it isn't surprising to me, to run, they just hook it up, and a few minutes later, they've got stuff running. It's kind of incredible.

02:30 KENNEDY: Yeah, that's really awesome. And that is a very impressive goal, to say we're focused on the first five to 10 minutes of somebody programming, because yeah, that's an early point in the life cycle. But I guess you got, you know, it's gotta start somewhere. And I do think these embedded devices really do bring some realism to programming for people who may be programming just in the more theoretical way. Didn't necessarily connect, so it's great.

02:56 OKKEN: One of the things I didn't know about was with one of the things that CircuitPython does is, it outputs, like all the print statements go automatically to the serial output. So, if you hook up your serial output to a connected display, you don't even have to have any other device. You can just see your prints and stuff, so, that's kinda neat.

03:14 KENNEDY: That's awesome, and Nina Zakharenko actually showed how to use this, and like, I think it was Visual Studio Code, she had that serial output connected so just within Visual Studio Code, the device's output would just stream at the bottom.

03:29 OKKEN: That's so cool. And then, we're also including a link to the release notes for CircuitPython 4.0.0. So, that's a new major number so there's a couple of breaking things. But that looks kind of neat.

03:43 KENNEDY: Yeah, that's super. And apparently they're not on the ZeroVer philosophy.

03:48 OKKEN: Yeah, no. So, that's good.

03:50 KENNEDY: Maybe read it reverse or ZeroVer, like, 0.0.4. I dunno, anyway. If you must. But no, that's cool. It's great that there's a new version of that out, and I really think they're doing a lot of cool stuff. The Adafruit folks are doing a lot of cool things, and some of those devices, I think, were given out at PyCon this year, as well, which is pretty neat. So, we've talked about Python being popular, right?

04:12 OKKEN: Yes.

00:00 KENNEDY: Yeah, absolutely, so, this next article that I wanna cover is by dice.com, doing a little bit of analysis of the TIOBE Index. So, we've talked about TIOBE before. This is a programming index. Talks about how popular languages are. And, one of the areas of major growth in Python has to do with the data science space, and just the scientific computing in general. So this article that I wanna highlight, the title is R Risks Python Swallowing It Whole, according to TIOBE. So, that's pretty interesting. There used to be kind of a debate. Do I use R, do I use Python? Well, it looks like there's a lot of consolidation, and all this growth in Python is somewhat a zero-sum game for the other languages. So it might be interesting to check out if you're thinking, should I learn R, or should I learn Python? R has a lot of interesting advantages over Python. But it seems like Python is kinda winning the day. So, R has tumbled out of the top 20 languages, and now is somewhere below that.

05:16 OKKEN: It's very popular with a lot of people, but I didn't even hear about it until maybe a year ago.

05:20 KENNEDY: For sure. Yeah, it's definitely focused on more of a niche space. So, the article speculates, sort of not super effectively, why they think that is. Like, they ask a question like, well, it seems that Python is winning in data science, but why? And so I thought, maybe I'd throw my own commentary in here, and there's this idea like, I really like to talk about with Python being a full spectrum programming language. And what I mean by that is like, you can get started with the absolute minimum amount of effort. There's no compilers, no linkers, there's no header files. There's a single file, and you can say print, print('hello word'). Right, and that's it. You don't need to think about generators, or all the other stuff that rich programming languages have. Think C#, Java, C++, right. You've gotta like do all this ceremony to get going. But the value of those other languages is like, you can go build video games, or operating systems, or you know, whatever, right? And you can do much of that kind of stuff, not operating systems necessarily, but like, you can build real apps, professional apps in Python. And it kind of scales from this ultra beginner part where you can partially understand the language and be effective, all the way up to using metaclasses, and decorators, and generators to build, I don't know, Instagram, or whatever. And I think that that's actually why Python is winning in the space, 'cause the data scientists, scientific computing folks are coming in and they're like, I don't wanna be a programmer. I want to use programming to solve my problem. And Python lets them start that super easy path, but grow into where they eventually find themselves.

07:00 OKKEN: One of the things, also, is that people that have to reach towards R, or some other programming language, that's not their only software issue that they may have. And, if you can solve it with Python, you learn Python, and then you can solve other automation things within your workflow, as well. Whereas R has very focused, I don't know how much you can do with it outside of data science.

07:22 KENNEDY: That's for sure. That's definitely part of the story. Speaking of stories, you've got a little history lesson for us, right?

07:27 OKKEN: I've had this on the list for a while, but it took me, I just went back and read it yesterday. It's an article by, I think it's Aymen El Amri, called The Missing Introduction To Containerization. And so container systems like Docker, and stuff like that, lots of people use them, and I do want to ramp up learning how to use them more. I'm kind of one of those people that need a mental model of how all this stuff works. And, this is it. So, it starts with a 1979 release of something called, I don't even know how to pronounce this. Chroot? C-H-R-O-O-T.

08:05 KENNEDY: Cha-root, sha-root chu-root.

08:06 OKKEN: Yeah. Anyway, Chroot Jail, which was a way to isolate a root process and its children from the rest of the OS. But there was a bunch of problems with, there wasn't really meant for security. And I'm not gonna read the whole thing, but it builds up. Because of this is open source, FreeBSD improved on it, then Linux Vserver, and then Oracle Solaris had some stuff, OpenVZ, and then Google chimed in with something called CGroups, and then, a group called Linux Containers did LXC. And then, you know, it kind of built up. CloudFoundry got involved, and then, in 2013, Docker. And then, Google's still doing more stuff with making things easier. But all this stuff builds up on itself, and I really like that bit of a history lesson of how things built on itself. And then it jumps into talking about the differences, all the different terms you'll find, like system virtual machine, or process virtual machine, and VPS, and what all those things mean. Also the, kind of the difference between an operating system, container system, and an app container. And Docker is a little bit of a mix of both. Also, it's kind of containers and platforms. Just, why there's so many things around is kind of described in this. And then that's only like halfway through the article. The rest of the article jumps into, I think it's creating a container system from scratch, based on some of these libcontainer things. And, yeah, I don't wanna do that, so. But, the first half of it, definitely recommend. It's a good article.

09:40 KENNEDY: Yeah, the history here is really interesting. I guess when I first learned about Docker, I thought like, oh, Docker invented containers, right? But, absolutely not, right? They were building on LXC, and all these other things, and, eventually, they sort of moved off that, but, yeah. They were just making containers more accessible and easier for folks and popularizing it. I think these containers are super powerful, and super interesting. To me, I dunno, do you feel like they're complicated?

10:07 OKKEN: It seems like the system is made to not be but I know there's a lot of stuff behind the scenes going on. And I, you know, to be honest, I haven't played with them much, or used them. I don't need them for my normal job. But I would like to learn more. How about you?

10:22 KENNEDY: I definitely like them. I'm not doing anything with them right now. And I've thought about how using containers might make sense, but at the same time, I have lightweight VMs I just fire up, and, like they're dedicated to a single purpose. So, I don't know, it's always a bit of a trade-off of like, adding more complexity I feel like it's a little bit of a whack-a-mole problem. I could have more simplicity in some places, but I've like pushed it to another. So, for example, people talk about containers often being a great way to simplify development environments for junior developers, okay? Right, so, like I'm gonna work in a new company. Our app infrastructure is super complicated. So, what they do is they say, well, here's like three containers. One runs a database, one runs the web frontend, and one runs the caching tier, or whatever the heck it is. And I'm gonna just run those, and I'll just develop in that, regardless of what my machine's set up like. Well, that's, on one hand, simpler. I set maybe, docker-compose up. And boom, my little environment's working. But now I've gotta figure out how does my editor do remote debugging of Docker containers, and how do I step across calls between containers in my debugger, and all this other stuff. It's like, okay, so, I've moved set up complexity to editor complexity, or other stuff, right? So, I don't know, it's super interesting. I certainly see them being really valuable for like, zero downtime deployments, and other kinds of stuff. But, yeah, it's interesting.

11:49 OKKEN: In my wacky corner of the universe, the place where I probably would use them is, we often wanna spin up a new build server, or something like that. And, we have it written down of how to build a build server, and even though it's on a virtual machine, we've gotta install a bunch of stuff, and it's a half a day to get it up and running. And having that just saved off.

00:00 KENNEDY: Yeah, that's a perfect example of Docker, right? 'Cause you can build the container images to just do that set up, and you just say, you know, docker build, and boom, you're ready. Yeah, I like that. Speaking of containers, and all those good things, let's talk really quick about DigitalOcean, some of the stuff they have to offer. So DigitalOcean, just this week, put their Kubernetes cluster into general availability, and added some cool new features. So, if you're using Docker, you've gotta run it somewhere and usually just running it directly is not what you want. You wanna run it somewhere with like, where you can upgrade versions, and do zero downtime deployments, and multi-container stuff. So, Kubernetes is a great place for that. So check that out over at DigitalOcean. Just visit pythonbytes.fm/digitalocean and get $50 credit for new users. Yeah, so, all sorts of cool stuff over there. You can provision your servers, and optimize it, and get it going. All right, really, really nice. And one of the things they just added is free integrated monitoring that'll provide insight across your clusters and your containers, and stuff. So, yeah, check them out, pythonbytes.fm/digitalocean. Super, super cool. So this next thing I wanna cover, Brian, touches on something I've been a fan of for a long time, and that's design patterns. So, design patterns, we talked a little bit about that, previously. I wanted to share this, just recently, but, this time I wanna focus on maybe a topic that is reverse from a lot of the advice that you hear. A lot of times, you hear people say, "Hey, Python developers, stop using classes, and stop using objects. Just write modules and functions." right?

13:41 OKKEN: Yeah, sometimes.

13:41 KENNEDY: Yeah, sometimes. Yeah, sometimes. And that's totally reasonable. A lot of times, people come from C# or Java where everything is an object, everything has to be in a class, and so they think, well, I have to do that in Python. If you've got a static variable in a class, that's just kind of like a module level variable and a function. There's no real value to breaking that apart. However, a lot of times, there are. So there's a cool article that walks you through, and super in depth, focused on sort of data science side of this object, no object debate called Algorithms As Objects. It says usually we think of algorithms as a single function with an input and an output, and algorithm textbooks reinforce this notion, right? Like, everything fits nice onto a single page, but in reality, what you end up with are these giant, monolithic functions that are full of details with lots of cyclematic complexity, and passing lots of data around, and all sorts of stuff. And it's not nearly as nice. You end up with these functions that lack readability, and because of that, they lack maintainability. Nobody wants to touch it because it's probably important, it's an algorithm, right? And if it's wrong, it's probably hard to tell if it's wrong. So you don't want to break it. It's just kind of scary, right? So, they talk about taking these algorithms, and turning them into functions. And, one of the ideas I really like that they're starting with is like, well, should I do this or not? How do I know? So they talk about this idea of code smells. And the idea of code smells comes from Martin Fowler, way back in the day, like 1999, or something like that, when he wrote his Refactoring book. And these are aspects of code that are not necessarily broken, but they're just a little bit off. Have you heard of this idea, Brian?

15:23 OKKEN: Yeah. Definitely.

15:23 KENNEDY: It kind of makes you wrinkle up your nose. You're like, ew. Something's not good here. But, you know, the code works, right? It would pass the test, so, it's fine. So, the code smells, they say, that you should be on the look out for here are, number one, the function, the algorithm, the one giant function. It's too long, or it's too deeply nested. Like, we spoke about guarding clauses last time. Does it have banner comments, like a huge comment at the top that describes what it does, how it works, the special cases, right? I often say that code comments are deodorant for bad code. So you should just write good code and not do that. So like, that's an example. Helper functions that are maybe nested closures inside there, or some weird thing like that, or maybe actual helper functions, but they're only used within this larger function, passing a lot of states. All these things are sort of indicators that maybe an object would be much better for wrapping up your algorithm. So, it's really, I think, got a lot of concrete advice here.

16:22 OKKEN: This actually looks pretty interesting.

16:24 KENNEDY: It's super interesting, and it's full of examples. It's a really long article with lots of concrete examples of, here's an algorithm, we did it this way. We refractored that to an object, and look how much more understandable it is and how much simpler it is. If this idea resonates with you, definitely check it out. And the guy who wrote it said, "Hey, when I present this idea to my colleagues or other folks, at first they're like, no, we shouldn't be using classes. Just functions will do." He encountered some pushback, but rarely does he encounter prolonged pushback after people see the results. They're like, no, actually, this is pretty killer.

16:59 OKKEN: I'm just chuckling at one of the topics he has here is I've Got 99 Problems, Give Me Two More.

17:07 KENNEDY: Yeah, it's a good article. Definitely check it out if people are interested. It's very concrete and helpful. So, Brian, I know you're into testing, and I know you're a fan of pytest. What are you into, like really small versions of pytest, or what is this?

17:18 OKKEN: I got into this because I've been using Python for testing purposes since like 2002 or something like that. They're often custom-made Python frameworks, or testing frameworks, within our company. And then, around 2010, I did the same thing and wrote my own. But it took me a while to get it down. I was arrogant and thought, oh, this would be trivial to, because it's the basic algorithm isn't really doing much. But, Oliver Bestwalter, there was a comment somewhere on Twitter that the core pytest could be written in a couple dozen lines of code. And, people were like, what, really? And, so he, of course, he's a brilliant person. He went out and just did it. So, he released a thing called pico-pytest. It doesn't have assert rewriting, and it doesn't have fixtures or any of that fun stuff. But it's a generally usable test framework that you could run some tests with, written in 25 lines of code.

18:16 KENNEDY: Dang. And, you know, like the first five are just import statements or space, and one of them is a method. So, I think you could probably get it down to 19, if you were willing to go a little crazy on it. That's wild.

18:28 OKKEN: So, some of the things that it uses are like importlib. Some of these things are clearly put in the language for tools like pytest and stuff. Like, importlib's spec from file location, and module from spec. I don't know what those things do, but it looks like it's a way to sort of gradually load a module and then run parts of it. 'Cause that's what this code does. One of the things I like about this, one of the reasons why I'm highlighting it is a lot of people think of test frameworks as this thing. They don't really know it's a black box that does stuff. And, I think this is a good way to highlight. Python is very flexible, and the heart of a test framework isn't that complicated. It's going out and finding files that match a certain pattern, test_, and finding some functions inside those to call. And then just catching exceptions and logging your failures. It's not that complicated, so, it's pretty cool.

19:22 KENNEDY: That's super cool, and I think anybody who cares about testing, or maybe is being introduced to testing, should read those 25 lines. Not necessarily for understanding but just to get the sense of like, this is what happens when you run tests against your code. It finds your module, it loads up the functions, it calls it, it does this basic thing, and that's it. It's really nice. Very, very cool. That is definitely, I don't know what the atomic unit of a test framework is, but that's nearly it.

19:48 OKKEN: He popped this out in like two days, and, it took me like two months to write my first version of my test framework. So, awesome.

19:55 KENNEDY: Yeah, that's super cool, super cool. All right, last one I wanna cover has to do with Cython. Not CPython, but Cython. It's an article called An Introduction to Cython, the Secret Python Extension with Superpowers. And, who wouldn't want an extension with superpowers.

20:09 OKKEN: Yeah, exactly.

20:10 KENNEDY: They make the statement that they think Cython is one of the best kept secrets of Python. And I agree, like, Cython will take almost arbitrary Python code and turn it into C. That right there is pretty impressive. If you have a, like, you've got some program and you find out like, oh, this part of, I don't know, some inner loop within an inner loop, within another nested loop, or something, like that's a little bit too slow. You could probably write a function in Cython that does that inner loop, and make it way, way faster. Super cool.

20:45 OKKEN: That's what we hear a lot about Python, is you can take some slow parts, and then rewrite it in C, if you need to. But, you don't have to with Cython, right?

20:53 KENNEDY: Exactly, you don't have, that's the thing. You don't have to rewrite. You could rewrite it in C or in Rust or whatever, or you could just call Cython against it, and make it, you know, it basically transpiles the Python into C, and then compiles the C over to machine instructions. Now, depending on how you write your code, it may still interact with the Python interpreter and the Python GIL, or it might not. And that could actually significantly determine the performance benefits you get, right? So, it'll work with an untyped item, but then it does it as, I think, as a PyObject pointer. Whereas, if you tell it, this is an actual integer, it'll work with it as like a C int type of thing, or something to that effect, right? So, you get all sorts of benefits that'll, or, you know, ways to overcome shortcomings of Python, say, for example, we talked about execution speed. But there's also a keyword in Cython that says, that's called nogil. So you can just create a context block in Python, effectively. Say, with nogil: and then that stuff works without the GIL. In threads. And that's it.

21:57 OKKEN: You're just guaranteeing that that stuff isn't going outside of it or anything.

22:02 KENNEDY: Well, the requirement for using that keyword is, and if it doesn't match these requirements, it's like a compiler error, for Cython, the Cython compiler, is that you don't interact with any Python objects. So, you basically gotta cast them into Cython native objects that can be represented in C. And then there's no reason for the GIL, 'cause the GIL's point, the purpose of the GIL is to interact with the reference count and to make sure that that works in Python's object garbage collector. But if you're not working with Python objects, you don't need the GIL. So, it's a really great way to free up speed and whatnot. They talk about some of the projects written in Cython, so spaCy, the natural language processing, UVLoop, which is a really fast asyncio event loop. Significant parts of scikit-learn, NumPy, pandas, all that kind of stuff. So I think the big value, like you said, is like, you could go rewrite it in C, or you could just use Cython and make your Python run somewhat like C. Pretty cool.

23:01 OKKEN: I actually wanna play with this a little bit, 'cause, I'm glad you found this article.

23:04 KENNEDY: Yeah, the article is super interesting. One thing that I've noticed, I mean, I didn't read it, I didn't like super inspect every code example but I didn't see them using Python's type annotations.

23:14 OKKEN: Right.

23:14 KENNEDY: So, they're using like the cdef to define types, and like, special Cython ways to define types. But the more modern versions of Cython, you can just say, like, value colon int equals something. Like the standard Python way of saying what a type is, for type checking. And, that'll actually also be understood and used by Cython for native types.

23:36 OKKEN: Okay, that's the question I had was can you use native Python types.-

23:41 KENNEDY: The answer used to be no, but now the answer is yes. Yeah, so it's super cool. All right, well, if you think you need your Python code to be a little faster, check out this article, check out Cython, and it's pretty awesome. Just a good reminder, I guess. We both have a few extras. How about you kick off that section?

23:56 OKKEN: Sure, I didn't really wanna highlight this for too long, but Hynek wrote an article called The Price of the Hallway Track. It's just a reminder to everybody, and what we do here about using, going to things like PyCon and other conferences and not actually going to the talks but doing hallway stuff. He's pointing out that that's kind of lame for all the speakers that work really hard to do that. It's also, even if you intend to watch it later, it's disheartening for people to speak to an empty room or even a mostly empty room. And, he's just asking, you know, don't fill up your day with talks, but pick some, especially ones that from people that are lesser known people, and that sound interesting to hear and at least go to a few talks. I think that's good advice. I'm gonna try to do that next year.

23:56 KENNEDY: Yeah, cool, and what else?

23:56 OKKEN: The second one is Who put Python in my Windows 10 May 19 Update? by Steve Dower. We did talk about this in a previous episode, but it is officially out, and people are noticing it.

23:56 KENNEDY: Yeah, and Steve gave us a shout out to the Python Bytes episode we did together, right there in the first paragraph. So, thanks for that, Steve. This is massive. Windows 10 is shipping with Python 3, and that version of Python 3 is auto-updating. Like how cool is that? Within a major version.

23:56 OKKEN: Yeah, but it ships within a little stub, so, you don't get Python right away. You get a little thing that pops open. If you type python, it pops open in the App Store to download it. It doesn't ship with it, 'cause it doesn't need to, and, still, a lot of people like, you know, a lot of people don't need Python. But that makes it easier.

23:56 KENNEDY: I guess, when I say ships with, I mean from a user's perspective. Like if you tell a user to go through a tutorial, and you tell them to type python3, and they sit down and they type it, rather than getting error, it says, "Oh, you have to click this button for this line to work." They click the button, and then it works. Like that.

23:56 OKKEN: Yeah, exactly.

23:56 KENNEDY: I wouldn't ask for more, right. That's really cool.

23:56 OKKEN: Yeah, how about you? Got any extras?

23:56 KENNEDY: Yeah, I got a, also something super small, a Pico thing. So, Matt Trentini sent over a cool project called the TinyPICO, which is an ESP32 based board. So a tiny, little board that has first class support for MicroPython. So, Brian, if you click on that link, if you check this thing out, it's pretty wild. The project you can order, it's pretty cheap, like $26.

00:00 OKKEN: It's so small!

00:00 KENNEDY: It's incredible. It's like two-thirds the size, so 60% of a AA battery. I mean, I did it with like maybe, you know, like the middle part of your pinky or something. I mean, it's a really small board. Like both the width and the height of that is crazy. But listen to its specs: 32-bit dual-core processor, full on Wi-Fi 802.11b/g/n, Bluetooth, all sorts of stuff, like, for 26 bucks, at that size. It's so cool. So, yeah, I might give a shot at it.

00:00 OKKEN: MicroPython's pre-installed. That's cool

00:00 KENNEDY: Yeah. Isn't that super? So, people are looking at embedded stuff in little devices things. This is really, really cool.

00:00 OKKEN: Yeah. Good for years, by Nick's spy cam project.

00:00 KENNEDY: Exactly. I've got another one from Automation Panda who we met at PyCon, and this is Andy. He wrote a cool PyCon 2019 Reflections, which I thought, if you haven't been to PyCon, check out this article. It's kind of his diary of what he did and his experiences. It was like his second PyCon he ever went to. So, it was kind of a fresh take on PyCon, which is great. That's cool. Yeah, it was fun to meet him there. I just wanna give a quick shout out to our Patreon page, which we don't do that enough. So, if people wanna support the show, obviously, visiting the sponsors helps a lot, but you can help support with editing fees and other stuff by doing small contributions. So, there's a link at the bottom of this episode to say, here's the Patreon page, so people can check that out. And Brian, thanks to you for putting that together.

00:00 OKKEN: And one of the things people get is the show notes emailed directly to their inbox if they do that.

00:00 KENNEDY: That is awesome. And then, I just wanted to let people know, I'm doing a free, one hour webcast in a couple of weeks. And the title of the webcast, probably more or less sums it up, but it's 10 Tools and Techniques Python Web Developers Should Explore.

00:00 OKKEN: That looks interesting.

00:00 KENNEDY: Yeah, so it's all sorts of fun stuff. Like Docker is one of them, Vue.js is another, you know, view models and other sort of design patterns, as well. A lot of fun things that people haven't maybe seen there. Well, let's let you kick it off with our joke section. What do you got for us?

00:00 OKKEN: Oh, you're gonna give it to me? I'll steal one of your jokes.

00:00 KENNEDY: Yeah, let's do it.

00:00 OKKEN: Okay, okay. What do you call eight hobbits? A Hobbyte. Oh, that's terrible

00:00 KENNEDY: I love it. It's so bad, it's so bad it wrapped around to good. It like, badness overflowed into the good level. Whaddya call eight hobbits? Yeah, all right, so, I got another one for you. This one may also be bad. This is a little more on the science-y, math-y side. Not quite programming, but it definitely has a computational bit to it. So, you know Mandelbrot. Benoit B. Mandelbrot is his full name. The guy who came up with the Mandelbrot set, and fractals, and all that kind of stuff, right? And, one of the core principles of fractals is no matter how much you zoom into them, there's always more detail, and oftentimes, there's super weird reasons that it repeats. Like, if you zoom way into little brands of the Mandelbrot set, there's like a baby Mandelbrot set. So, the question is for Benoit B. Mandelbrot, what is his middle name? What does the B stand for?

00:00 OKKEN: Well, it stands for Benoit B. Mandelbrot.

00:00 KENNEDY: Of course it does.

00:00 OKKEN: Ah, yeah.

00:00 KENNEDY: Ah, I love it. All right, well, guess we're gonna leave it with...

00:00 OKKEN: We've gotta do the other one, it's so great.

00:00 KENNEDY: All right, go for it.

00:00 OKKEN: Okay, so, two bytes meet. The first byte asks, "Are you ill?" And the second byte replies, "No, just feeling a bit off." That went left shift.

00:00 KENNEDY: Golly.

00:00 OKKEN: on that one.

00:00 KENNEDY: Yeah, absolutely. Beautiful, all right, well... Thanks as always for being here, Brian, it's a lot of fun to talk about these

00:00 OKKEN: Thank you.

00:00 KENNEDY: and share them with everyone.

00:00 OKKEN: Yep. Bye.

00:00 KENNEDY: Yep, bye. 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 look out 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