Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 189, recorded July 2nd, 2020. I'm Michael Kennedy. And I am Brian
Akin. And this episode is brought to you by us, our courses and our books and all those sorts of
things. Tell you more about that later. Right now, let's talk about improving Python exceptions.
Yeah, this came from Ram Ratcham. I'm probably getting his last name wrong.
But this is a pretty interesting article. Actually, I had seen this in code. So exceptions are a big
part of programming in Python, I think. Some people don't like to use them because they're kind of
difficult in some languages, but it's pretty easy in Python. So let's say you've got a, you're dealing
with an exception. You're inside of the accept part of a try accept block. And an exception happens. And
if an exception is raised from an accept clause, which exception should be reported? And I really
don't know what the mechanism was in Python 2. But there were changes made for Python 3 that are
associated with PEP 3.1.3.4 and others that both of them will be reported. So you get both exceptions.
But you get something like that. Often you get something that says during handling of the above
exception, another exception occurred. Right. Which is super frustrating because it's not actually saying
the error occurred trying to handle it. It's like, I'm trying to add more information to it or give you
more detail or more specificity or something like that, right? Right. So what Rahm is pointing out is
that if an exception is raised within an accept clause, it can be really one of two things. It can be
something, I called some code that I didn't expect to have any exceptions and an exception happened there.
And that's what kind of the default message sort of implies. But it might also be, and he has like this
long block, I'm just going to read it. An exception was raised and we decided to replace it with a
different exception that will make more sense to whoever called this code. Maybe the new exception will make
more sense because we're giving it more helpful error message. Or maybe we're using an exception class
that is more relevant to the problem domain. And whoever's calling our code could wrap the call with an
accept clause that's tailored to this failure mode. So a long mouthful, but basically trying to be nice
and raise a better exception or a better message or something. And in order to do that, all you have
to do is just change one thing and it's the from E. So within your exception clause, you accept something
as E or as, you know, any variable, but E is often used. You raise the other exception with a different
message from E and that little from will get you a message within traceback. We'll have both exceptions.
It'll say during the handling of the above exception, another exception occurred. Oh no, wait,
no, it'll say that's what we had before. It'll say,
That's a confusing one. Cause it looks like we tried to handle it, but we actually crashed again
inside the handling of it. Right?
Right. So the new thing, if you do the from E, it'll say the above exception was the direct cause of the
following exception. So that's a little clearer, I think. So you have the one on the top caused the
second one to happen. So you, you know that we're in the case of somebody's trying to wrap a, an exception
with a friendlier exception, which is subtle. The reason why I kind of, I don't know, I just like it.
Rom likes it. And, but he didn't see that no, that like nobody was using it. So he went even
further and he went out and wrote a script that can look for probable places where that should be
happening. And he did, he did pull requests to a set of tools, scipy, map plot, lib, pandas,
py test, ipython, my py, pigments, and sphinx, which is like awesome that he just went out and
did pull requests against all of those projects. Oh, that's really cool. The other thing he did was he
wrote a new rule for pilot. And so w 0 7 0 7 raise, raise missing from, which is kind of weird, but, but
basically pilot will now catch it. So if you use, the most recent, it's not released yet, but if you
run pilot from GitHub, you can see that rule. But the next time they release pilot, it'll be in there.
Yeah. This is neat. I like it. I think it's confusing the way it is now, if you don't do it
the right way. And I also often get messages from students saying, Oh, I got this really bizarre
error, like some, you know, some other thing. And the problem is buried in the other part of this
whole story. Right. And it's, it's not clear what part they should be paying attention to. So I think
this makes it more clear and it's nice. All right. Well, the next thing I want to talk about
is publishing data science and other interactive stuff on the internet. Now there's a couple of
ways you can do this. You could go to like Google collab and whatnot, but Tim Pogue sent over this
new place where you basically custom built for this story and it's called data pain. So data pain is an
open source framework, which makes it easy to turn scripts and notebooks into interactive reports.
So you can export a Jupyter notebook as a report, but then it's just static. You can't interact with
it. Or if you try to run it, then, you know, there's a bunch of code in there and there's all
kinds of stuff that you probably don't want people to see. So data pain is a way to like create and host
interactive HTML that runs against APIs and runs data and so on. It's pretty cool.
You go in there and like use sliders to adjust what's happening in say a graph or filtering or
things like that. That's neat. So this is one of those things that it's a paid service, but they
have free accounts that you can do, right? Yes, exactly. So I'm not entirely sure the whole
spectrum of what's going on. So it says it's an open source framework. So I think there's an API
that you bring in to make this happen. And there might be a self-hosting story. They also have a
platform for publishing it too. And on that platform, it's free for individuals, but I,
I can't find a price anywhere, but it looks like they're going to eventually charge like for a team
commercial corporate version. I don't really know what's going on with that anymore, but it's free
for individuals and you can use their open source framework to generate these reports.
Okay. And they also have the gallery there. So I was looking for, found it for a while.
So obviously right at the top says open, open analysis gallery for looking at pictures.
Exactly. Yeah. So the idea is that you can use like the tools that you already know and love. So
you, you can use Jupyter or Colab or Airflow and you can build reports using their frameworks,
using Markdown as well. And cool libraries that people probably are already using for visualization,
like Altair, what I've been using for my visualizations lately. And then you can either
export these as standalone HTML files, which is one option. That's the totally disconnected,
just take the library. The other one is you can publish them to data pane for free where you can,
people can share them and embed them. And there's probably this paid corporate thing that I don't have
details on. Nice. Yeah. So you're going to add like forms to help filter and drive the report.
You can have a talk to APIs. Also they have APIs that you can use to deploy your scripts to their
server. And you can even have integrated set up with like GitHub actions or Airflow or standard CI,
CD stuff to like update your reports on data pane.com. Yeah. So pretty cool. Like you said,
there's a gallery. I'll link to the gallery at the end of the section. So these kinds of things,
you just want to poke around the gallery and get a sense before you mess with it. Right.
I like pictures. I do. We both like pictures. Now, before we go on to the next thing and we look at
the ways in which pickle might make you sour, let's really talk about things that won't make you sour.
Your pie test book. If people are interested in learning pie test, getting into testing and
not just scratching the surface, but really deeply understanding pie test, they can check out your
book, which we'll link to in the show notes. And if they would like to take some courses,
we have a whole bunch of courses over at Talk Python. We're almost up to 200 hours of courses over there.
That's a lot. Nice. It is a lot. But like I've said before, one of the things I like about it is
you don't have to spend hours at a time. You can spend a few minutes and not lose your place.
It's a nice way to set it up. Yeah. Thanks. On the pie test site, I wanted to reach out to people.
I'm pretty available on Twitter or through the contact form on Talk Python, not Talk Python,
Python bytes. However, I've had people try to email me at the contact form on Talk Python and Michael
just send it to me nicely. So anyway, I want to like have people know, I'd like to know people,
people, if they, if they want to learn how to test more, whether or not they've read the pie test book,
what's stopping you? I don't know how to get in people's heads of why are they not testing more?
So please reach out to me and let me know your questions. That'd be awesome.
Yeah, absolutely. Now you want to make me sour?
I love pickles. Do you like pickles?
I'm coming around to them. I've used to really not like pickles, but I'm okay.
Okay. I have a really fun pickle story to tell you, but it's like 10 minutes. It's better.
Next time. But let's talk about Python's pickle. I kind of like it sometimes.
No, it's one of the first things I learned about for saving data and stuff with is you can pickle
stuff. So if you got whatever object, a bunch of objects or whatever in a collection,
you can use pickle to serialize it somewhere. I think we've brought it up here on this podcast,
but you will occasionally run into people saying, just be careful with pickle or never use pickle or
something. And Ned Batchelder put together a post called pickles nine flaws where he says,
it's not never use it, but you know, use pickle if you're okay with these flaws. So,
and I like this list because I've heard some of these before, but never in one place.
First off, it's insecure. So unless you really, I mean, if you're only pickling and unpickling your
own data within your own program, and there's not a chance of having somebody else feed you bad
pickles, then you're okay, but it's not secure. There's ways to have them and have malicious
pickles be generated that can cause the unpickler to run random code, which is not what you want.
And then he links to a more thorough article on the security. If you're worried about that old pickles,
second one is old pickles look like old code. And the gist of it is, is it's, you can't really
version this stuff. So if you change the way your objects look, your pickles aren't going to,
it's not going to work right. Change your data structure and you got to pretty much throw all
data away and start. Yeah. This one is really tricky because it takes the entire object graph.
You say like, here, save this list. This list contains these things. These things contain
pointers. So there's other things, it's going to save all of that stuff. And if the code that defines
the fields of that change, I have your rename a field and you try to load it, you're done.
It's not going to be able, it's like this blind binary blob that doesn't fit together anymore.
There's not like a, well, let me adjust for this. It's just like, nope, nope. You can't no longer
load that file. So it depends, but not being able to load your file at all or open it in a text editor,
even that might be a bad place. Basically, if you're trying to save code between versions or save stuff
between versions, it's not a good thing. There may be cases where you're just using it to serialize
between a live app, a running application. And you're, you're not going to save that data anywhere.
I think there was an interesting problem. I think it was Instagram that had this problem. Somebody
that had done a big talk at PyCon, they were doing caching and something like Redis or something. And
they were putting their pickles, they would pickle stuff, put it in the cache and they pull it out.
And then they switched from like two to three and they could no longer read their cache. And it like
took down the system or something. Yeah. Like something really, even really weird like that,
like deploying a new version of the site. Yeah. Yeah. I'll read through the whole list. We can pick
out a few. They're implicit. So it serializes everything, even if you don't want it to.
Oh, that's the over serializes. The implicit part is it serializes things as class objects.
And even if that's not really what you'd want, like his example is date time, you really wouldn't want
to serialize it as a date time object. You'd want to serialize it as a string or something.
The init isn't called. So normally your classes, the init gets called, but during unpickling,
it just creates this object without calling init. So if there's any side effects that you need to have
happen, that ain't going to happen. It's Python only. You can't convert it between different languages.
It's unreadable. You mentioned it's binary. So if anything goes wrong, good luck with debugging it.
It appears to pickle your code, but it really doesn't. So if you've got a list of functions and classes
and objects, those will be in there, but it's just names of stuff. And then when,
when you unpickle it, it creates those objects without calling init, it's slow. And so the binary
part gets me, but basically these are all the things that are wrong with it, but there's some
ways to get around it. And a lot of people will say, well, there's ways to get around it. And,
Ned's comment is if you're going through some of the code to work around the problems with pickle,
then just why are you using pickle? There's other things out there. And my favorite alternative is
just Jason. So Jason mostly works most of the time and you can read it. So you can look at what's wrong
and go, Oh, I see why that didn't work because I was putting this garbage in there or whatever,
or I haven't tried these others. So there's a other suggestions like marshmallow,
catters, protocol buffers. I haven't used those before, but the, what was I going to bring up?
You brought up something about being binary and that's one of the parts that gets me as a
serializer that goes to binary. That makes sense if it's really fast, but using a slow serializer to
slow and binary. Come on. Yeah. One of the things that the over serializing that I found is interesting is
caching is something we do for like a long, hard computations or something, or just to save some
computation, you cache the result, that stuff will get saved in your pickle also. And that's
surprising. So it's just weird. Yeah. So thanks Ned. Yeah. It's a cool article. You know, the one
place that pickle kind of makes sense to me is if I'm doing like a really quick prototype and what I
would need to save would be fairly complicated. I'm just like, you know what? I just want to save this.
And if I really invest and I like what we built here, we're going to go and rewrite this with a
proper serialization data saving story. Yeah. I could see that. I, all right, just pickle it. Now I
don't really often do that, that off a very light, you know, it's not very common, but I would certainly
consider like, I just need to save this complicated data structure and I don't want really know if I
even need this forever, but I'm just going to do it for now. I might consider pickling, but in general,
it's not super awesome. And also the malicious bits makes you, you know, you got to be careful.
So the reason why you can't grab Jason right away is because there's some objects that are
not serializable, right? Yes, exactly. And some things that are simple, like date times, like if
you had a really complicated, some structure that had like say date times or other objects in there,
you can't just dump the whole thing to Jason. Right. So if you, if you were just in a hurry,
you're like, I'm just really trying to spend 30 minutes to figure this out, but I just need to
save this and then load it. And like, then maybe pickling makes sense. But the fact that you,
you could never be, it's very possible you upgrade Python, you can never load it again
or things like that. You can't look at it. Like that makes me never want to invest in this as like a
long-term option. Yeah. The other thing I thought might be a reasonable thing is, I'd like to hear
other people's thoughts on what reasonable uses for pickle are, but like, in memory stuff. So you're,
you're serializing it just to get it from one part of your system to another or something.
yeah. Yeah. Yeah. Like a super deep copy sort of thing might make sense potentially. Right.
yeah. Speaking of it might change because you get a new version of Python that is now going to be more
common. Yeah. Yeah. So Lucas Lenga, he's been in charge of releasing a release management of Python
recently and he has gotten Pep 602 accepted and Pep 602 says we're switching from a 17 to 18 month
release cycle to a yearly release cycle. Yay. That makes sense. Yeah. Remember we were talking
about something that got into Python three nine and we were looking at the conversation
on the dev channel and it was like, I really, really tried. I submitted this before the deadline,
but you guys weren't able to like review the PR before the window closed for three eight. So because
of that, like that feature missed by a couple of weeks and it was a year and a half before it could
actually get accepted. Right. It was like really long. So on one hand, this, this is to shorten that
cycle. The other thing is on a given year, when will Python come out? I don't know. Is it an even year
or an odd year? Like that's just a weird way to think of things, right? We have conferences yearly
in theory, things like that. Right. But for Python, it had been on this 18 month sort of alternating cycle
this way they can schedule it. So that things like the feature freeze or beta stage happens right after
PyCon. So the sprints can always focus on getting that last bit into CPython at PyCon and what, and it's
much more predictable. So I think that'll be nice. Yeah. And there's other stuff in life like,
you know, holidays and things like that, that you can just sort of figure out when a good time is for
the whole schedule and then just do that every year. Absolutely. Absolutely. So let's see. There's a
little bit of interesting detail. It says the PEP proposes that Python 3.whatever be developed around,
I think it's a seven over 17 months across a 17 month period, which doesn't sound annual, does it?
No. So the way it works is the first five months will overlap with the previous versions beta period.
And then there's seven months spent on the alpha release and then three months on beta releases.
And then finally two months on release candidates. So there's the way it's going to work instead of like,
we're now on 3.8. Now we're all focusing on 3.9 that 3.8 is out. There's like an overlap. So
basically as soon as the features freeze on the previous, on the what's coming out, right? So
like right now 3.9 is coming out. So as soon as it hit feature freeze, 3.10 would start, right? So
there's like this overlap as the version that's coming out is getting stabilized and finalized new
features and developments already happening on the other one. And the way with that overlap working,
it's going to result in a new version every 12 months. There'll be like a five month period of where
there's like new features go to the new one and stabilization to the old one. And this is kind
of how commercial software is done anyway. Yeah. Yeah. You never like, no one touches the new one
until we've like shifted the gold version. Like now, like some people are fixing stuff that they need
to fix. And some people are putting the new features. So in terms of advantages, they call out,
makes the releases smaller. So doubling the cadence doesn't double their available development
resources and so on. And consecutive releases are going to be smaller in terms of features. So that's good.
It puts features and bug fixes in the hands of users sooner, right? Six months sooner. It creates
a more gradual upgrade path, right? Instead of adopting 18 months at a time, you can adopt 12 months
at a time. Like you could be, if you're saying like, we're always going to be one version back of what
just got released on the Python, right? So if you're saying we're going to run on three, seven in today's
world, right? That's not an 18 month gap. That's a 12 month gap. So that's good. You're a little less
far behind if you're on the laggard side of things. The predictable calendar. So the final release is
always going to be in October after the annual core sprint. And the beta phase always starts in May.
So after the PyCon US sprint. So there's like a nice lineup for that as well.
Also, my prediction is that people won't be doing the two version thing. They'll actually do three.
Yeah.
I recommend everybody do this anyway. So let's say like right now, if you've got a project on Python,
you should make sure that it works on three, seven and three, eight, of course, but also three,
nine's around. So tested on three, nine also. And then when, when three, nine is the official one,
maybe you keep three, seven, but if you don't want to, you're at least doing,
making sure you're compatible with the next one, the current one and the last one. So
it'll make more sense.
Absolutely. Very good. Now we spent a lot of last episode on Git, right?
Yeah. Well, episode 187, we talked about, Oh Shit, Git from a zine from Julie Evans. And I,
I mentioned that I was concerned about, I wanted to buy this for my team, but I was,
I didn't know if HR would like the naming of it. And John Place reached out, one of our listeners and
said, you know, there's a non-swearing version. He actually sent us a ton of great Git information.
So the same little magazine, you can get it as Dang It, Git.
Ah, shucks, Git.
God darn it, Git. All of those would be good, but it's Dang It, Git. And then also when I was
looking around these, there's also, these were zines that you can buy, but these were inspired by two
websites that were put together by Katie Siler Miller, DangItGit.com and OhShitGit.com are,
there's actually really cool. These are free websites that have kind of the idea of something
went wrong. How do I fix it? And then every single one of the topics is clickable and linkable. And I
didn't understand the clicks at first. I'm like, Oh, these are links. Do they go to articles?
Oh, it just takes me right to where I already was. I don't understand this. Why would I do this?
Well, it's so that they're anchors so that you can click on it and get the URL and send it to
somebody. So if somebody asks you a question and the answer's here, you can send them the link and
say, here's how to fix it. And then next time they can fix it themselves. So these are neat things in
the community. And then also this, okay. Do you see the link for Git cheat sheet? Have you looked at
this yet? I'm looking at it now. I thought this was going to be a Git PDF, like a PDF or something
with a bunch of commands, but this is an incredible resource. The Git cheat sheet is an interactive
single page website. That's just beautiful to look at for one, but it's got five columns. I'm going to
pull it up. Also, it's got five columns, the stash workplace index, local repository, and upstream
repository. And you just, when you hover over it or click on the different columns, it shows you all
of the different Git commands that affect that. So if you click on the local repo, for instance, it'll
show you how to get information from, you know, diff, how do you compare between the workspace and the
local repo, what reset does, switch, rebase, cherry picking, and all sorts of stuff. And then different
commands that go between the index and the local repo and the local repo and the upstream one with
pushes and stuff. But it has this nice visual of where your stuff is and how do you get it back and
forth. And then you hover over, if you hover over any of the commands, it shows you the information on
the bottom. This is just great. I'm going to share, I'm going to share this with my team for everybody
that's kind of, because one of the things that, that takes a while to get your head around with Git is
this idea of what is the workspace and the index and the local repo and stuff. So having a visual
of what commands affect which part of Git, it's pretty, pretty darn cool.
Yeah.
The last thing I wanted to share was, this is a one pager that you could print out. It's a Git
pretty that is kind of like the dang it kid and oh shit get offerings, where it's a single page PNG
flow chart that starts with, so you have a mess on your hands. And then it asks you a bunch of
questions of funneling it to like what commands might fix it. And I don't know if I use this much,
but I totally want to print this out and put it on my cubicle wall because it's kind of entertaining.
Yeah, this is really cool. I like it.
More Git resources.
These are a bunch of great, yeah, a lot of, a lot of bunch of Git resources. All right,
I'm going to close this, our main items out, Brian, with a simple one. Okay.
Okay.
So there's a new PEP around strip, basically. That's the short version before I tell you the
long version. Okay. So if I have a string and the string is Saturday is the first, like so Saturday
is the number one ST. And suppose for whatever reason, I'm not sure it's a really normal use case,
but for whatever reason, I want to get the ST off of the end here. And so I might say dot strip ST.
What comes out of there?
Yeah, that's interesting.
So what I thought was when I first encountered the strip function, I would pass it a string and that
string would be taken away from the string that I was stripping it from. So like, if I say dot strip ST,
it's going to take the ST off the end. But what it really means is take away all the S's and take
away all the T's until you hit something else. So it would be Saturday is the one, right? It would take
the S off the front, even though it's not ST, it's just S, right? Yeah. Yeah. I mean, I guess the idea
is you give it a space, a tab and a backslash in and a backslash R and you say, take that away.
And that destroys the white space, right? That's probably the foundation, right? But you give it
a string, it doesn't take the string away. It turns it into a bunch of characters and it just takes the
characters away. But what if you wanted to take away the ST? Well, you've got to write a bunch of code
that goes and finds the ST and sees if it's at the end and then take it away. Or you wait a little
while and use a new function that's going to be in 3.9 called remove prefix or remove suffix. So
Dennis Sweeney has got a PEP accepted to add these two functions that are actually probably what you
first thought that strip would do. Given a string, it's going to take it that string off of the ends.
Okay. Not a big deal, but I suspect that there's probably people out there that type
more than one character into strip and expect it to be treated as a substring when it's not. And so
there's going to be in 3.9 two functions that do that.
Yeah. I mean, I totally, because I get the need to have like a set of things. If you want to pass
it in like a space and a tab and a new line, there's a bunch of things you want to strip off the end.
Well, there's easier ways to strip the white space, but like, let's say there's other like random
stuff that might appear at the end. Yeah. Stripping that, but having it be character. I was totally surprised by that. I didn't believe you. I just typed it in because I'm like, well, what about the S and is, but no, it just, the strip takes those. It's a set of characters that are only at the end.
Yeah. It takes the S off Saturday and the ST off of first, but it leaves the other ones alone. Yeah. Yeah. Yeah. So replace doesn't, there's not, there was not really a great way in Python to do that without writing your own function that checks that those are only on the ends and then takes them away. And so now remove prefix and remove suffix.
Nice. Cool. Nice. And just to finally, this will be applied to all the string like things in Python. So Unicode str, binary bytes, byte arrays, objects, and collections dot user string. So not just against str, but it takes all these other things that are string.
Oh, nice. Stringish. Is that a technical term?
That's, I think if we get the PEP accepted, it'll be technical. Yeah. Okay. No. Yeah. All right. So that's it for our main items. What else you got?
I've just been working a lot. So I got nothing. How about you?
Got nothing. Well, actually a couple of things going on. So Manning, the book publisher, they are going to have a Python conference in a couple of days. I'm pulling up really quick to see exactly what day that is.
I think, actually, I do know what day it is. I think it's the 17th. Okay. I think it's the 17th of July. Anyway, we're going to be there.
Yeah.
Not the 17th. It's the 14th. It's the 14th. The 14th of July. So we're going to be doing a live Python bytes at the Manning conference. And I'll put a link to it in the show notes so you guys can sign up. So you want to see us do a live event?
We've done that at PyCon. We've done that at some other events. And it'll be fun to do it virtually, which is basically all we get for our conferences, right?
By live, you mean like in real time, but like online?
Right. With audience questions and stuff like that.
Oh, okay.
So that'll be fun. Also, I did a talk on 10 techniques for web developers with a little bit of a focus on Pyramid, but more generally just for web developers, tips and tricks and tools and whatnot at the Python virtual conference.
That was last month. Well, maybe the big, yeah, last month for sure in June. So the recording for that is out and I'll put a link to that as well.
We also have a humble bundle running right now. It's probably when this episode comes out, got another week or so. So there we've got a couple of courses for me, but tons of stuff, stuff from Matt Harrison and stuff from real Python and we've been learner and on and on great long list.
There's like $1,400 worth of Python content and get it for 25 bucks. So that's going like crazy right now.
So if you're thinking about maybe taking one of the courses for either for me or one of these other guys, check it out. It's pretty much as good of a deal as you're going to get on those.
And then lastly, lastly, I'll be sick.
Pednecker. Hopefully I got your name close to right there.
Actually built something really cool for us. So at Python by side of him and talk Python dot FM, we have a search API and click on the little search box in the top right.
And there's like a link to a JSON API you can use. So he did, of course, what you should do when you find an API and use it.
He wrote two Telegram bots and you can just speak to the Telegram bot and you can either install the talk Python one or the Python bytes Telegram bot.
If you just text or speak to it in Telegram, it'll search talk Python and give you relevant responses about stuff we've covered.
What? That's cool.
Isn't that cool? Yeah, it's super, super cool.
So I'll put the links to get those those Telegram bots for you if you want.
Nice. All right. You ready for a joke?
I am. All right. This one comes from Karen Chi.
I don't think she submitted it to us.
I think we just found it on Twitter, but here's a quick adaptation.
It's not exactly what she said. I expanded a little.
She did it on Twitter, so it had to fit within a couple of characters.
So it's a conversation.
And Brian, let's just have it together.
OK, OK.
Who do you want me to be?
Oh, I'll be you.
No, I'll be me.
Wait.
OK.
Yeah. I'll start off. How's that? Because it's very confusing the way I phrase that.
All right. Hey, a famous engineer inventor is coming over tonight for dinner. You want to join us?
Sure. Who is it?
Oh, his name is Rube Goldberg.
That name rings a bell, which sets off a trap under the that undoes a buckle and releases a ball that rolls down a pipe.
And yeah.
And on and on and on and on and on and on.
All right. Well, that's it. Rube Goldberg. I love those things.
I should probably go check the Internet for some really funny ones.
And with all the coronavirus stuff, there's actually some awesome Rube Goldbergs that people are putting together on YouTube lately because people are at home and they have lots of time on their hands and their kids are home.
Absolutely. Absolutely. All right. Well, I'm definitely going to go check YouTube now.
Okay. Bye.
All right. See you, Brian. Thanks.
Follow the show on Twitter via 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.
On behalf of myself and Brian Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.