Transcript #117: Is this the end of Python virtual environments?

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to

00:04 your earbuds. This is episode 117, recorded February 12th, 2019. I'm Michael Kennedy.

00:11 And I'm Brian Okken.

00:12 Hey, Brian. How you doing?

00:13 I'm great.

00:13 Excellent. Great to hear. Great to hear. You haven't been flooded out in this torrential

00:18 rain that we're having around here?

00:19 Nope. And I survived snowpocalypse.

00:21 Yes. So did I. My rain jacket got me through.

00:24 Yeah.

00:25 Wouldn't do that. This episode is brought to you by Datadog. Check them out at

00:29 pythonbytes.fm/Datadog. All sorts of cool monitoring stuff. Tell you about more later.

00:35 Brian, the first thing you have queued up here is super exciting to me. Hit me.

00:39 Okay. Well, in 117 episodes, this is the first time we collided and both picked the same article.

00:46 Because it's good, because it matters.

00:48 Okay. So here is Goodbye Virtual Environments.

00:52 What?

00:52 Well, I don't know about that.

00:56 Is this just like pseudo pip install into like root?

00:59 Is this what they're just like, forget it. It's too much. We're out of here.

01:01 Well, so we have a lot of solutions to this.

01:05 So this is an article by Chad Smith.

01:07 And apparently this is referencing pep582, which is a local packages directory PEP improvement.

01:16 Okay. So here's the premise.

01:18 Virtual environments are awesome, but they have some problems.

01:22 They, the learning curve bit. So when you're trying to teach people how to use Python, you want them to have a safe environment. So you start them off with virtual environments and you have to like teach them about all this gunk and they don't even see any code yet.

01:37 So there's that problem.

01:38 Right. And if you close like your terminal, yeah, it'll come back. And you're like, oh man, I forgot to reactivate it. Like, why won't this run? I mean, you know, once you get into it, it's fine. But like, as a new person, you're like, why did this work before? And now it doesn't? Super frustrating. Right?

01:52 So that the proposal is if you have a directory sitting around in your local, say called Dunder pypackages. So it's two underscores on each end pypackages as a directory. It's just sitting there. It doesn't have to have anything in it.

02:07 The idea is if you pip install while you're there, it, instead of installing it in the site packages or anywhere else, it'll just install it in this local package directory. And you don't even really have to care what it looks like in there, but it's there.

02:22 And then, so there's a couple changes. It's got a pip has to change, but also Python has to change because Python has to include looking for a pypackages directory locally to see if something's there.

02:35 Some of the neat things about this is that it's not where you're calling it from. It's not your current directory when you're calling a module or something.

02:44 So let's say somebody is just somebody that's writing a Python script and it has some dependencies.

02:49 They could have a pypackages directory right next to their script. And then as long as their script is in their search path, Python will pick, run that. And then, then if that module has some imports, it'll try the local packages first. So that's kind of cool. I think that's it.

03:06 Yeah, I think this is fantastic. And if I could take all my votes for what I'd like to see added to Python, certainly more than one would go towards this. So I think this is great.

03:17 It's basically like what Node does with Node modules and other things. There's a convention that if there's this folder in the root of your project and you run code, it will try to use the modules or packages in our case from that location.

03:31 There's no more activating. There's no more deactivating. None of that. You pip install. If it sees dunder pypackages, it installs it there. You Python run. And if it sees pypackages next to your file or in the working directory, it uses that from there as if it were a virtual environment.

03:49 You don't have to keep activating it and deactivate it and make sure it's the right one. And it already follows a convention that so many people already do. Either create a VENV or .ENV folder at the root of your project. So many people do that. Editors like PyCharm and VS Code automatically detect and activate them. But this would just solve that problem. Flat. I love it.

04:11 Well, solves most of the problem.

04:13 I love it. What will problems then solve? Where do you see the challenges remain?

04:17 So this article also, it's kind of cool that it has like this little trial thing. You can install a Python loc package to try it out. So I tried it out. And one of the things that's missing is your entry points. So like, let's say I'm installing a command line, some utility that has a command line interface. Where do those go? They actually go in this pypackages directory also, but they're not obvious where they are.

