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 Okken.
I'm Michael Kennedy.
And I'm Kojo Adresa.
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 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 like the random ones. Like, 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 your 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?
Ah, yeah, that would be cool.
Yeah.
You're right.
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 could 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 then 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 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
RoboCars 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 RoboCars are going, or the self-driving are 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 and 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. I, 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.
Yeah.
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?
Yeah. Rest in peace. I ran across an interesting article by Nick Timkovic, I think, called,
RIP Pipenv. Try too hard. Do what you need with pip-tools. So I didn't realize that 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 subdependencies
and complicated release process or something. But...
Well, I want to add one really bit of a small bit of detail here because I think it's interesting.
There's not been a release of Pipenv 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
whether, 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 one of the benefits that we saw with Pipenv was this idea
of pinning everything and using, like having 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 subpackages,
I put those in another file, a lock file with their hashes so that I can know that I can reproduce
that environment. And that's a, 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 pip enf 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 more about this than I do, Brian. Isn't pyproject.toml the new hotness
instead of pip file?
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, 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 in an application. With an application, you definitely
want to lock things down to know what you're doing.
For sure. Kojo, did you use pip enf 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 virtual. Well, I 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 want this 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 pipenv 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
--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, a 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 dot lower. And so you're not worried about whether someone types something in with,
you know, 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 case fold 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.
Well, and so the interesting thing about this is that, you know, lower works in a lot of,
it works. It covers a lot of, a lot of use cases, especially if you're, you're using English or
a similar language. It's interesting in the, the docs that case folding is similar to lower casing,
but more aggressive, which is just a little funny to hear when 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 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 Japanese. I taught myself to read and write 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, and 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, 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 like a, a slightly more flushed out example.
Yeah. Yeah. So let me just give people an example because aggressively lower casing,
that doesn't mean anything to me. When I 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 with 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,
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 a, 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 were on like an American or English
keyboard, you're like, I can't find that character. I'm just type two S's as common in German.
And if you case fold those, it will actually convert their flus with the S set that 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,
it'll take these letters that are, I guess, considered uppercase, but you know, 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, and, I've, I've seen the,
the example like that and I have no knowledge of German at all. And so, but it was useful to see
that example. It's like, okay, here's, you know, here's another concrete reason, you know,
why you might want to use this. but, 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,
that, you know, will work across the Unicode characters, then, you know,
it's not going to break once you get outside of, you know, the 26 letters of the, you know,
the English alphabet is helpful. So yeah. Yeah. Brian, did you know about this? I I'm like blown
away. I've always been doing lowercase. And so you've been doing it wrong. Yeah. I think it's
pretty new from like, I think it's a, 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. Cause it
hasn't been around that long, but as a, I think one, another thing that drew me to it
was that the idea that in Python 3 and going forward, everything is, you know,
everything is Unicode, the default sort of text handling mode 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 in, and again, bring 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, you know,
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
digital oceans, new memory optimized droplets. They're optimized, especially for these high
memory workloads. So check them out at pythonbytes.fm/digital ocean, and you can get a hundred
dollar credit. Awesome. Yeah. Thanks to digital ocean 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 enf, which to be clear,
the pip enf 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 enf, and this was like
the way to create virtual environments prior to VE and V being built in 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, VNV, 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, 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 said,
hey, we just did a major release of virtual enf. 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 can 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 pypi 3 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 package, or caches part of the seed,
the wheels as part of the seed packages, which after it's been created and cached, it 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 VNV is
not included with Python by default. For example, if you get the Debian or certain versions of Ubuntu,
and you say Python 3 dash MVNV, it'll say VNV 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 VNV. 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 two.
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 PipBend 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 so the fact
that people are trying to improve, you know, 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?
Yeah. Well, either installing all the things, or unfortunately there's, you run into sort of like
a namespace pollution thing where like almost everything is called like Pi ENV something or,
or pip Venve, 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 the good side of the bad side of the coin. Again, like it's great that these
things are being worked on because, you know, especially with Python, you want to have, you know,
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, you know, 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. All 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 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 the 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 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 have, 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 like a big set of the standard unit tests for CPython moved over
and maybe condensed and brought down into like this hypothesis style to see what the two sets of test
suites look like. That would be interesting. Feels 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 in 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.
Yeah. So property-based testing is a thing that I saw 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 Hatfield-Dowd and Paul, they are doing a tutorial on
property-based testing. And so what I wanted to talk about was just about, what time is it now?
Three of 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, you know, 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 haven't, 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 it, make connections with
people. Again, like if you are trying to say, for instance, you know, just to say with the hypothesis,
with the properties-based testing, if you're trying to implement that where you are, not only now is
there this effort to bring some property-based testing into CPython, but you take a tutorial,
you can actually interact with the people who are sort of leading this effort. And then if you have
specific questions, you've made a connection where you can reach out to those folks and try to get some
help as far as implementing, you know, trying to figure out, you know, 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, you know, 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, few things get
people's attention, like writing some code and making it, making the light turn on and making the light
change color or making it flash in a certain pattern. And so the Circuit Python, I remember, I think at
PyCon last year, everybody got like a Circuit Python 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 Katni's tutorials,
like a PyOhio in 2018, maybe. And so it's the Circuit Python boards are really interesting.
You've got lights and sensors and you can, you know, you can build all sorts of things with them.
And it's a great gateway into programming, great, great way to get started. Or if you're an experienced
developer, a great way to start 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 that 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. I mean, 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, you know, meeting people and making connections and that sort of
stuff. And the open, you know, the open spaces in 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 really good, a really good option for that.
I love that angle. And I also approached it the same way that you do is 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're talking about the hardware is 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, 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. You're 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 it, so I will be there. But yeah, Ian, I would have been there either way,
probably so. 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 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 Pippin's all upgrade, all the things on it.
Because yeah, there's like a SQL 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. And why is Pyramid and Waitress together? Is Waitress bundled with Pyramid?
It comes with Pyramid. And I think the guys who work on Pyramid may also work on Waitress. I'm not
sure I could be wrong about that. So 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, you know, 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 Guide to Software Development.
And I'll kick it off. There's like a cat with little like super bionic legs. And 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 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 like 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 happened 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 like action.
Yeah. What the customer really wanted, there's just a question mark, because nobody asked.
Exactly. And then how the software looks two versions later, it has a nose like an anteater or an elephant.
It's just a random human arm coming out the back of it.
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 their software.
That's great. All right. Well, this is 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. Bye, everyone.
Bye.