Python Bytes - #168 Race your donkey car with Python

Episode Date: February 11, 2020

Topics covered in this episode: donkeycar RIP Pipenv: Tried Too Hard. Do what you need with pip-tools. str.casefold() Virtualenv Property-based tests for the Python standard library (and builtins) PyCon US Tutorial Schedule & Registration Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/168

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 168, recorded February 5th, 2020. I'm Brian Ocken. I'm Michael Kennedy. And I'm Kojo Idrisa. Yay, we have Kojo here as a special guest. Hey Kojo, welcome to the show. Happy you're here. Hello. Thank you, thank you.

This episode is brought to you by DigitalOcean. Thank you, DigitalOcean. Michael, I'm actually confused about this. It's a little bit of a funny name, right? So let me tell you by Digital Ocean. Thank you, Digital Ocean. Michael, I'm actually confused about this. It's a little bit of a funny name, right? So let me tell you about Donkey Car. Have either of you participated in or at least watched a proper RC remote control car race? Not really. Just sort of the random ones. Like, you know, random people have random remote control cars and running them around the neighborhood.

But not an actual official proper one. No, I have not. Brian? Yeah, I just watched a little video that you sent me and it was quite exciting. These are really weird things. If you've never seen one of these, I put a link to like a three minute video from GoPro where they put a GoPro on one of these little RC race cars. I used to have one of these when I was a kid, like high school, maybe late middle school. And they're insane. They're these little cars and you remote control and they go like 35 miles an hour. They're super quick and responsive.

Really interesting. But what would be even cooler is if I could use Python to like win an RC car race. Don't you think? Yeah, that would be cool. You're right. Yeah. I mean, you've already got the GoPro on there. It's already got a camera that's high quality so the thing that i want to talk about is this thing called donkey car and it's a minimalist modular self-driving library self-driving car library for python so people are always looking for ways to get kids into programming or themselves to get into programming if they don't have some like formal project like i want to build this website or I've got the data science thing I want to do something like a self-driving car, I think it'd be really

interesting. They have some much tamer vehicles that they have pictures of on the donkey car repo where it's more like little Lego cars and stuff, but you basically have these little tiny cars and you can put cameras on them and you put a raspberry pi and then you teach it how to drive and i think that's pretty awesome yeah that looks fun doesn't it yeah so it says you can use a donkey car if you want to make an rc car drive itself and win an rc car race that would be awesome if you want to compete in self-driving races like diy robo cars are you know the great robot race from darpa way back in the day. I guess that's probably a little bit quite enough, but still quite cool. If you want to experiment with like

autopilot or mapping computer vision and neural networks, if you want to log sensor data while you're driving around, if you want to drive a car via an Xbox game controller, that's pretty cool. Because you can then communicate, you know, with the controller over to the Raspberry Pi and then just tell it to drive however it tells it. Yeah, a lot of cool stuff. And yeah, I think if you have anything to do with like you're playing with AI and computer vision, this seems like a really fun way to make it interactive or kind of exciting without a lot of code there's it's pretty simple actually do you know if any of these uh robo cars are going or the self-driving or going like 35 miles an hour i don't see well when i watched the video that i included like on

one hand like i don't see why it would be hard because they have these little rails and it's kind of clear where the edge of the track is you could even put up markers like little things that you could like shine you know have detected with the computer vision but they're so bouncy they're incredibly jiggly and it's really hard i think i think it would be a little bit hard so maybe slow but i don't know my joke about winning the race it seems a little far-fetched you'd have to have a really stable camera which i guess you could get there but anyway i think this is a fun one so if people are out there looking to play with a little far-fetched. You'd have to have a really stable camera, which I guess you could get. But anyway, I think this is a fun one. So if people are out there looking to play with a little AI computer vision,

this seems cool. Check it out. It's very interesting. Yeah, for sure. Brian, there's a bit of a sad one coming up, right? What's going on here? Yeah, rest in peace. I ran across an interesting article

by Nick Timkovic, I think, called RIP PIPENV, Try Too Hard, Do What called RIP PIPENV. Try too hard. Do what you need with PIP tools. So I didn't realize that PIPENV was kind of stagnating. There's not been a release in 2019. I didn't check to see if maybe they slipped one in in 2020 yet. But apparently there's some problems with the sub-dependencies and complicated release process or something.