04:46 It's not difficult to find them. There's a bin directory in there. In order to be able to use them, you'd still have to modify your environment, like your bash environment or something.

04:54 I see. So like, for example, Pyramid has a p-serve web server that comes when you install it, and it's just in the Python path.

05:03 Yeah.

05:03 So you'd have to do some kind of mechanism to make that be active.

05:08 Yeah. Or like pytest or Talks or so many things have little extra things that go with them.

05:13 Yeah. I mean, I guess you could usually do Python dash M of that thing, but that's pretty clumsy compared to like just typing pytest.

05:19 Yeah.

05:20 Okay. Yeah. Gotcha.

05:21 I'm all for this. I want it to happen, but I don't think virtual environments are going to go away unless we have, maybe they'll just be, you can have some extra thing in your path or something in your bash environment or whatever that says, hey, also look here.

05:37 Yeah. Well, what I would like to see, I mean, maybe like this Dunder PyPackages is a virtual environment that you just don't have to activate, but you could, if you want to run these types of utilities that you're talking about.

05:49 Yeah. Okay.

05:51 That would be a pretty good compromise, I think.

05:52 Anyway, good thing. Doesn't solve everything.

05:54 But I think it's a super step forward because it doesn't impose some opinionated behavior and workflow and other tooling to replace.

06:04 It's like, it just now works. I run Python. It works using the packages that I meant for it to use. I run pip. It installs them into the proper place generally that I meant them to do and so on. So I like it.

06:17 And the getting new people up to speed on stuff quicker, getting, being able to isolate installs application development. There's so many benefits here that it, yeah, it's great.

06:28 Yeah. Love it. So yeah, definitely vote for that over some of the other options. Super cool. So Brian, I got some bad news today.

06:34 You do?

06:35 Well, you know, my life's pretty good given that I'm calling this bad news, but I learned about this thing called Google Lighthouse. Have you heard of this? I'd never heard of this.

06:44 No.

06:44 So Google Lighthouse is a thing that will analyze your websites basically for how well they're going to rank it based on a whole bunch of factors.

06:54 And people have heard of SEO. So you've got like, of course, you should have your title on your head and your H1s and all this stuff that you need.

07:01 But this is more about the behavior of your web application. So is it responsive? Are your images, do they fit on like phone screens? Does it return data at the right amount of time? Are you serving like old style images that are too large and you could reencode them in small, like a huge bunch of these types of things?

07:20 Are you bundling and minifying your CSS and JavaScript? So I sent my site through there, which I consider to be blazing fast, because if you go to like talkpython.fm or some of the other ones or pythonbytes.fm, although I've been cranking on talkpython first before I break Python bytes.

07:34 If you go to the homepage, it renders like out to the network in 15 milliseconds. And I'm like, well, that's pretty much as good as it's going to get, right?

07:43 Maybe I could shave two milliseconds off it, but who cares, right? It's so fast.

07:48 But when you look at all the CSS and all the JavaScript and the way it renders and the images and everything, it turns out that that's, that could be better.

07:56 And I knew that it could be better, but I didn't realize how much Google was sort of punishing my site for it.

08:01 So I went looking and I found this cool Python project called Web Assets.

08:06 I'd never heard of it. Yeah. And I found it on Python, awesome Python.

08:09 So I went there and said, well, what can I find for like minifying JavaScript and bundling CSS, like five CSS files into one and whatnot.

08:18 So this is a Python package you install. You basically created an environment that registers your settings.

08:25 Like here's the static folders. If you're going to generate files, like if you're going to take five CSS files, minifying them and like mush them into one giant file that can be gzipped.

08:34 Right. If you do that, where do you save it? All those kinds of things.

08:38 What transformations you want to apply to it, like bundling and minification or whatever you configure that you give it a list of files.

08:45 And then it will just bust out like a new one onto disk. And you can just start serving that instead of all like you just take away the five CSS links and you put in the one.

08:53 Okay.

08:53 It also has built in Flask, Django and Pyramid support. So it integrates in there.

08:58 But to me, it looks like like a whole bunch of stuff that's getting in the way of your web app working.

09:02 Whereas like you can just ask it to save a file that gets served out of Nginx and doesn't touch your Python code.

