« Return to show page
Transcript for Episode #114:
What should be in the Python standard library?
00:00 KENNEDY: Hello, and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is Episode 114, recorded January 23rd, 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. Brian, how you doing?
00:18 OKKEN: I am doing good.
00:19 KENNEDY: That's great to hear. I am, as well, and I hear often people praise Python because it is a batteries included language or technology, and I think that's really important, but it's not a subtle debate, is it?
00:34 OKKEN: No, this was interesting. We actually, there's an article we're going to link to called What Should be in the Python Standard Library? So, with the batteries included, we often think of that as well, I don't know. I used to think of it as the standard library. Now I kind of think of it as the standard library, plus some of the recommended PyPI packages, and stuff.
00:54 KENNEDY: Exactly. It's almost like an onion. You have the language, you have the standard library, and you have pip install anti-gravity wrapping around it. And I agree, when I think of batteries included, I think of it as that whole spectrum.
01:06 OKKEN: Then there's even stuff that you can't easily install even through PyPI. Things like that are in distributions like the scientific packages and stuff.
01:14 KENNEDY: Yup. Indeed.
01:15 OKKEN: We were going to talk about it last week, but I couldn't find an article that didn't say stuff like this is internal, but now I found an article on lwn.net, and I just can, I'm probably not the first one to say that this is a really ugly website.
01:30 KENNEDY: This is technically true. It could certainly use a little bootstrap action theme, or something, but it's by Jake Edge, and Jake Edge does a lot of good coverage of the core developers meeting. So, well done, Jake.
01:42 OKKEN: No, yeah, definitely great information. This will be hard to summarize, but anyway, we've got somebody, I think Jonathan Underwood proposed adding LZ4 compression to standard library because there's already some other compression.
01:58 KENNEDY: Right, you can do a ZIP file, and Tar files. Why not LZ4, or RAR, or some random other type of compression?
02:05 OKKEN: Right, so and then Brett Cannon proposed making something similar to hashlib. If there's a whole bunch of other kinds of compression algorithms, maybe we could have a compresslib, or something, that had a bunch of different algorithms in it, then can of worms opens. There's an argument against it. Basically, we don't actually, stdlib doesn't need LZ4. Maybe people do, but stdlib doesn't. It already has BZ2 there, which I'm not sure what BZ2 is. I think it's a ZIP thing, but it's kind of late to remove it since people rely on it. And then kind of a discussion ensued. Like if stdlib is the batteries included, shouldn't we have some way to add new batteries? Even things that aren't needed by standard library, but other people might need. And then there's a discussion as well of, you can't just rely on PyPI because some people don't have easy access to it, or can't install things...
03:02 KENNEDY: Right, maybe it's like REPL, some kind of online REPL, and you can type whatever they've installed, but that's it.
03:08 OKKEN: That's true. There's online REPL stuff, then there's also things like people working behind a firewall that have to have proxies to get out and use PyPI, and you have to apply for a proxy password, and stuff like that. So, there's issues, and then it gets bigger as to like, well, if we're not going to add a whole bunch of other stuff, maybe we should look at the stuff we already have, and maybe kick some of it out. Who would decide what gets kicked out? And it falls along with the discussion of well, maybe we don't really think of it as just the standard libraries, or is there a batteries included, but there's maybe we could have a standard distribution that had some set of recommended PyPI packages?
03:51 KENNEDY: Right, because the initial discussion was can we make stdlib bigger? And some of the responses were, actually, can we make it smaller? Could we have less stuff, not more? Which I thought was pretty interesting, which has led to, let's make it a lot smaller, but let's make much of what is stdlib like a standard distribution like Anaconda versus Miniconda type of thing. But with more or less, but you can choose that sort of thing, right?
04:18 OKKEN: Yup, there really isn't a solution here. It's just an interesting discussion going on, so I thought I'd bring it up. Anything that would happen would end up happening through PEPs, and the PEP process is sort of stalled right now, so we got to figure out that first.
04:33 KENNEDY: Yeah, it's interesting. I certainly see some of the drawbacks, right? One of the complaints, or one of the cautionary flags that was raised when they said, oh, can we add this? Was like, you're trying to give us more puppies. We have a kennel full of puppies and we're really busy taking care of them. You're trying to give us more of these modules that we have to care for indefinitely, right? It's almost impossible to take something out of stdlib, so maybe we shouldn't do that so much, because releasing the next version of Python means all the stdlib modules are up-to-date, got all their patches, and any additional features. It's just a bigger software project to corral, and so Steve Dower suggested maybe a smaller standard library that has a standard distribution that comes with the stuff that kind of got pushed out, or something to that effect. And maybe those comes with even more batteries like a bunch of PyPI modules curated by core developers, and I thought that's a pretty cool idea. You have a mini Python, and then you've got, oh, and it comes with requests, and it comes with, I don't know, Pandas, or whatever, you name it, right? It comes with some web framework included. I don't know, right? But it's a cool idea. And then you could update it independently.
05:43 OKKEN: One of the interesting arguments for taking things out is that there are things that are in the standard library that once you get into Python a little bit you realize that's not the right way to do it. The standard way to do certain things is to use requests, and requests isn't in there.
06:02 KENNEDY: Yeah, almost nobody uses the built-in HTTP library unless they are explicitly trying to go without dependencies.
06:09 OKKEN: Yeah, and there are people that try to do things just without dependencies, and yeah, it's an interesting thing. For instance, unit tests. One of the reasons why a lot of people recommend or say they'd rather use unit test over pytest is because unit test is in the standard library and pytest is not. And why is the unit test in the standard library? Because the standard library needs something to test itself with.
06:34 KENNEDY: Right, and that predates everything. I mean, it's very JUnit-esque, right? It's got some old school style to it, but that's the way it was. It can't come out.
06:44 OKKEN: Like for instance, if we had the standard distribution, we could possibly put unit test out and into the standard distribution.
06:51 KENNEDY: Right, and then pytest could be one of those curated modules that comes with the distribution, right?
06:56 OKKEN: And those are just a couple examples. I kind of like this idea of the standard distribution thing.
07:00 KENNEDY: I do, too. I mean, because if there's an improvement to one of the modules there, you can PIP install upgrade it, whereas you got to wait 18 months for it to come out with part of the CPython.
07:10 OKKEN: Yeah, and another thing is if we make the standard distribution smaller, it makes the process for releasing new versions of Python a little easier because there's less stuff to test.
07:21 KENNEDY: Yeah, I'm not sure if this is a good idea or not. My first impression is I see a lot of benefits to it. I can certainly see some drawbacks, right? Oh, you got the wrong distribution. Not only did you have to have Python 3.6, and not 3.5, but you also need to have the super duper...
07:34 OKKEN: Yeah that's true.
07:36 KENNEDY: But at the same time, there's a lot of benefits to it, right? The standard Python experience could get better if it came with a bunch of awesome curated PyPI packages.
07:45 OKKEN: Yeah, so I'll just leave this as everybody involved with this I'd like to have people just remember to listen to each other and not talk past each other. Talk at each other and listen.
07:55 KENNEDY: Yeah, yeah, and finally, I guess maybe just a data point, if people look at what Microsoft did with .NET. They had a huge, huge distribution and base class library, and they decided that this doesn't make sense to maintain all this stuff if we're going to have a cross platform .NET, which they created. So, they made a lot of the .NET standard library, base class library basically pip installable, right? Like you get this core thing and then you install the little other bits. So, it's not that different than what Steve is proposing.
08:24 OKKEN: How is that received by the .NET community?
08:26 KENNEDY: I think it's mixed, honestly. It makes life a little bit more hard, right? 'Cause you can't just use the stuff. You're like, oh, you got to have these dependencies and install it, but it did make it possible for them to have a Linux and MacOS version that they can now use, when before it was stuck in Windows. So, they were like, this part only belongs in Windows. It can't go somewhere else. So, now it's going to be part of this external thing that you can only get by installing that dependency on Windows. So, I don't know, there's some benefits, but there are also, you know. Packaging is already challenging in Python, so I'm not sure I want to poke the bear.
08:55 OKKEN: Yeah, okay.
08:56 KENNEDY: But it's pretty cool. Speaking of pretty cool, something I've wanted to install, but I don't have enough devices to justify is this thing called Home Assistant. Do you know this?
09:06 OKKEN: Well, we've talked about it a couple times, but I haven't tried it yet.
09:09 KENNEDY: Yeah, neither have I because I think I might have one smart light bulb I bought on accident. Technically, I have a Nest. My car is electric, so it has a charger, but the charger doesn't integrate with Home Assistant, so that doesn't help me. So, I would really love to have it, but I just don't have enough. My home is too old school and too analog for it. Anyway, Home Assistant is this cool web server that integrates all your smart home appliances and things, and collects data about them. Can run as a web server on a Raspberry Pi, and you just leave that in your house, and it does Magic, which is cool.
09:42 OKKEN: They're very cool.
09:43 KENNEDY: So, Paul Cutler, one of our listeners, let us know that they have now launched a data science portal to process and work with your data that comes from your home backed by Home Assistant. That's pretty cool, right?
09:54 OKKEN: Oh yeah. Nice. You could have like temperature sensors, and stuff.
09:56 KENNEDY: Yeah, exactly, and it's already collecting all that data on just because what Home Assistant is, but now they've set up a special way to work with it. So, they said, look, one of the core ideas of Home Assistant is all of your data lives on your Raspberry Pi and an SD card, not somewhere else. So, they set up this Home Assistant data science website to help you work with that data and analyze it, and then they went so far to create a new add on for their IO that runs, their OS that runs Home Assistant called JupyterLab Lite. It just runs JupyterLab right on your Raspberry Pi hosting Home Assistant. So, on the same thing that is your Home Assistant, now you have a JupyterLab running there to analyze your data in place.
10:37 OKKEN: Yeah, cool.
10:38 KENNEDY: Yeah, and they also created a Python library called the Hass. That's their operating system, Data Detective, that's based on things like Pandas that lets you start get going quick. So, anyway, it's pretty cool.
10:49 OKKEN: Yeah. Very nice.
10:50 KENNEDY: So, people have a smart home and they want to do some data science-y stuff about it, or maybe even build a product for other people so that they have more data control over their home. Yeah, so that's pretty cool. And then finally, I think I finally decided my first IoT project. We'll see if I can actually make it happen, but I've always wanted to build an IoT thing, and I'm always like, but I don't really have any use for one, but I think I have a use for one now.
11:13 OKKEN: Oh, tell me about it.
11:14 KENNEDY: Yeah, so you might sympathize with this. I know a lot of people who do things like we do would. So, I have a separate office above my garage where I can record quietly away from the kids, but especially in the summer, kids are home, they come over, they want to talk to me or my wife. It's like, hey, I got to ask you something, and I might be in the middle of recording a course, or talking to you, recording a podcast. So, I'm going to get a big, fat button and I can press the button, recording, not recording, and then down by the door before people even get to here it's going to say recording, not recording.
11:45 OKKEN: Oh, that would be cool.
11:46 KENNEDY: Wouldn't that be fun? It's super easy.
11:48 OKKEN: Yeah, I wonder if you could hook it up to the Skype connection status.
11:50 KENNEDY: Oh, yeah. Maybe so. Do you have Camtasia running? Are you on a Skype call? Yeah, oh, if it could be automatic, that would be sweet. Yeah, why not, right? Zoom, couple of those things. Yeah, alright. There we go. It just went open. Pretty cool.
12:05 OKKEN: It started easy, now it's hard.
12:07 KENNEDY: Now all of a sudden I have a machine learning problem . No, just kidding. A bunch of APIs I've got to learn. That's cool. Alright, speaking of machine learning and the future, what do you got next?
12:16 OKKEN: Kevin Markham, over at dataschool.io, I don't know if we've talked about him before, but dataschool.io is pretty cool. It's just he's got a lot of cool resources. But he wrote an article called What is the Future of the Pandas Library? And I didn't realize Pandas is one of those zero ver projects, which is odd, considering everybody uses it. But they're considering going to a 1.0 release early this year, and there's an article describing some of the stuff that is coming new and coming with some of the new versions of Pandas. One of the things is we already know method chaining is becoming more popular with functional programming, and people are used to that. You can already do that with a lot of stuff in Pandas. What's new really, is just that they're going to try to take that further in and make more methods that support chaining. All you have to do to support chaining is to return the object that you're operating on as a return for a function call, so that you can chain a bunch of function calls.
13:15 KENNEDY: And a lot of times, they probably return nothing, so they might as well just return the thing again so you can have this fluent API, which would be nice, right?
13:22 OKKEN: Yeah, there's also people in the know might know what Apache Arrow is. I really don't know what Apache Arrow is, but apparently, it's something that can help the back end of Pandas become a little bit more efficient. And so, they're going to try to push that out. It'll probably be after 1.0, 'cause it doesn't change the interface at all.
13:39 KENNEDY: Yeah, it's cool. I don't know much about Apache Arrow, but it sounds cool. They talk about things like working with data that's larger than what you can fit into memory, and things like that. So, instead of loading everything just into kind of data frame, or something, it's like it'll stream the data off disc, and all sorts of stuff. It's pretty cool.
13:56 OKKEN: Yup, and I know a lot of people listening to this use Pandas every day. I'm starting to use it more. So, the rest of my spiel will be stuff that I don't really know about, but you might. One of the things is apparently, it's hard to do custom data types because of some of the limitations. So you could kind of have to jump through hoops, but there is going to be extension arrays that make it easier to create custom data types for using with Pandas, which that sounds neat. And then some things that are going away, so some deprecations that have been proposed, in place parameter. It doesn't really work as it's supposed to, and it mucks up chaining, so they're going to try to deprecate that. The IX assessor, which is going away, or it's deprecating, use loc or iloc instead. The panel data structure, apparently, you should use multi-index instead. And the sparse DataFrame never really worked as it was supposed to, so they're going to just support DataFrame. And last, but not least, in the 1.0 release, they won't support for 2.7.
14:57 KENNEDY: Hoo-hoo! Viva modern Python, right? That's right. Moving on, so no more legacy Python. Super. Okay. I think these things are all great. I don't use Pandas enough to really say a whole lot, but I do think they talk, Kevin talks a little bit about the zero ver impression of it not being ready, and so on. And it feels like these deprecations are kind of like, alright, these are a few of the rough edges of the API that we wish we could get rid of, and we're going to call it 1.0, and we're going to drop the few things that we don't really like, including Python 2. Pretty sweet. Alright, also sweet is DigitalOcean. So, if you want to do anything with containers, you got to orchestrate them. You got to get them to talk together, so check out Kubernetes. DigitalOcean just launched their public Kubernetes, service DOK8. Super simple managed Kubernetes service so you can deploy faster, configure your Kubernetes cluster in seconds, and provision and access your cluster in a few minutes. You can scale reliably based on incoming traffic, and everything's stored in block storage and behind load balancers, stuff like that, and people are seeing a 2.4 times better price to performance ratio compared to other providers. So, if you want to do all that cool stuff or more with a free $100 credit for new users, check them out at pythonbytes.fm/digitalocean. Now, I'd love to talk about something that we haven't. I don't think we've touched on it very much, but maybe packaging up Python apps. Have we talked about that?
16:24 OKKEN: Yes, we have.
16:25 KENNEDY: Oh, I do remember that now. That three week stint.
16:27 OKKEN: More.
16:28 KENNEDY: We will more. This one is, at least it promises to be pretty excellent. So, let us count the ways. There's more than this. We have PEX, which is a way to make a ZIP file of Python code executable with its dependencies. We have PyInstaller, which will take a Python environment plus its dependencies, and turn it into kind of an embedded Python interpreter plus like a ZIP file, or something to that effect, of its dependencies and its source files, and then run that as an exe, or a .app. There's py2app, there's cx_Freeze, there's many of these, right?
17:06 OKKEN: Yes.
17:07 KENNEDY: The new kid on the block is PyOxidizer. So, when you take the Py element and you combine it with iron and oxygen through the Rust compiler you get the PyOxidizer outcome. No, so PyOxidizer is a set of Rust crates. Libraries, I'm guessing, way to put it that facilitate building libraries and binaries containing Python interpreters.
17:30 OKKEN: Okay, interesting.
17:31 KENNEDY: So, cx_Freeze, Pyinstaller. You're like, okay, great. Well, somebody loves Rust, and they're just doing it again, but this time with Rust, because it's amazing. But this one has some special capabilities that maybe are better. So, it makes a single executable file in exe, or .app, or something, and all the dependencies and all the resources like PYC files are embedded inside the executable. So, with Pyinstaller, you get an exe, and then a bunch of loose files, and ZIP files, and directories, and somehow all that stuff gets put back together to run. Here, you get a single exe, or executable, that takes those and puts them inside the binary as a resource, and then runs it.
18:10 OKKEN: That's cool.
18:11 KENNEDY: That's cool, right? So, this is of course, the oxidizer part comes from Rust, and these are compiled from Rust, and basically, the Rust, it becomes like a Rust executable, right? And the Rust executable code is responsible for managing and running the embedded Python interpreter in all of its operations. So, it's totally self-contained.
18:32 OKKEN: Yeah. Okay. Yeah, that's kind of cool.
18:33 KENNEDY: It's pretty cool, right? So, instead of all these others that I mentioned, except for the produced executables contain embedded, statically linked Python interpretors, so no dependencies. They have very little run time dependencies on the OS it runs on, and everything is run from memory rather than extracting temporary Python files to a directory and trying to run them from there with weird paths, and stuff. So, I'm pretty excited about this. I haven't got a chance to try it, but I want to.
18:58 OKKEN: Yeah, me too.
18:58 KENNEDY: Yeah, it looks really promising. It looks like this is the way it probably should be, so I'm pretty excited if it works the way they're promising. And you have to work with no files on the operating system. You get one file, so it's simple, but not all file systems are simple, right?
19:11 OKKEN: Right. Actually, I love it when I can program, work on a project where I don't have to deal with the file system at all because sometimes it's just kind of a pain. But everybody, anybody that's using tools can go, hey, I can automate, I want to automate some part of my job, and often, that involves dealing with the file system. And Real Python just recently put out an article called Working with Files in Python, and at first, I'm like, oh cool, another file system thing, but it's a pretty nice article. It's a very comprehensive write up, and they cover both legacy ways like the os and sys versions to do some of these things that I'll cover in just a second, but they also use pathlib. I'm trying to use pathlib more and more, but pathlib is for more recent versions of Python, and you might not be there. However, it might be that you're used to doing, you've done file system stuff in the past, and you want to try pathlib also, so having the examples right next to each other is kind of nice, to be able to say, hey, I used to do this in OS, and now I'm going to use the pathlib version here. So, that's cool.
20:19 KENNEDY: Yeah, yeah, quite cool.
20:20 OKKEN: I'm not going to read the article, but a lot of the stuff that you might have to do is get a directory listing, what alls in a directory, looking at file attributes, creating directories, doing pattern matching on file names, traversing directories and doing stuff with the files that are there, creating temporary directories and files, deleting, copying, removing, renaming. They include in this article how to deal with zip and tar files, including reading the contents of those. So, there's quite a bit of stuff here.
20:48 KENNEDY: Yeah, it's a really nice and standard, comprehensive Real Python article, so well done on that. One of the things that I like about this is it doesn't go, here's a way to read ZIP files. Here is a way to create directories. It goes, here are the ways, all the ways in the standard library to do this, and when you would choose this over that, and why that's better, and so on. So, for example, like with path, from pathlib, you can say, I want to create the directories, but normally, there'd be an exception if it already exists, so you could say, it's okay if it exists. I just need it to be there. This is an idempotent type of thing I'm trying to do. Stuff like that, right? Or if I want to create multiple directories in a chain, how do I create the intermediate ones without loops and other annoying checks? So yeah, pretty nice.
21:34 OKKEN: Yeah, it's good to have all that stuff in one place, too.
21:37 KENNEDY: Yeah, it's definitely a good reference thing, right? If you've got to do all the things listed here at once, I don't know what you're doing. You've got something going on that's a little crazy. I got to ZIP, and tar stuff, and create directories, and get the file attributes, right? But it's certainly good to have as a reference for when you got to one of them.
21:56 OKKEN: Yeah, but usually you have to do two of these things. You might have to create multiple directories, and then read the file in there, or something.
22:04 KENNEDY: Yeah, for sure. Alright, so this last one that I picked for us, Brian, this is a little bit motivated by a conversation we had before, right? We had talked about having Python, the command you type on a terminal or a command prompt, being converted from meaning Python 2 to meaning Python 3 as part of this whole transition, right?
22:22 OKKEN: Yes.
22:23 KENNEDY: I think what Red Hat was doing was basically saying, there shall be no Python. You have to type python2 or type python3 on the new Red Hat enterprise Linux. And there was some debate about that, so David Furphy in a really cool thread from PEP 394, and it says look, this thing that you sensibly suggested, or at least debated on the show recently, it's been tried and it didn't go super well. So, Homebrew tried it. Homebrew said, you know what? Python equals python3, yes, and there was a bunch of knock on effects, and they said, we're really sorry. We kind of broke some stuff. We'll put it back. So, Homebrew tried it and they had to actually roll it back, and there's a link to that conversation. Also, on the PEP 394, there's some interesting conversation over on GitHub around it. So, this PEP 394 is allow the Python command not to be installed, basically, and other minor changes. So, basically requiring you to type python2 or to type python3. So, there's no way to just type python, which to me, doesn't feel like a great fix. We want to move to the next version of Python, so when Python 4 comes out it's going to be like, well, everyone's using python3 in their tutorials, and they keep breaking. It doesn't seem very scalable, but nonetheless, that's what the thing says. So, I want to read you a couple of thoughts that Guido van Rossum had about this. So, somebody said, Python doesn't exist as a command on MacOS, so it's solved. He's like, no, no, no. python2 doesn't exist as a built-in command, but python definitely does. So, however, I'm still unhappy with, basically people are saying if you type python and that means python2, what that is saying is the core developers prefer Python 2 over Python 3. 'Cause if you typed a simplest statement to run Python, it does old Python, not new Python, okay? So, there's an endorsement to say, let's not encourage Python 2, legacy Python. Let's have python point to Python 3, as we've been saying, right? So, Guido said, I'm still unhappy with any kind of endorsement of python pointing to Python 3. When the user gets bitten by this, they're going to be really unhappy. Regardless of what MacOS does, I think I would be happier in the future if python as a command does not exist and you have to say python2 or python3. So, anyway, that's just a bit of a follow up to this python equals python3 discussion we had.
22:23 OKKEN: Hmm. Yeah.
22:23 KENNEDY: Yeah, I'm not super happy with it 'cause I feel like, well, what happens when the next version of Python comes out? Then it just gets complicated in the same way, but still, it's okay.
22:23 OKKEN: I think that's our children's problem.
22:23 KENNEDY: That's right. It's like global warming. That's someone else's problem. We're just going to kick that down the road. Let them deal with what happens when you type python and it goes to Python 3, not 4.
22:23 OKKEN: Well, and how many other tools have like, which grep do you want? Do you want grep 2, or grep, I mean...
22:23 KENNEDY: Exactly. You want to run Homebrew? There's seven choices. Which version of Homebrew you've installed do you want to run? No, I just want to run Homebrew. Preferably, the latest. Anyway, yeah.
22:23 OKKEN: Anyway.
22:23 KENNEDY: I guess that summarizes our thoughts, doesn't it? Cool, well I do have one quick extra thing. You got any?
22:23 OKKEN: No, not right now.
22:23 KENNEDY: So, I'll just throw this thing out here because it wouldn't be a show if we didn't mention Anthony Shaw somehow, right?
22:23 OKKEN: Yeah, he's a good friend of the show.
22:23 KENNEDY: That's right. So, he wrote a letter to the Python community in Africa, which is a pretty interesting summation of the state of the Python community throughout the different regions of Africa, and really highlighting a lot of cool stuff that's happening over there.
22:23 OKKEN: That's cool.
22:23 KENNEDY: Yeah, so it says, look, if you look at what they're doing, there's actually a lot of stuff that the broader Python community can learn from what people are doing there. And I'll let you all read the article. It's really long, and it's just, this is an extra, right? Not a deep analysis, or whatever, but just to give you a sense, the attendance, in terms of gender of PyCon NA was 50% male and 50% female. Think of other tech conferences where that's the case.
22:23 OKKEN: Yeah, I've never been to one.
22:23 KENNEDY: Neither have I, neither have I. It wouldn't be terrible, would it? That looks like the population. Hey, wouldn't it be cool if you were a tech community that looked like the population in general? Anyway, he covers a bunch of stuff like that, and there's a lot of interesting things going on, so I thought I'd give him a shout out there. I know we've laughed a lot on this show, Brian, but I don't think we're done.
22:23 OKKEN: No, we're not. This is the one I was waitin' for, actually. No, it was all good content, but it was good. So, we have our joke.
22:23 KENNEDY: Are you tellin' it or am I tellin' it?
22:23 OKKEN: You can tell it.
22:23 KENNEDY: Okay, so this comes to us from Luke Russell who sent in a joke, which is great because it helps us to have jokes if people send them to us. Alright, so this is a knock, knock joke. You ready? Knock, knock.
22:23 OKKEN: Who's there?
22:23 KENNEDY: Java. Takes a while to get started. Hold on. We're good now. We're running.
22:23 OKKEN: I love that. I told this a couple times at work, and instead of the pause, I counted on my fingers.
22:23 KENNEDY: Well, as long as they can't see you, it's fine. So, actually this brought back memories of a really funny, doesn't directly involve Python, but it involves Open Source. And if it were made at a later date, it probably would be involving Python, but instead, it involves Java video, which is really funny. Called Java Forever.
22:23 OKKEN: This is an amazing video, so people, watch this. It's high production value. I hadn't seen this before, and it's really, really hilarious.
22:23 KENNEDY: Yeah, so there's this family. They love .NET, Microsoft, and they will never stray from them. Like very authoritative father, but there's a rebellious 18 year old who loves Open Source and Java, and all sorts of crazy mayhem ensues. We can't do it justice here, so I'll just link to the YouTube. It's pretty funny. Check it out. Alright, well thanks for the joke, Brian.
22:23 OKKEN: Thank you.
22:23 KENNEDY: Yeah, catch you later.
22:23 OKKEN: Bye.
22:23 KENNEDY: 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.