Well, I want to add one really small bit of detail here because I think it's interesting. There's not been a release of PIP-INF in 2019. And that makes it sound like all people have walked away, haven't done anything. There are 650 commits to that project and there's still not a release in the year, which is kind of rough, right? Like the people who worked on it, if that stuff's not getting released, that can't be great. Yeah. So I'm not sure what's going on, but the main emphasis of the article really isn't that, I mean, whether or not PIPENV survives or it's really dead. I don't think it's dead. I don't know what the state of it is, but the, one of the benefits that we saw with PIPenv was this idea of pinning everything and using like having a, have a PIP file and a PIP

lock file or a lock file that says, these are the packages that I really depend on. And then all of those plus all of the sub packages, I put those in, in a another file, a lock file, with their hashes so that I can know that I can reproduce that environment. And it's a really cool idea. I like the concept. Most of the bulk of the article is just basically saying you can do that yourself without PIPenv. You can use PIP compile that comes from PIP tools, and there's a generate hashes function. But basically, you do that yourself. You just have a smaller requirements file that just has what you really need your direct dependencies and then

you can generate a hash file that is directly readable by pip you can pip install from this this other generated hash requirements file the other part of pipenv that people are using is virtual environment support. But I guess I'm on board with Nick to say, I don't understand why these were bundled into one tool. And I'm using virtual VENV, the built-in, just fine. I don't really need PIPenv for that. So I think I'm going to try to incorporate this possibly in my workflow, at least on one project to see how it goes. Yeah, that's pretty cool. I didn't realize you could output the requirements.txt

with the hashes using pip compile either. That definitely was one of the selling points of pipenv was like everything is locked, not just by pinning the version, but by the hash as well to make sure that it couldn't get messed up. Pipenv uses pip compile anyway, so. I see.

And it uses pip file and pip file.lock. You know is pipcompile anyway. I see. And it uses pipfile and pipfile.lock. You know more about this than I do, Brian. Isn't pyproject.toml the new hotness instead of pipfile? The pyproject.toml doesn't have, I don't think that it supports doing hashes and stuff like that. So they still

kind of support different ideas. I think the pyproject.toml is.toml. I'm not sure where they cross over, but there still is this difference between a library that you can use for lots of stuff with lots of different versions of things

and an application. With an application, you definitely want to lock things down to know what you're doing. For sure. Kojo, did you use pipenv any? What's your virtual environment preference? So I used it a

small amount. I never used it a huge amount. I think my virtual environment preference has been, well, it had been virtual env wrapper, but I've recently started using pyenv. Well, actually, I started using pyenv, but that's more for managing different versions of Python. Right, right. I started using PyEnv, but that's more for managing different versions of Python.

Right, right. There's virtual environment to be Python 3.7 and that one to 3.8 and GASP, that one too. Yeah. And so I've been using PyEnv to manage different versions of Python. But then there's a PyEnv-VirtualEnv module. And so that makes it a little easier to create virtual environments as you switch between Python versions. But for me, so pipenv, again, I'd never really gotten into using it. But having looked at it a little bit, and I saw some of the early talks about it,

it introduced me to that idea of a lock file. And then my personal blog is Jekyll, which is in Ruby. And Ruby uses a similar thing, that sort of gem lock file. And so just the familiarity with it there from pipend was helpful to me as far as having to try to sort out stuff with Jekyll because I don't, Jekyll is the only thing, the only Ruby project I use. It's the only time I ever really use Ruby.

So it was helpful at least to be familiar with that set of concepts there. Yeah, yeah, cool. And Brian, I'm very excited about Python 3.9 having the dash dash prompt dot. So you get the folder name without the extra bits that you have to put in there to make that happen in the shell. Yeah. That's going to be cool.

I love using prompt. Yeah, for sure. Kojo, what you got next? I'm going to talk about string method called case fold. And this is something that's interesting. It actually just came up this morning. I was working on something this morning. And you can use case fold in places where you're trying to do comparisons without having to look at the case of a string. And so they call it caseless matching.