09:08 That seems nicer. So that's what I'm doing. I don't want to integrate it into my app.

09:13 But if you wanted to go that path, you certainly could. It's a really cool little thing.

09:16 Oh, neat. So talk Python is faster now.

09:18 It is much faster. It now has a like a best score or whatever on Google's lighthouse, basically.

09:25 Which will help it rank higher in Google search results, which is also pretty awesome.

09:31 Yeah.

09:31 So yeah, there's a bunch of cool. And so anybody doing anything with the web, they should look at their website in Google Lighthouse, which I have a link to.

09:38 And then one way to address some portion of that around your static files anyway, has to do with web assets.

09:45 So that's a pretty cool thing.

09:47 Awesome.

09:47 Yeah. And it's all Python goodness.

09:49 Yeah.

09:49 And the next item, have we spoken about packaging? I think we might have touched on it once.

09:53 Yes.

09:54 This week? Have we spoken about it this week?

09:56 No, yeah. Let's do it. Sort of. We kind of have in a sense, but let's go. What's next?

10:01 Okay. So we've got actually a three-part series of articles by, I think his name is Bernat Gabor.

10:08 And he is one of the maintainers for talks and virtual environment and a bunch of other stuff.

10:13 He's with the Python Packaging Authority, and he's right in the thick of all of this changes in packaging and everything.

10:21 He wrote kind of a three-part series.

10:24 The first part is the state of Python packaging, which is just kind of a nice overview of what are we trying to do and what is the issue and all that stuff.

10:33 We've got a bunch of like a directory full of a source directory, and you want to share it with other people.

10:40 And how does that all happen?

10:42 And how did it happen in the past using setup tools and all that?

10:46 And where are we at now?

10:48 And then some of the problems, he talked about some of the problems with, I guess it's kind of hard to hand wave this, but it isn't just source files that you just copy from one computer to another.

10:58 Sometimes there's C parts to it that need compiled for different machines.

11:02 Even Fortran in the data science world, you've got to compile like crazy stuff, right?

11:06 Yeah, and so there's that part of it, and that's included in all of this packaging mess.

11:12 And then on the other side, when you're trying to install it, if you just grab the source distribution, then you have to compile it on your side, but you have to make sure that all the compilers are available and all that stuff.

11:23 And it's kind of a mystery black box with a lot of scary guts inside because it's a scary problem.

11:30 It's a hard problem.

11:31 Now, moving towards things like wheels are pre-compiled, so you build everything before you push it up, and then clients just can just sort of download it and unpack it.

11:41 But in order for this all to work right, there's a lot of moving parts, and it's all being done by people in there volunteering their time.

11:49 And that's why I love this set of articles.

11:52 It's from the inside, talking about some of the hard problems, why they did what they did, some of the breaks that happened, and why they happened, and moving forward.

12:02 And I want to read one article.

12:05 It's actually the conclusion, one bit of it.

12:07 It's the conclusion to the third article.

12:09 It says, Packaging is hard.

12:12 Improving a packaging system without any breakage where users can write and run arbitrary code during the packaging in your free time is probably impossible.

12:20 Yeah, that sounds about right.

12:22 Yeah.

12:23 They said, granted, as we go through this change, some packages might break, and we might disallow some practices that worked up until now.

12:31 But we, the packaging authority maintainers, do not do it in bad faith.

12:36 So when errors do pop up, please do fill in a detailed error report with what went wrong, how you tried to use it, and what is your use case.

12:45 And I guess I have to speak from experience.

12:47 It's when we just, when I started trying to, even when the, some of the same involved people were, were working on some of the transition to the new pip server, IPI.

13:00 It's a similar sort of situation, I think, is when, when we change the way we do things.

13:05 Some people get upset and just expect it to all just work for free.

13:09 But please keep your head and read this article.

13:12 It's a great series of articles on where we are.

13:14 And I'm, it's going to be hard.

13:16 Yeah.

13:17 I'm not even going to try to summarize it, but it's good.

13:19 Yeah.

13:19 It sounds like a great write-up.

13:21 Did, you know, if they, he mentioned the PEP, the one you just mentioned there, what was it, 582?

