Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 188, recorded June 24th, 2020. I'm Brian Okken.
And I'm Michael Kennedy.
And this episode is brought to you by us, Talk Python Training and Brian's fabulous pytest book.
Brian, can you believe 188 contiguous episodes?
I cannot. The number keeps going up. I guess that's what numbers do.
I guess so. It's awesome. I'm glad we're still doing it. It's fun.
What you got for us to start with?
Well, you may have heard me talk about async. And actually, I didn't cover it on purpose.
There's sort of a controversial async article going around. Don't really want to talk about it at the moment, unless I have to.
But I do want to talk about my favorite async thing, which is unsync. U-N-S-Y-N-C. Unsync.
Okay.
I feel like the Python core developers should look at this and say, you know what?
We massively overcomplicated all the asynchronous parallel capabilities of Python.
Let's create a unifying API that is the one simple way that you can do things.
And if you need to dig into the details of the other ones, that would be great.
They haven't done that yet.
I mean, async it away.
The keywords are great.
But if you want to, say, work with like a thread and some asyncio thing, the way you do it is like totally destroy and unrelated.
So this unsync library is like a unification library on top of threading, multiprocessing, and async and await.
So I've talked about that a bunch of times, and it's sweet.
I'd love to see Python just adopt something very similar to that API internally.
Anyway, there's a cool article called Making a Trading Bot Asynchronous Using Python's Unsync Library by Matt Godston.
Oh, nice.
Yeah, it's cool.
It just walks you through a somewhat realistic example of creating something that does freighting.
And in order to do it, it has to go and, you know, it talks to different web services and some databases and whatnot.
Now, all these are simulated with a function call to a time.sleep call, right?
One of the things you'll see a lot of people when they do like these performance analyses and stuff is they'll have some async code and it's hitting up against some other thing.
And that other thing has a performance limit that is like near what it can handle anyway.
And so you can't get a big boost out of it.
So this kind of like puts that to the side and says like we're not going to actually talk to another thing because maybe that thing is slower than we can handle or who knows.
We're just going to go and simulate slowness by sleeping, right?
So it actually walks you through some different ways of doing things.
It has a synchronous version and the async and await version using unsync.
I don't know if there's intermediate.
I can't remember if there's intermediate versions in this tutorial about having just a pure threaded version, right?
But it's mostly about taking the synchronous version and making it unsync.
So it's nice because it's a somewhat realistic example.
It's not as much of a realistic example as some of the scenarios.
It's not as ideal of an example as some of the other scenarios.
Like for example, if I need to web scrape a hundred different websites, right?
You can do that a hundred times faster by just like kicking them all off and getting it back and not really waiting because all the work is happening distributed elsewhere.
But it's still a pretty realistic example doing some different things.
It would be fun to hear it talk about scalability more like how much it's like we've got a couple.
I think it's doing three things.
It's like, look, we could do these three things quicker.
But, you know, like what is the limit?
Like how far can you push it?
Because I think you could push it quite far actually with what they're doing.
It's just hard to know when if sleeps are representative as well.
Yeah.
It is hard to know if like a sleep is representative.
Basically, if it's like a truly external system that has infinite scale, right?
Some cloud service, then a sleep is probably pretty representative.
Like whatever you're doing is not going to affect it.
But if it's say like a database, right?
If I'm doing 10 requests against the database versus one, maybe the database can't handle it.
And it slows down to what like two or three queries at a time would be like.
There's things like that, right?
Where it hits a limit.
But if the thing you're talking to totally scales and sometimes it does, sometimes it doesn't.
One thing that I think is missing from this is it doesn't actually use async methods.
It just has regular methods.
So this is really an interesting thing, right?
So it's like, okay, we're going to put unsync on it.
Here's some regular functions and we put the unsync decorator, which turns them into these things that are awaitable and parallel and so on.
And what you really probably want to do is actually leverage async and await, create, you know, def async methods, use, you know, await asyncio sleep and all that kind of stuff.
So it didn't actually fully transition them to leveraging asyncio.
But what I think is interesting about that is it still got much better with unsync.
And what's cool is like it said, okay, well, these are not async methods.
So we're going to have to use threads, but let's just fire them off with threads anyway.
And because the time.sync releases the gill, just like a network call would, it still kind of works.
So it's kind of neat that like it wasn't fully converted over, but unsync still made it better in the same way that you would expect.
Interesting.
Yeah.
So anyway, a cool example of someone talking about unsync was not me.
Except for right now, reviewing it.
There's a lot of cool stuff in there, kind of like a fruit salad, would you say?
Yeah.
Just a lot of stuff to take and it's sweet and people generally enjoy it.
Oh man, I shouldn't have picked this story right before lunch also, because I'm kind of hungry.
I know.
It's good.
So tell us about this.
I was going to put this as an extra thing, but I put it as one of my topics because it's actually pretty darn cool.
So this, on Twitter, Lacey Henschel just asked the question of like, there was this scrum estimation tool with fruit.
Does anybody remember it?
And Kathleen Jones replied and said, is this it?
Essentially.
And it was.
And so we're linking to this article.
It's called the Fruit Salad Scrum Estimation Scale.
And, you know, task planning and scrum estimation is a, you know, it's a kind of an art form and a science together.
It takes a while to get things right.
So maybe just really, really super quickly tell people, what is this scrum estimation about?
Oh, okay.
Maybe scientists and they're like, we don't do that in our biology lab.
Oh, that's true.
Lots of teams have picked up scrum or sort of a variant of scrum, which is a way to plan what tasks, what things that people are going to work on.
And the things that people work on, we kind of want to, you know, have a, like a size for them.
And instead of doing like, oh, it's a one day task or a two day task or a five day task, or some people just use small, medium, large.
T-shirt sizes are popular.
And then also, for some reason, just points are very popular.
And the point system is often a Fibonacci sequence, which, but it's not really, it's just kind of Fibonacci.
So I can't remember the numbers right off the top of my head.
I think they're like one, two, three.
We usually skip three.
So one, two, either four or five and like eight sometimes.
And then like 13 and 40.
So it isn't really quite fit normal Fibonacci, but I think that's where people took it from.
So we've been using them at work as well lately, but the numbers, it's kind of like t-shirt sizes, but I don't know.
None of these things really fit.
But the fruit salad estimation scale actually kind of fits.
So they've mapped one, two, three, five, and eight to grape, apple, cherry, pineapple, and watermelon.
And I like these ideas because they're kind of like how easy they are to cut up something and how easy they are to eat them.
So like a grape is trivial.
You know, you just pop it in your mouth.
It's no big deal.
You don't even have to cut it up for a fruit salad.
Although I usually do.
An apple.
Everybody knows how to cut up an apple, but it's a little more food.
So it takes a little bit more and it might take some more time.
A cherry.
It's also easy, but there's some unknowns in it because of the pit.
And a pineapple.
Yeah, you can't just eat that.
You've got to actually put some work into it.
Some people don't know how to cut it up and it's a little messy.
You're going to have to get your hands dirty for that one.
And a watermelon.
All bets are off.
Nobody knows.
You don't know what you're getting into until you cut open the watermelon.
So I like that as the large size.
There's more description on this article.
And then they throw in some nice ones.
Tomato and avocado.
Tomato and avocado do not map to points.
But tomato is unknown.
I mean, are you a fruit or are you not?
And you need more information before you can estimate it.
And it really doesn't belong in the fruit salad until you change it into something else.
And then one of my favorites is avocado.
That's something that you just get.
You can't really scope it very well.
And it's probably urgent because it'll go bad quickly.
These are great.
I like this concept of thinking about them here.
Yeah.
So I think that somebody needs to put these fruits in an official product.
That would be cool.
You know, another one that comes to mind here is a mango.
Yeah.
You know, those are tricky because I like to cut them like in the orientation of the husk
or whatever the thing in the middle is, the giant seed.
But you got to hack into it a little bit before you can even figure out what that is.
So you kind of start out unknown and it's slippery.
You may hurt yourself on it.
But it's really, I don't know, it's a high value once you get it out of there.
I don't know.
Mango.
And sometimes you can't tell until you get into the mango if it's even good or not.
Exactly.
Yeah.
I think mango is in this category somewhere.
But this is a really cool idea of thinking about it because it's super hard to be very
accurate when you're estimating stuff.
And what I like about this is it just brings that together in a pretty clear way, right?
They're not like, well, how many hours is it going to take?
It's going to take three or four hours.
Like, no, no, no.
We're not talking.
Like, I can't possibly give you that answer.
It's like, all right, fine.
It's four hours plus or minus 16 hours.
Yeah.
And then that kind of stuff.
If you do points, people always have like some conversion to hours anyway, and it's annoying.
I think it'd be cool to if somebody said, you know, I got a manager or somebody saying, hey,
hey, how many, how much time we have left?
And be like, well, we have three grapes and a cherry left to do.
Yeah.
Just don't talk about it by lunchtime.
Anyway, I am hungry now.
So, instead of doing another topic, we should just talk about how awesome we are.
How awesome your training courses are.
Thanks.
Well, so this episode is brought to you by us, and we both are doing stuff we would love for
you to check out.
So, over at Talk By The Line Training, we have a bunch of courses.
I think we're up, probably by the time that this goes out, we're up to almost 200 hours
of courses and a couple hundred hours of exercises.
So, lots of stuff to be learned over there.
But I want to call out, if you have a company and your company has a training budget or a
training plan, you know, reach out to us.
We have special deals and offers and pilot programs to help get our courses started at
your company.
So, shoot me a message over at Michael at talkpython.fm, or just check us out over
there.
And if they're writing code, they should test it, right?
Definitely should test it.
And tell everybody, the Python testing with pytest is the best way to get started with testing
with Python.
And even though it's like 180 pages, the first two or three chapters will get you up
and running like in a day, less than a day.
So, you can get started right away and then you just get faster and more awesome as you
go along.
Indeed.
I take advantage of all those features and pytests that people might not know about.
Yep.
So, you know, one thing I think people come into programming often feel like if they're
going to be programmers, they have to be good at math.
Like, oh, I was really good at calculus, so I'd be a good programmer.
Or I never actually got algebra very well, so I'd probably be able to be a good programmer.
And I think that connection is often very much not true.
Like, I don't do math other than like basic arithmetic in my programming these days.
But some people do, right?
Some people come as engineers or they come as scientists and they actually do math frequently
and they want to do it with Python.
So, Vernon Thamaret sent over this cool project called Math to Code.
Have you seen this?
Yeah.
I was checking this out the other day.
It's pretty fun.
Yeah.
So, imagine you wanted to learn something by doing flashcards.
Right?
I'm going to show myself.
I'm going to flip through them and like see like a simple thing and then what the answer
to that is.
And this is kind of like that.
Like it starts out and says, what I want you to do is take the square root of something
using NumPy.
And it's all based on NumPy or just pure Python.
Like raise something to the power.
It's just X star star Y, for example.
But it just really quickly and simply takes you through that.
So, you type out the answer, hit enter.
It's all hotkey driven, which is great for a web app.
And it just kind of guides you through like practice experience of here's a math problem.
Solve it.
NumPy.
Yeah.
And it's so beautiful.
It is pretty, right?
Yeah.
Cool.
Yeah.
I honestly haven't made it to the end.
So, I don't know how many answers or questions or whatever there are or flashcards as I'm calling
them.
But it is open source on GitHub, which is pretty cool.
So, you can go in there and, you know, check out the source code and play with it.
And yeah, it looks like 13 questions, but it's on GitHub and the questions are just marked
down.
So, you could go add as many as you would like.
Actually, that's pretty cool.
Yeah.
But what also is interesting, just at a more higher metal level, maybe you don't care about
finding, you know, the square root of something in Python, is the building blocks.
So, if you look at how this thing is built, and like I said, open source on GitHub, you
can check it out.
It's built running Python on the client side.
What?
Really?
Yeah.
So, it's built using Sculpt, which is a JavaScript implementation of Python.
And then it has Sculpt NumPy for the subset of NumPy running on a client side that it wants
you to experiment with, right?
Like NumPy.square root, for example, or MPs.square root.
It has KTX for rendering LaTeX on the browser side.
It has Next.js for front-end, Tailwind CSS, which my friend Mark just told me about, which
is a really interesting alternative way to like CSS front-end frameworks.
I like Bootstrap, but different Remark from Markdown on the client side, Gray Matter, all
sorts of stuff.
So, there's a lot of cool building blocks here, regardless of whether or not you're actually
into the questions.
Yeah, this is awesome.
That might be more interesting, actually, than the thing, right?
Because I honestly don't care about learning the math features generally.
It's nice, but it's just not as it might do.
Yeah, but this sort of model of like have a, I mean, if you look at it, I don't know if
you already said this, but if you look at it, you've got like some explanation and a question
on the left, a place to type in and submit your answer on the right, and then there's even
a place where you can like set up a hint and show the answer or a hint for somebody.
And having all this just, it looks very nice, and having like this as an example for somebody
else.
I could totally see like a teacher running with this to help their students learn really
pretty much anything.
Yeah, it doesn't have to be exactly Python, as long as you can verify it with Python.
Yeah, cool.
Yeah, yeah.
Tell us about the PEP.
There's always a PEP to be discussed.
I've learned about a couple of new PEPs in the 3.9 time frame.
Right, so this is the 3.10 time frame.
So, where everybody should be using 3.8 now, and you should be testing 3.9, especially if you
have a package that depends on, that people depend on, so that when 3.9 is then official,
it'll all work.
But people are already working on 3.10, of course, and one of the PEPs for 3.10 is PEP 6.22,
and it's not official yet.
It's in draft status, but there's some cool people working on it, including Guido, and I
think it's super cool.
Have you taken a look at this?
I have taken a look at it.
It starts out to me feeling like a switch statement.
Yeah.
But there's a lot more going on here.
It's called structural pattern matching.
And right off the bat, they note that there have been previous PEPs before that have tried
to put switch case statements in Python, and they've been rejected.
I don't know why they were rejected.
It's kind of something I didn't pay attention to.
But this, yes, instead of a switch case, it's a match case statement and a multiple statements.
But the neat thing is there's all these different...
So when we think of like a switch case statement in like from C, it matches by equality or value.
You switch on some variable name or some expression.
And if the answer matches one of the case statements, then you run that part of the code.
So that would be in the PEP 622 world, that sort of a use model would be like the literal pattern or the constant value pattern, basically with equality and stuff.
But it does more than that.
You've got name patterns so that if you just have a whatever, if these will always...
If nothing else succeeds prior to it, you can just have a variable name and it just assigns whatever you're passing in to that name and you can use it there.
My first thought was, what's the big deal?
You already have the variable name or the value.
But this new value in the name pattern is only available in that.
It isn't assigned otherwise if that didn't get hit.
So that's kind of some useful, neat things.
Constant pattern is kind of the same, but then it gets interesting.
So I think it'd be worth it just for that.
But you've got sequence patterns where you can do...
It works like unpacking assignment stuff.
You've got mapping patterns that are like similar to sequences, but for like dictionaries.
And class patterns where you can have like a custom class or a class that it might be and you have a match object.
It's similar to equality, but you could have...
It could be different than equality.
And then you can combine them with ores so you can match cases if multiple things are true, like a boolean expression in there.
I don't think it's a full boolean expression, but at least ores work for pipes.
Guards.
So you can say if this pattern matches and then have an extra if expression so you can clarify it even more.
And then even sub patterns.
And at that point, I kind of got lost.
So just there's a lot here.
I don't think it's going to clutter Python up.
Actually, I've seen some examples of how this would dramatically simplify some Python.
Yeah, it's interesting.
What's surprising to me is how many types of things it's trying to do at once, right?
Like it's not just like, oh, let's have a switch statement with like a slight variation.
Like it's...
There's a ton of stuff going on, including things like if you switch on an enumeration, you can just say dot attribute and it'll try to like pull that attribute out of that type and check it.
And yeah, it's pretty interesting.
One thing that's missing here that I would love to see is range matching.
Right.
So I could say it's in the range of zero to 10.
Match this case.
If it's a range of 11 to 100, do this other thing.
Actually, so I have my package, the switch link package, which adds switch to Python and it has those types of things.
So I actually sent that over to one of the people working on this PEP and said, hey, this is really cool.
You know, check out some of the ideas from this one, like especially the range matching and see if it makes sense here.
Because it's so common that you would want to say like this range is this case, that range is that case and so on.
And we even talked about a package a while ago.
I can't remember exactly what it was called, which is unfortunate.
We've covered too many things.
But it was basically you could give a like a number or a value and then this range and you could ask, is this thing in that range in some real simple ways?
So it'd be cool if like that was all combined.
You might be able to do it with the if guard though.
So you could say like, you know, match X if X is within, you know, in this range.
Yep.
It's true.
Yeah, we'll see.
I mean, at that point, like if you're writing a lot of complicated if statements, you might as well just write if statements.
Right.
Yeah.
Although, I mean, it's just always, I don't like it when I see like these, the if else ladders.
So I think that this is more than, of course, more than just replacing the if else ladders.
It's also doing things like unpacking and other sorts of cool stuff.
But you're right.
Yeah.
There's a lot going on here.
There is.
But it's cool to see innovation around this.
I do feel like that thing, that general idea is missing from Python.
I know people say you could just use a dictionary or stuff, but there's like a lot of cases where if else is buggy, hard to maintain, or like these other cases are very, you know, verbose and so on.
Anyway, I'm happy to see this, I think, depending on how it comes out.
It's very complicated, but the idea is good.
So one thing that we've talked about a lot, Brian, is how do you host your own private PyPI, right?
Pip install a thing, but I want to be able to pip install and version, like say you work at a large company, you probably have libraries, packages that you've shared across projects.
How do you like have the pip style package management, but for you?
Well, we've got a custom PyPI at work.
That's right.
And that's fine.
That's fine.
The more global you are, the harder it is to maybe do that well without people getting a hold of it.
Like, obviously you want to protect that code because that's internal private code, but at the same time you want to share and version it.
So there's all sorts of options that you can set up and take care of that.
But there's this new thing, which Tormod McLeod has said over our way, called Code Artifact from AWS.
Neat.
Yeah.
So the idea is it is a general purpose, basically package management system for a variety of things.
So right now it works with Java, with Maven and Gradle.
For JavaScript, it has NPM and Yarn.
And for Python, it has pip and Twine.
And basically you can just set it up in AWS and tell it to go.
And it'll take care of all the storage and the security and all that kind of stuff.
And then you can just pip install all the things.
And it also is backed by the real PyPI or the real NPM.
And you can whitelist stuff.
You say, okay, if somebody pip installs requests, just get the real requests and stay in sync with that, but let them have it.
But if they pip install the misspelled request, I think you can say don't let them have the typo squatting hacker version.
Yeah.
So these sorts of solutions are pretty interesting to be able to have basically a cache of PyPI stuff and then also your own stuff.
So you push to it just like often you publish it.
I don't know about this one, but often some of these you use Twine or something to push just like you normally would.
But it doesn't go to PyPI.
It goes to your own thing.
Yeah, it's pretty neat.
It reminds me of Artifactory, which people might have heard of, which looks really cool.
However, if you look at the pricing, it starts at just $2,900 a year for the base version.
The pro version is $14,000 and it goes up from there.
So, you know, this looks like one of those cases where one of these cloud services from places like AWS and so on is coming along and going, you know what?
We got you.
And it's not $14,000 a year or whatever or a month.
I don't know.
Whatever the unit was I said there per year.
Yeah.
I think to some degree, I believe GitHub is working on something like this as well.
I can't remember what it's called over GitHub, but it doesn't have Python yet, which is why I haven't jumped up and down about it.
But I think it will.
I think they're working on it.
Well, supposedly like warehouse was something you could just use that is used for, well, I guess they don't call it warehouse anymore.
PyPI.org, the new PyPI.
Yeah.
So, I think that you can deploy that yourself, but there's not, I haven't seen very many people like, well, one, I'd like to see people write instructions on really how to get that up and running for yourself.
And I'd also like to see some like, you know, warehouse as a service sorts of things.
I mean, why not?
Some free money laying on the table there, people.
Yeah, that's a good point.
That's right.
All right.
What's this last one?
I wanted to bring up Invoke.
And it's at, what, pyinvoke.org is where you can see the documentation for this.
And to tell you the truth, we've had it on our list for a while and I've tried several times and couldn't get it to work, but I had some confusion.
So, then my confusion was the product, when you install it, you install it with pip install invoke, not with the py part.
But there is a pyinvoke on PyPI, but it does something different.
So, the invoke that I'm talking about is invoke without the py in front, but the website is pyinvoke.org.
Okay.
If you're confused, I'm confused, but we've got it in the show notes.
But why do we care about this?
We care about it because it does make me feel, I like make files.
I think make files are fine.
There's parts of them I don't like.
Like, I don't like that the tab, like, it's the only thing in my life that I have to use tabs for because I usually use spaces in Python.
Make files have tabs.
And often things like cleaning out your, building your documentation or kicking off your tests or deploying or a lot of those other book maintenance things for a project you put into a make file.
And some people use talks for that, and you can.
But invoke is intended to do that sort of thing, but with Python code.
So, with invoke, you just create a little task.py file with these little types.
You just have little functions that you decorate with the at task decorator.
If you have it installed, you can just say on the command line invoke and then the name of the function.
So, if you have a build function, you can say invoke build, and you can pass in command flags to it.
And it's just pretty easy to run something.
So, something like you would use make files for, you can have it without any make files.
Yeah, that's cool.
And you get to write Python for your scripting, right, basically?
Yeah.
The project looks like, I'm not quite sure if this is recent or old.
It says that it was intended for building documentation, but it does look like there's some examples on how to combine it.
I don't see why you couldn't use it to run your tests and run all sorts of other stuff, too.
Because it's just, it's got things like you can run Python code, but you can also run command line.
It can launch a command line tools and all sorts of stuff.
Yeah, if you can run stuff off the command line, then you could do get pre-commit hook type stuff or all kinds of automation.
Or even cycle the version, increment the version numbers and all kinds of stuff you want to put together.
Oh, yeah.
That would be a good thing to put in there, version incrementing.
And then also just like things like deploying, like check linting, that's a good thing.
And then you can, so one of the neat things about make is different make targets can depend on each other.
And this one has dependencies as well.
You can have, like, for instance, build can depend on clean and it can have to run off and do a different target.
And you can make a whole mess of stuff in there.
Or you could keep it clean.
But I like things like this to have, I mean, one of the reasons I'm not even, I don't mind make files.
But people that are not from a Unix or don't come from a Unix background have no idea what to do with a make file.
Yeah.
It's good for the team to make it easy for them.
Yeah.
Yep.
Indeed.
All right.
That's pretty cool.
I like to use this.
And I just got to think of a reason, a use case for it.
And I will.
It looks great, though.
Well, that's all of our six items.
Actually, I've been, like, totally swamped at work.
I don't have a lot of extra things to share with people.
Do you have anything extra for us?
I have a mystery that we can discuss.
You have a mystery?
Yeah, apparently.
You just talked about Python 3.9, and it's in beta, which means it's getting no new features.
It's just getting tested and ironed out.
And there was Python 3.9, beta 1.
And then there, Hito announced, oh, hey, everybody, here's Python 3.9, 0.
Beta 3 is out for immediate testing.
And somebody disappeared beta 2.
So the problem, apparently, with beta 2 was somehow the way that it looked up certificates was busted.
So if you, like, installed it from source and just ran it, it would be fine.
But if you installed it from the installer, all of a sudden, every web request that went to HTTPS or something along those lines would fail.
So that's not good to break the networking subsystem of Python because a lot of things depend on that.
And so they quickly ditched that one and fixed it and rolled out beta 3.
Okay.
And just about the time that this is released, so on June 29th, we'll have beta 4, which presumably will still make web requests successfully.
It won't have to be disappeared.
So anyway, just some Python 3.9 news.
Beta 3 is out.
Beta 4 will be out days after this comes out.
Or actually, maybe even before.
So there is no beta 2.
Before will be after or before will be before?
Before will be before, I think.
But it might be after.
I'm not sure.
So I've got a joke for you I grabbed here off of Geek and Poke, which is like a cartoon strip.
Okay.
All right.
So it's a mom and a son.
And you have kids.
I'm sure you know how this goes.
How was your day?
Eh.
Good day?
Yeah.
What did you learn at school?
Not much.
You were there for eight hours, continuously getting instructed like you didn't learn more
than like half a cent.
Like, eh.
Yeah.
Right.
So, but if this child happens to be a geek, there's another ploy in which you can employ,
another technique you can employ to get them to tell you more about their day.
So it goes like this.
It says, hi, Darlene.
How was your school day?
And like sort of a blank stare.
Hi, Darlene.
How was your school day?
Dash, dash verbose.
Yeah.
I totally wish I had verbose flags on my kids sometimes.
Yeah.
Also, sometimes a dash Q, like a quiet one would be good sometimes too.
Yeah, exactly.
The dash, dash quiet.
If I got to pick one or the other, I'm going to go for the dash, dash quiet as an option.
Yeah.
Especially for young kids.
Yeah.
Exactly.
Daddy needs a little piece, dash, dash, quiet.
Yeah, definitely.
All right.
Well, that's it for the episode, I guess.
Yeah.
Thanks a lot again.
You bet.
See you later.
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 Okken.
And on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast with your
friends and colleagues.