And so the standard thing in Python or the more common thing that you would do in Python is maybe you use like the string method like string.lower. And so you're not worried about whether someone typed something in with uppercase or lowercase. And that works in a lot of situations. Wait a minute, wait a minute. You're telling me that I've been doing it wrong for all these years? Completely wrong? Shame on you. Yes, I didn't. I knew the function casefold was here, but until you brought it up, I'm like, oh,

whatever, like lowers. I've been doing it wrong. Carry on. This is awesome. I'm ready to hear about it. So the interesting thing about this is that lower works in a lot of, it works, it covers a lot of use cases, especially if you're using English or a similar language. It's interesting in the docs that case folding is similar to lower casing, but more aggressive, which is just a little funny to hear. One of my coworkers got a kick out of that.

And I think where case fold becomes especially useful is if you're using a lot of Unicode characters. And I think, Michael, you had an example here. But so it stood out to me partially because I was working on a thing where I wanted to make sure cases, things were being compared and I didn't have to worry about the case of what was entered versus what was expected. Right, right, right. And until like today, I would have written.lower.strip and been happy with that.

Exactly. And so I started looking for some other ways. I, in addition to other things, I lived in China for two and a half years, so I can read today i would have written dot lower dot strip and been happy with that exactly and so and i started looking for some other ways i in addition to other things i lived in china for two and a half years so i can read and write mandarin a functional ability to read and write uh japanese i taught myself to read at hangul and so i tend to use unicode characters maybe a little more a little more frequently than than the average american and so for me, I was like, if I'm trying to build something and I'm concerned about handling text or case matching, I'm always interested in things that will support Unicode

because the Unicode characters, because, you know, of course, like Emoji, probably the most popular Unicode characters among English speakers, but you also have a number of other languages where the entire language is represented in Unicode characters. So something like this that will work in these situations where you get Unicode characters is important. So like I said, I just discovered that this morning and ended up using it in a test I was writing. And I'm like, okay, I can see how I can use this going forward. And I think, Michael, I think you've got a slightly more

fleshed out example. Yeah, yeah. So let me just give people an example. Because aggressively lowercasing, that doesn't mean anything to me. When read this i'm like i still have no i read what the the docs said about it i'm like i still have no idea what this means like if i had like michael dash kennedy would the dash be down like underscore now like i mean i just i don't even know right and so i found this example and it has two strings der der Fluss, the river in German, and there's sort of the formal German way to spell it, where you have an, what's called an S set. It's like, it looks like a beta symbol, which is like two sharp, two S's together, like a super S. And then you could just, if you are on like an American or English keyboard, you're like,

I can't find that character. I'm just going to type two S's as common in German. And if you case fold those, it will actually convert der Fluss with the S set, like the beta thing, down to lowercase F-L-U-S-S and compare it, which I had no idea. That's pretty cool. So it'll take these letters that are,

I guess, considered uppercase, but not quite the same. And it'll sort of normalize the string more than just lower is the way I see it. It's like the canonical lowercase version of it. Yeah, and I've seen the example like that and I have no knowledge of German at all. But it was useful to see that example.

It's like, okay, here's another concrete reason why you might want to use this. But I think also with a lot of applications, be they web applications or standalone apps, when people are dealing with internationalization and localization, that kind of thing, having some sort of a method for caseless matching that you know will work

across Unicode characters, then you know it's not going to break once you get outside of the 26 letters of the English alphabet is helpful. Yeah. Brian, did you know about this? I'm like blown away. I've always been doing lowercase. And so I'm going to change right away.

Yeah. I think it's pretty new from like, I think it got added in Python 3.3. So it's not, you know, it's not like, you know, it's not like a thing that you haven't been using for a very long time because it hasn't been around that long. But I think another thing that drew me to it

was that the idea that in Python 3, going forward, everything is, you know, everything is Unicode, the default sort of text handling what is Unicode. And so it's not brand new, but it's also not like super old. So if you haven't been using it, you haven't been, you know, missing out. And again, string that lower still works unless you run into a situation where you were actively having to deal with unicode characters, which, which a lot of us, honestly, a lot of folks here in the U S don't. So, yeah. Yeah. Pretty interesting. Thank you. That's awesome. This episode of Python bytes is sponsored by digital ocean. They have awesome infrastructure and awesome product,