13:27 No, they didn't, he didn't reference that.

13:29 But there's, of course, reference to 517 and 518 that dealt with the pyproject.toml and stuff like that.

13:37 Yeah.

13:37 Cool.

13:38 All right.

13:39 Well, you know what all this means to me, the way I perceive it is, like, people are trying to solve this problem.

13:44 They know it is a problem.

13:45 And I think if we get it dealt with as a community, I think it'll be a massive, massive benefit.

13:51 I mean, I was just talking to someone the other day at a conference here in town, and he was like, oh, well, Go is so awesome.

13:57 I'm like, okay, tell me why Go, like, sell me on it.

14:00 Why is Go so awesome?

14:01 He's like, I press a button, I compile it, I get a single binary I can give to anyone, and they can run it as long as they're on that platform.

14:06 I'm like, yeah, that's a benefit.

14:08 That would be nice, wouldn't it, if there was a, like, Python space build option.

14:13 So, very, very cool.

14:14 But there's a lot of stuff coming and a lot of work being done on it.

14:17 Like, we talked about PyOxidizer recently as well.

14:20 Yeah.

14:21 Quite cool.

14:21 Yeah.

14:22 One more thing before we move on, one of the things he brought up is Flit.

14:26 Flit uses the new Toml style.

14:29 The implementation of Flit is built on top of distutils and all that stuff also.

14:35 And that's one of the things moving forward is some of these newer packaging tools.

14:40 If Python embraces some of the stuff and some of the changes, we'll be able to kind of simplify the maintenance of a lot of these extra things.

14:50 Right, because they do a lot of work to piece it together and paper over the challenges, right?

14:54 And if the underlying bits changed, it got easier, well, maybe it just, they just, you know, use the easier foundation, right?

15:01 Yep.

15:02 Nice.

15:02 All right.

15:03 Let me tell you about Datadog before we get to the next one.

15:05 So Datadog has been a longtime sponsor of the show.

15:08 Super thanks.

15:09 Big thanks to them.

15:10 And they're a cloud monitoring platform built by engineers for engineers.

15:15 They're tracing client auto instruments, popular frameworks like Django, Flask, Tornado, and so on.

15:21 So you can quickly visualize the flow of data across your application architecture, not just how's my Django app doing, but how is all my infrastructure and moving parts doing?

15:30 They also integrate with over 250 technologies like Hadoop and Redis, allowing you to pivot seamlessly between distributed request traces, metrics, and logs.

15:38 So check them out and get a free trial as well as a cool Datadog t-shirt over at pythonbytes.fm.

15:44 Datadog really helps support the show.

15:46 Cool.

15:46 Yeah.

15:46 Brian, I picked this one to be custom picked for you.

15:50 Like you should, this was the one you could have chosen, but I got it today.

15:53 I beat you to it.

15:53 Okay.

15:54 All right.

15:54 So this one is a cheat sheet for mocking in Python.

15:58 So mocking, not the insult, but the ability to change the behavior of some deep internal parts of your application without rewriting them.

16:08 Super powerful testing feature, right?

16:11 If I want to test how my data access layer works, but I don't want it to actually touch the database, or I want to test how my credit card system works, but I don't really want it to talk to the, to Stripe or whatever.

16:21 I can mock out different parts of that and basically inject behavior into my app, right?

16:29 Yes.

16:29 Yep.

16:30 So mocks are built into Python, right?

16:32 That's great.

16:33 You can just import mock and start doing stuff with it.

16:36 However, there's a lot of different ways in which you can do that.

16:40 And there's also a lot of features.

16:43 You could use mocks the way I describe them there, which I think is sort of making your test decoupled from your dependencies.

16:50 But you can also say, I would like to kind of look inside the behavior and make sure certain parts of my app are using functions that I want.

16:57 Like, for example, I could say, I'm going to call the login function or the access, let's say, admin part of my app.

17:05 And I'm going to make sure that it's checking is admin on the user, right?

17:09 Like, if it doesn't, if it talks to the admin section and it doesn't say, you know, test whether or not I have the permissions, something's badly wrong.

17:16 So you can even verify that things were called with like in a start called once and so on.

17:20 So this is a nice write-up that takes you through all the different things you can do with mock and like quickly gives you examples for those various things.

17:28 Like how to use a mock as a decorator, how to use it as a context manager and on and on and on.

17:34 Great.

17:34 Yeah.

17:34 Nice.

17:35 Yeah.

17:36 So all those folks out there who are testing or want to start testing, or even if you don't test because testing is too hard, you're like, well, all this stuff happens when I call this function.

17:45 How am I supposed to test it?

17:46 Mock.

17:47 Here you go.

17:48 Yeah.

17:49 One of the things that's nice about having it not just completely tied with testing, although that's definitely where it's used a lot, is we can, like some applications that have like a, I don't know, a debug mode or some other mode that they're operating in.

18:04 You can even build it into your application to, you know, flip a bit or something and it turns some of the system off.

18:11 So, and you can use mock for that if you don't want to build it other ways.

18:16 Yeah, I guess you could, right?

18:17 You could just, you could fire off the mock if you want the logging to do nothing, right?

18:21 I'm going to create a mock that replaces this file behavior or whatever, right?

18:25 Yeah, or if you wanted to like switch out for diagnosing software issues or debugging, you can switch out your database interface with some other database entry or something or whatever.

18:37 Yeah.

18:38 But I don't know if very many people do use it for that, but you could definitely.

18:41 Yeah.

18:42 Yeah.

18:42 Very cool.

18:43 All right.

18:43 Yeah.

18:43 Mocking is super powerful.

18:44 What do you got next?

18:46 I have just an article about conference speaking.

18:49 So, Saron, and I'm not going to try to pronounce her last name.

18:53 Do you know how to pronounce it?

18:54 Yit Barak.

18:55 Sure.

18:55 I'm going to go with Yit Barak.

18:56 Okay.

18:57 I know her from the Coder Newbie or Code Newbie or something.

19:00 She does a podcast and she's been doing quite a bit in software to try to get more people involved with software.

19:06 And she's been doing a great job.

19:08 But one of the things that she wrote recently was just talking about if you're giving a technical talk, just improving it.

19:15 And I love this because it's just a zero in on one little bit to try to make presentations better.

19:22 The article is called Transitions, the Easiest Way to Improve Your Tech Talk.

19:27 Improving how you speak.

19:29 Public speaking is part of one of the things I work on personally.

19:32 So, I'm going to, before we get started, I'm going to grab a quote that I got read recently from Jeff Atwood from Coding Horror.

19:40 He said, the people who can write and communicate effectively are all too often the only people who get heard.

19:47 They get to set the terms of the debate.

19:49 And I think that definitely applies to public speaking as well.

19:53 So, that's one of the reasons why I picked this up.

19:56 But one of the things that, so, Saron mentioned is the typical way people will default to presenting something is they get, they put their stuff that they want to talk about on slides.

20:06 And then they talk about whatever's on the first slide.

20:09 And then when they get to the, and then they pause, click to the next slide, and then talk about the new topic.

20:16 This is where the focus is of this article is to try to work on those transitions.

20:19 And it's a simple thing.

20:23 I think it would take practice.

20:24 It's definitely something I'm going to practice.

20:26 But as an example, she talks about transitioning from one slide to another.

20:31 Instead of pausing, you can have a sentence transition as well.

20:36 So, you can, for instance, say, and that's why documentation is important, as we see on this slide.

20:44 And span that sentence over transitioning from one slide to another.

20:49 And you can even time your clicking from one slide to the next and how you transition a sentence from one to the next.

20:56 This totally makes sense.

20:58 And we've been doing it in writing all the time, transition sentences in paragraphs.

21:03 And we get, we've been dinged on it throughout school.

21:06 But somehow we forget to do it while talking.

21:09 So, I just wanted to bring this up and highlight this article.

21:12 I think this is great.

21:13 It's such a good recommendation.

21:15 And when I first started doing in-person training, you know, standing in front of, you know, 20 people giving technical training is highly nerve-wracking, especially when you're new to it.

21:28 And it's easy to get derailed or try to, like, you kind of fall back to reading your slides, which is, like, really not very engaging for anybody.