and we use them in our services. Do you have a memory intensive workload, maybe something like a high performance SQL or no SQL database or an in-memory cache, like maybe Redis or some indexes or some kind of large data analysis runtime. Well, check out DigitalOcean's new memory optimized droplets. They're optimized, especially for these high memory workloads. So check them out at pythonbytes.fm slash DigitalOcean and you can get a hundred dollar credit. Awesome. Yeah. Thanks to DigitalOcean, and you can get a $100 credit.

Awesome. Yeah. Thanks to DigitalOcean for sponsoring the show. Brian, I feel like we're kind of in the same groove this week. You pick this rest in peace pip-inf, which to be clear, the pip-inf people didn't say rest in peace our project. Someone from the outside looked at it and made this declaration, but it's still an interesting article, right? Yes.

Something that I have often wondered about is like, you see a lot of times people talking about virtual inf, and this was like the way to create virtual environments prior to VE and V being built in Python, right? Yeah. Yeah. There's a new release of it. And my first thought was, why? Why is there a new release of it?

Because Python 3-M, V and V, whatever i'm going to type after that seems like it's solving my problem for me and so why would you continue to work on this you know like it's we're technically in the post python 2 era officially right i mean not in practice there's a lot of python 2 still out there but it is now no longer supported being past january 1st 2020 so why work on this thing right well b Brian Skin sent in this and I'm like, all right, I'll take a look. Brian usually recommends good stuff. And it's this announcement by Bernat Gabor, who is working on the project and say, Hey, we just did a major release of virtual. I'm like, okay, I got to figure out why this is still a thing. And he said, look,

there's a couple of pain points that exist with current, you know, the dash MV and V style, that creating a virtual environment is slow, it takes around three seconds, even in offline mode. Unless you're on Windows, then it takes longer. I don't know how much longer, but it seems to be that it copies more into the virtual environment rather than sim linking it on Windows. So it seems like it's a little slower. The other thing is that the API used around pep 405 is great if you just want to create virtual environments. But it doesn't allow you to target very much around that or describe the target environment without actually creating the environment. And then the duality of virtual ENV versus VNV. So Python 3.4 has VNV added, as I said. So in theory, you could just switch away.

But there's some other benefits that he talks about as well. So over specifically over VNV, which is the ability to discover and use alternate Pythons, right? I could say dash P2 to create a virtual Python 2 virtual environment, or kind of like you were saying, Kojo, I could say dash P3.8 or 3.7 or even dash P pi pi three and get one of those environments created. So I can select from the different installed pythons as I create these, which is pretty cool. It also packages out of the box out of the box, it packages the wheel package as part of the seed pack or caches part of the seed, the wheels as part of the seed packages, which as part of the seed the wheels as part of the seed packages which after it's been created and cached and speeds up the install time especially for things like micro whiskey or whatever like that thing takes 15 seconds to pip install at least so making

that faster seems awesome and it's also guaranteed to work in places where ve and v is not included with python by default for example if you get the debian or certain versions of ubuntu and you say python 3-m venv it'll say venv is not installed on this computer and you've got to apt install it right which is kind of funky and then around that as well you can also because it's pip installed not apt installed it will you know you can upgrade it right away with pip whenever there's new changes and version it separately than what the os is versioning v and v so i don't know what do you guys think does that that sounds like a pretty good reason for it to be around actually all those reasons yeah the downside of it's confusing to

have to it is confusing to have two well and i was confused about as well and i'm not saying i'm switching to it necessarily but i can see why that it's pretty interesting i guess i'm sort of between the two of you from the standpoint of i like that there is a lot of activity in this space as far as both like we just we just talked about pip end with you know virtual environments and with you know installing and package management that sort of thing it's sort of a tricky issue and package management, that sort of thing, it's sort of a tricky issue. And so the fact that people are trying to improve,

people are looking at pain points and trying to build tools to improve on those is fantastic. I think sort of the confusing part is, and again, as someone who just started a new job, and I've just been going through the process of setting up a new machine. You've been installing all the things, right? Well, either installing all the things or unfortunately there's, you run into sort of like a namespace collusion thing where like almost everything is called like pi E N V something or, or pip venv or, you know, like a lot of the names are very similar. It's one of those things where it's, you know, sort of, uh,

the good side of the bad side of the coin. Again, like it's great that these things are being worked on because, especially with Python, you want to have some sort of separation, some sort of dependency management. And so wanting to make sure that you're developing the right version of Python and that you're not overriding things or creating conflicts.

But I guess it's a situation where one or two dominant solutions show up. We'll sort of standardize on those. But now there's a little bit of confusion as we get to that point. Yeah, yeah. It's good to see a thousand flowers blooming, but it is tricky to know which one's going to be around. Right? Which flower do you pick?

You know, there are literally a thousand of them blooming, Seth. Exactly. Exactly. Brian, what you got next for us? Well, a little bit of testing. I don't know if we've talked much about hypothesis, but people probably know about hypothesis, property-based testing. Hypothesis is kind of mind-blowing a little bit, to be honest.

It isn't a silver bullet, but it's kind of a cool thing. So I am highlighting a project which is relatively new by Zach Hatfield-Dodds and Paul Gansel, who are two people working on it so far. This is the idea of adding property-based tests for the Python standard library and for the built-ins. And their comments are that CPython's existing test suite is actually very good, but bugs do still slip through occasionally, and maybe throwing some property-based testing tools at some parts of it could help.

It's not a magic bullet, but computer-assisted testing techniques routinely try inputs that humans wouldn't, and Hypothesis is what we got for Python, so why not? There's not very much covered yet in this project, so I'm highlighting it to try to get other people that are interested on board, but they want to try to have a compelling proof of concept by PyCon US this year to be running as a, and to see if it'd be worthwhile to have it running as part of the Python continuous integration suite to see how that goes.

I think it's really, my view on the hypothesis really is that it's especially geared towards helpful for algorithmic pure functions. And in a lot of cases where you have like two functions especially geared towards helpful for algorithmic pure functions. And in a lot of cases where you have two functions that work kind of in opposite directions, so you can do round trip, it's easier to set up a test for hypothesis to see. Like, for instance, encode or decode. You can take some sort of string or something and encode it, and then use the decode to make sure that you've got the final output is the

same as your input. These are easier tests. Functions that are not pure, that have state, that depend on state, those are harder things to test with Hypothesis. So I think there's actually quite, and that kind of applies to a whole bunch of the standard library. So I think there's a whole bunch of stuff that could be tested more thoroughly with Hypothesis. So this is pretty cool. Yeah, it's a really interesting way of testing and I'm glad

to see the project. It looks cool. One of the things I like about it is these are some people that I respect and having some people do these focused examples of how to use Hypothesis in this way, I think will actually help as a teaching tool to help other people learn how to use it. Yeah. I would love to see a big set of the standard unit tests for CPython moved over and maybe condensed and brought down into this hypothesis style to see what the two sets of test suites look like. That would be interesting. Sounds like a lot of work. That would be interesting. Oh, but even like a specific case of taking like one,

what are the functional tests that exist in CPython already? What do those look like compared to the property-based test? They're testing different things, so I think it'd be cool to see them side-by-side too. That's neat. Yes, and so property-based testing is a thing that, sorry, in my prior

job, I did mostly QA, and so I started to look into property-based testing. It's one of those things that it sounds very interesting and that something that I'd like to know more about and just have another time to dig into. But this project looks interesting. And it also kind of flows right into my topic. So the people that you were just talking about,

Zach Hatchfield-Dodds and Paul, they are doing a tutorial on property-based testing. And so what I wanted to talk about was just a – what time is it now? Three in my time? So about two hours ago, I got an email from PyCon saying that the PyCon tutorials, the schedule for the PyCon US tutorials, PyCon US 2020, the schedule for those tutorials is up and available, and you can register for them now.

And so if you are thinking about going to PyCon, depending on what you do, different people, you know, some people work in places where their companies would just send them PyCon and it's not a big deal. Other people have to make a business case to try to sort of convince their organizations to let them go. If you are in a situation where you need to make a business case, the tutorials are often an excellent tool for that because you can get a lot of high quality training from people who are very knowledgeable in their fields. And so one of the sets of people, one of the tutorials is actually an introduction to property-based testing by the same people that Brian was just talking about. So there's a link here to PyCon.org. So there's a full schedule of