21:37 So, the thing that I found was super helpful is if I could have one sentence that's engaging, like, this is how I'm going to start this slide.

21:45 Everything is just downhill and, like, smooth from there.

21:49 And this really seems to kind of capture that same idea.

21:51 Like, every part of your presentation, if you can start it well and you feel good, like, yeah, this is going great.

21:57 Like, you just, you have that natural momentum that just keeps going.

22:00 But if you start it clumsily, it distracts you and it just goes downhill in the wrong way, right?

22:05 So, this is actually a huge benefit, I think.

22:08 But it's so easy.

22:09 Like, can you have one sentence for each major concept in your presentation?

22:14 Like, it might be 10.

22:15 Like, how hard is that, right?

22:16 It's not that hard.

22:17 But it's super valuable.

22:19 Yeah.

22:19 Yeah.

22:19 And then, also, I think when I've been presenting before, I will take advantage of the end of the slide to take a little micro break.

22:28 And it's nice for me.

22:29 But it's kind of annoying for the viewer to sit there and watch nothing as the person transitions from one slide to another.

22:36 But now there's, she brings up that there's definitely times where you really are transitioning ideas that it's perfectly fine to take that little break.

22:45 It gives everybody a rest a little bit and you're moving on to a new topic.

22:49 That's a great time to not talk while transitioning.

22:52 Yeah.

22:52 Silence is important, too.

22:54 Right?

22:54 Yeah.

22:55 Like, people too often think, I have to be absolutely continuously making noise.

22:59 Right?

23:00 But, like, a few seconds of silence as a point sinks in or you are transitioning ideas, it's also really valuable.

23:06 Yeah.

23:06 Anyway.

23:07 So, cool.

23:08 Cool.

23:08 Great pick.

23:09 So, it's so cool that PEP582 is presented as an idea, but there's this problem.

23:15 Like, since Guido has stepped down, there really hasn't been any way to even address these PEPs, right?

23:22 Because how the decision-making happens, it's just been on hold, right?

23:26 Yeah.

23:26 So, maybe that PyPackages thing is just going to be in limbo forever?

23:30 No.

23:31 Finally, we have good news.

23:34 The final governance model for Python was chosen to be the steering council model.

23:40 And the people who populate that council, the first steering counselors, I don't know if you call them that, but I'm calling them that.

23:48 The first steering counselors have been elected.

23:50 And so, our new technical leaders are Barry Warsaw, Brett Cannon, Carol Willing, Guido Van Rossum, and Nick Coghlan.

23:56 All great folks.

23:58 And congratulations to them.

24:00 And this is news sent to me from Joe Carey.

24:03 So, thanks, Joe, for sending that in.

24:04 Yeah, that's awesome.

24:05 Good thing.

24:06 Very good pick.

24:07 So, of course, there's tons of great people that would have been fine, but these are good sets.

24:13 Yeah, I think it's a great set as well.

24:14 I think one of the things that's really cool here is we have Guido Van Rossum is not gone.

24:20 He didn't just go like, you know what?

24:22 I'm going to go do Go or whatever, right?

24:24 He's still on the steering council.

24:27 He's still part of Python.

24:28 He just doesn't have to bear the brunt of all the friction of moving it forward on himself alone, right?

24:36 So, he's still part of this, which I think is great.

24:38 Yeah.

24:38 Also, happy to see Carol Willing on there.

24:40 That's really good.

24:41 So, very, very good news.

24:42 All right.

24:43 So, it looks like maybe stuff will start happening around Python, which is long overdue, actually.

24:49 Yeah.

24:49 They still have a lot to figure out, but we will report it when we hear more.

24:53 There's a bunch of good things happening in the community, a bunch of good ideas being proposed, like this PEP we talked about at the opening.

24:58 And until this stuff gets finalized, it just literally cannot be addressed or any action can be taken.

25:05 So, it's really good to see this taking place.

25:07 Yeah.

25:07 All right.

25:08 Well, Brian, that's it for our six main items.

25:11 What else you got for us?

25:12 Well, I got interviewed recently.

25:14 So, I got interviewed for the IT Energizer podcast.

25:18 Right.

25:18 With Phil Burgess.