the different tutorials that are available and you can register for them now if you'd like. They do tend to sell out pretty quickly, though. The PyCon tutorials tend to be pretty popular. They tend to sell out pretty quickly. The good news is that the videos of the tutorials are all available. So even if you weren't able to make it to a prior PyCon, the videos for those tutorials are available. And so you can look at past tutorials. The big advantage of actually going to PyCon and going to a tutorial is, again,

just the fact that you have a chance to interact with the people who are giving the tutorial and to be able to ask specific questions that meet your specific use case. Yeah, and make connections, right? Yeah, exactly. I mean, make connections with people. Again, like if you are trying to say,

for instance, you know, just to say with the properties-based testing, if you're trying to implement that where you are, not only now is this effort to bring some property based testing into CPython, but you take your tutorial, you can actually interact to those folks and try to get some help as far as implementing, trying to figure out what to do to implement that kind of thing where you are to get a better understanding of the use cases, that sort of thing. So I went through, like I said, I think the schedule just went up an hour or so ago. So I went through and sort of looked at ones that were interesting to me. A couple of standouts to me were, one, there's a tutorial on migration from Python 2 to Python 3. And as Michael was just talking about, Python 2 is now end of life. And so, you know, if you have not moved to Python 3, now, you know, now is the time,

you know, earlier was really a better time. But, you know, there's no time better than now if you haven't done it before. So a tutorial on that, that'll be really helpful. Another one called Welcome to Circuit Python by Katni Rembor. We were talking before with Michael's point about the remote control cars. If you're looking at ways to get started with programming or to get other people into programming, actually programming

hardware is a good way to do that. You know, a few things get people's attention, like writing some code and making it, making the light turn on or making the light change color or making it flash in a certain pattern. And so the CircuitPython, I remember, I think at PyCon last year, everybody got a CircuitPython playground board, like a small little mini circular board that had lights and various sensors on it.

And so I've been to one of Katniss' tutorials, like at PyOhio in 2018, maybe. And so the CircuitPython boards are really interesting. You've got lights and sensors and you can build all sorts of things with them. And it's a great gateway into programming, a great way to get started. Or if you're an experienced developer, a great way to get started with hardware programming. And then the intro to property-based testing. And then there's another tutorial called Minimum Viable Documentation by a woman named Heidi Waterhouse. And I've met Heidi.

We spoke at PyCaribbean together, I think a couple of years ago. But it's this idea about how do you set up a proper technical, you know, a proper documentation structure for your projects and focusing on the technical writing aspect. I think it's one of those things, especially as a project gets larger, but even in a smaller project,

it gets overlooked sometimes. There's so much focus on let's write code that does this thing. And that's fantastic. But what if you want to add a second person, add a third person to that project and your options then become either the first person sits down and just spends four hours talking to the new person, you know,

or if you have good documentation, a good documentation, a good documentation structure, you can just point them to the documentation and let them get up to speed on their own. And there are, there are multiple other tutorials, but those are ones that just sort of stood out to me. But if you haven't been to a PyCon US, the tutorials are, I think, one of the strong reasons to want to go.

Among other things, meeting people and making connections and that sort of stuff, and the open spaces and the hallway track. But the tutorials, especially also if you're in a situation where you need to make a business case to your company to get support to go, the tutorials are a really good option for that. I love that angle. And I also approached it the same way that you did. It's like, oh, these are out. Let me see which are interesting to me. So I came up with three as well.

Maps and machine learning. Spatial analysis with TensorFlow, Scikit-learn, and PyTorch. And I think it's really cool, kind of like you were talking about the hardware. It's like you take geospatial data and real-world things and do awesome stuff with it with Python. So here's kind of the map version of that. I think that one's a fun one. And then hands-on web app test automation by Andrew Knight.

Brian, that'd be a good one for you as well, right? Like that sounds pretty interesting. Yeah, it does look good. Yeah, and finally, bigger, better, Brian, that'd be a good one for you as well, right? Like that sounds pretty interesting. Yeah, it does look good. Yeah, and finally, bigger, better, faster, more, building applications in Python. That also looks pretty cool to me. So there's a bunch of other great, and this is not like the best of list or whatever.

This is just like stuff that stood out to me, like, oh, I'd go to these. Sounds pretty cool. And these tutorials are priced way lower than any sort of corporate training is going to be priced. Yeah, yeah. Very cool. You guys are both going to be at PyCon, right?

Brian, you're speaking. Is that true? I am speaking, yes. On what topic do you speak? I am talking about parameterized testing. Awesome. And Kojo, I'm guessing that you're going to be there at a lot of the conferences. Yeah, and actually, so this year, I just started a new job.

I'm working with a company called RevSys now. They're sponsoring, and so I will be there. But yeah, Ian, I would have been there either way probably. Yeah, awesome. I'm glad you're going to be there as well. All right, Brian, I guess that's it for our main items, huh? Yeah, it is. You got anything to share with folks?

I was going to share with folks that I'm speaking at PyCon, but we already covered that. We snuck it in the previous one. How about you, Kojo? Anything extra you want to throw out there for the world? No, I don't think I have any new exciting Python-related stuff. Well, I've got a couple to share. One, Eric Cho just released the third edition of his Mastering Python Networking,

which is a cool little use Python to control all the network things and set up network topologies and whatnot book, which is quite interesting. And I got a chance to write the foreword for that. So thank you, Eric. And I'll link to the book. Also, speaking of network things, both Pyramid through the Waitress web server thing and Django have issued like vulnerability CVEs.

So yeah, if you have either of those in production and they're on the internet or even not, you might want to do a little upgrade a pip install upgrade all the things on it because uh yeah there's like a sequel injection vulnerability like a little bobby tables vulnerability in django and some other similar type of thing for waitress and those are not good to have why is pyramid and waitress together is waitress bundled with pyramid or it comes with. And I think the guys who work on Pyramid may also work on Waitress. I'm not sure. I could be wrong about that. Sorry, people who work on Waitress, if I got that wrong.

But certainly, when you install Pyramid, you get Waitress and you want that to be up to date. Waitress, server, things like that. Okay. And then the last thing, kind of like your item here, Kojo, even shorter time, like 45 minutes ago, the Stack Overflow 2020 survey is open. So everyone should go fill that out. There's a ton of information about where the broader ecosystem is at here. So it takes about 10 minutes.

It's a little bit long, but it's totally worth it, I think. Yeah. And if there's anywhere in there where you can plug our podcasts, go for it. I don't know if there is. There totally should be. Like, where do you get your news or something like that? Yes, exactly. Other. All right, Brian, I picked a joke for us that's graphical,

so we have to do a little work describing it. But I think it's going to come out pretty well because I think it's right up your alley, actually, here. So this is a comic, which is Richard's's guide to software development and uh i'll kick it off there's like a cat with little like super bionic legs and it underneath the caption is how the software is designed you want to take it from here okay well then the next one is how much time is has to be spent on each part? And there's like 4% for the head and then 2% for the middle of it, 80% for the tail.

Oh, yeah, that's totally true. Nice. The next one is how the software looks before the beta test. It's a cat, but it has no back legs at all, but it's still suspended somehow. Yeah. And then how the software looks after the beta test, there's no front legs, but there are back legs. I'm just trying to imagine what happens here. Like, no, no, we wanted legs on the back of the cat.

Like, oh, you want the legs on the back? Sure, we'll put them on the back. Okay, we'll just move them. Yeah. And then how the software is advertised is like a tiger springing out of a picture with action. Yeah, what the customer really wanted, there's just a question mark because nobody asked. Exactly exactly and then how the software looks two versions later it has a nose

like an anteater or a or an elephant it's just a random human arm coming out the back of it uh that's oh man and the last scene has like a dude petting this cat that has the arm sticking out with the elephant nose saying, I still like you anyway. The cat says toots. Yeah. Anyway, there's a nice little testing one. Actually, for you as well, Kojo, right?

You were in QA. Yeah, it used to be. Yeah, the developers love your software. That's great. All right. Well, this was a lot of fun. Kojo, thanks for being here. And Brian, thanks as always. Glad to have you back this week.

Yeah, yeah. Thanks. Thanks for having me, you guys. Yep. Joe, thanks for being here. And Brian, thanks as always. Glad to have you back this week. Yeah, yeah. Thanks. Thanks for having me, you guys. Yep. Bye, everyone. Bye. Thank you for listening to Python Bytes. Follow the show on Twitter at Python Bytes.

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. This is Brian Ocken, and on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast with your friends and colleagues.