25:19 Yeah.

25:19 Yeah.

25:19 And you've been on there, too.

25:20 So, we're going to drop a link to both of our interviews in the show notes, but mine's better.

25:25 So, listen to mine.

25:26 No, they're both good.

25:28 That's great.

25:28 I hadn't listened to yours yet.

25:29 I knew you had been interviewed, but it hadn't been out yet.

25:32 So, I'm looking forward to listening.

25:34 Yeah.

25:34 And then also, I'm sorry.

25:36 I can't remember who sent this to us, but somebody mentioned to us that PyCon Latin America

25:41 is coming up in Puerto Vallarta, Mexico on August 29th.

25:46 And the call for proposals is open until May 31st.

25:50 That sounds super.

25:51 It'd be great to go down there and spend some time where it's warm.

25:54 And it's in the summer, right?

25:56 A lot of people have maybe a little more flexibility.

25:58 Yeah.

25:58 So, call proposals.

26:00 Get them out there.

26:01 Get your talks in.

26:02 Plus, it's in Puerto Vallarta.

26:03 We should go.

26:03 Exactly.

26:04 We have to go do a live podcast recording because work.

26:08 Yeah.

26:08 But so, if somebody wants to sponsor us to go down there, that would be awesome.

26:11 Yeah.

26:12 That would be great.

26:12 So, there's something wrong with this episode.

26:14 We haven't really fulfilled our duty.

26:16 I don't think we've even mentioned Anthony Shaw yet on this show, have we?

26:19 I'm not sure how Anthony is part of this, but...

26:24 He's so prolific.

26:25 He seems to always have something we ground.

26:26 Yeah.

26:26 Okay.

26:27 So, we've got our joke section.

26:29 And you put a list on our database of show ideas.

26:33 Is this list coming from Anthony?

26:35 But it's not his list, is it?

26:37 Or did he just tell you about it?

26:38 No, he just said, hey, Michael, you should check out, or hey, Python Bytes, you should

26:42 check out these jokes.

26:44 So, they're not his jokes.

26:45 They're just transferred to us via him.

26:47 Okay.

26:48 I couldn't pick one, so I've got a few.

26:49 All right.

26:49 Hit me.

26:50 Okay.

26:50 What's the second movie about a database engineer called?

26:53 The Migration.

26:54 Oh, that would be good.

26:56 No, the sequel, of course.

26:58 Of course.

26:59 The SQL sequel.

27:01 I love it.

27:01 Perfect.

27:02 All right.

27:03 These are like programming dad jokes.

27:05 I love them.

27:05 What's the next one?

27:06 Yeah.

27:06 Programming dad jokes.

27:07 Okay.

27:08 This one is not false.

27:09 It's funny because it's true.

27:11 Okay.

27:14 These are bad.

27:16 And this last one, I actually laughed out loud at this.

27:20 So, a programmer's spouse tells them, would you run to the store and pick up a loaf of bread?

27:25 If they have eggs, get a dozen.

27:27 The programmer comes home with 12 loaves of bread.

27:29 That's right.

27:31 They must have had eggs.

27:32 All right.

27:35 These are great.

27:35 These are great.

27:36 Thanks for putting these in here.

27:37 So, awesome.

27:38 Very cool.

27:39 Just for everybody that's annoyed with these jokes, we keep getting feedback from people that they like them.

27:43 So, they're going to stay in there.

27:44 Yeah.

27:45 People seem to love them.

27:46 Even if they're bad.

27:48 Thanks.

27:50 These are funny.

27:51 Yeah.

27:51 Thanks for doing the episode.

27:52 Talk to you next time.

27:53 Talk to you next week.

27:54 Bye.

27:54 Bye.

27:54 Bye.

27:55 Bye.

27:55 Thank you for listening to Python Bytes.

27:56 Follow the show on Twitter via at Python Bytes.

27:59 That's Python Bytes as in B-Y-T-E-S.

28:02 And get the full show notes at pythonbytes.fm.

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

28:10 We're always on the lookout for sharing something cool.

28:12 On behalf of myself and Brian Okken, this is Michael Kennedy.

28:16 Thank you for listening and sharing this podcast with your friends and colleagues.