Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 194, recorded August 5th, 2020.
I'm Brian Okken.
And I'm Michael Kennedy.
And this episode is brought to you by us, and we'll tell you more about what we're shilling later in the day.
I want to talk to you about mutants.
Mutants? Like mutant ninja turtle type things? Or what are we looking at here?
Sure, mutant ninja turtles.
No. So mutation testing.
So I really kind of, I think, I'm warming to mutation testing, and it's kind of a neat thing.
And I think we've covered it before, but this article is from Mosh Zadka, and it's called An Introduction to Mutation Testing in Python.
There are a few, a handful of, I think there's like two or three different mutation testing libraries.
MuttMutt is one of them, and that's what this article uses.
And so if people are not familiar with mutation testing, here's the problem.
So you can use code coverage tools like coverage.py to show how much of your code your tests are covering.
But even if you get to 100% coverage, it doesn't mean that you're really testing everything.
And so mutation testing, what it does is it takes your code under test, and it does some modifications.
So it modifies portions of your source code to simulate potential bugs.
Like, for example, it'll replace the greater than comparison with greater than equal, or replacing it with those sorts of edge cases and stuff are often where we muck up.
If there's no boundary test around the boundary condition, you know, there'll be a problem.
So every little change is considered a mutant.
And it generates all these different mutants, and it does it in a fairly smart way.
It can test your code fairly quickly with not too many mutants.
So, and then it runs your test suite on the mutant.
And the idea is your test suite should kill all of the mutants.
So in this article, he shows an example of three methods and one test case and 100% code coverage.
But he runs mutt-mutt, and 16 of them survive, and then talks about how to fix that.
So it's a really good, quick article.
Yeah, this is interesting.
And I like the emoji legend use for the output.
Yeah, it's a cute library.
Yeah, it is.
You know, one thing that I don't understand about mutation testing is, like, I understand, okay, well,
we're going to change, like, a value of a variable, or, like, the way if we're doing a test,
make it, it was less than, we're going to make it greater than, and see if your tests still pass,
and, like, those kind of things.
That totally seems reasonable.
But if it goes in, I don't know if it does, maybe, you know, if it goes and, like, says,
well, you're doing a print statement, so we changed part of the print string.
Like, who's testing for that, right?
Like, that seems like it would survive.
Yeah, I'm not sure.
So it seems like there's certain things, like, I would just never care to test for the output
of the print statement where the static string changes.
Like, to me, that just is not something I care to test, right?
Yeah.
But I feel like the sort of general case of mutation testing, you go, well, here's a piece of variable
that I need to change around.
Let's change a string and see if the tests still pass.
So, I don't know, maybe it's just inappropriate for those types of scenarios.
Maybe you only test stuff, like, at a lower level where you don't have, like, a bunch of print statements.
But, you know, you've got logging and all kinds of things.
So, I don't know.
But still, I do like the idea.
I think MutMut and some of the others have ways to specify which kinds of mutants to generate.
I see.
So, I don't know if it does the print statement sort of example, but I'm sure that there's ways
to say, yeah, I don't really care about.
Don't modify string values, for instance.
Yeah.
Like, don't modify constants or something, maybe.
Who knows?
Yeah.
Cool.
All right.
Well, you know, that looks really interesting.
And Masha does a great job writing up these types of things.
We feature him a lot.
Very cool.
Next up, I want to talk about asynchronous programming.
Oh, nice.
Yeah.
So, maybe we've covered this before.
No, we've covered this a lot, but I don't believe we've covered async Q.
I don't think so.
I don't think so either.
So, this is from Quora, and it is not brand new.
So, I just want to be really upfront.
Like, this has been around since 2016, but it's pretty interesting.
And the idea is, so much of what asynchronous programming, especially asyncio type of async
and await programming is about, is scaling while you're waiting.
Scaling the latencies, right?
Okay.
So, you know, like, I'm going to call the Stripe service, and it's going to take, you
know, half a second to return.
And so, I want my web server to be able to go and just do stuff.
You know, other requests instead of waiting for half a second while we're checking out
some person or whatever, right?
But they've got a different use case.
What they're doing is they're running, I don't know if I said this is from Quora.
They're running Quora.com, which is a really cool Q&A site.
I actually think Quora does a great job of having, like, solid, thoughtful answers.
Not always right, but thoughtful at least, which is pretty cool.
But what they do is they don't talk directly to their database because that would be too
slow.
Don't give me started on that.
But what they're doing is they're talking to Memcached or Redis or whatever, but they're
using Memcached to store a bunch of pre-computed query results so they don't have to keep going
back to the database.
Like, for example, when you go view a question, they want to see the names of the people who
upvoted the question, right?
So it's kind of a complicated query, right?
I need to go, here's the IDs.
We store the IDs of the upvoter.
Then we're going to do a query, a join over on the user table and get their names back.
And then we're going to show it.
Like, that sounds expensive for lots of data.
So what they do is they basically store those answers.
Like, this user goes to this thing in Memcached.
But a lot of the latency around this has to do actually with the network call.
Like, it's pretty close.
It's like, you know, one millisecond or something, but they've got to go get those
names over and over, right?
Because the way that you store stuff in Memcached is this ID has this name.
You've got 50 upvoters.
It's like, give me the name of this person, give me the name of that person.
So there's a way to do like a, you know, a batch get like, here's all these IDs.
Go get me all the associated names.
And they've got like this dependency tree of these sorts of questions they have to answer.
So what they've done is they've come up with this thing called AsyncQ.
And it's all about batching asynchronous requests and converting them from a bunch of individual
calls into like one massive call.
Oh, okay.
So they can like do what looks like asynchronous programming.
Say, go get me all these things.
And instead of doing a bunch of individual async and await type calls, the system looks that
goes, okay, what that means is turn that into one giant query where it's like all of these
IDs go to all those things and then return them back.
Oh, that's right.
Yeah.
It's pretty neat.
So it's basically this way to write code that will take a, what would be a bunch of small
independent requests and turn it into like a one shot request for talking to things like
caching servers and whatnot.
Yeah.
So apparently this is like a core component of core's architecture and yeah, it's all about
batching up these calls.
I didn't know core was Python on the backend.
Oh yeah.
Yeah.
They've got a really interesting Python blog where they, like an engineering blog where they
talk about all sorts of stuff.
So this was like written up on their engineering blog about sort of how they went from what they
were doing before this, which was, you'd have to like write several functions that would
prepare the things.
And then you could ask for it because they would be cached locally and all sorts of funky
stuff.
So there's a great writeup on sort of the whole use case of this.
So this, like I said, is from 2016.
So it predates async and await.
And so they use the yield keyword, which is a sort of a more foundational way to get, to
break up functions into parts that run.
So basically you decorate a function and then you yield out the various steps.
And then before it executes all those, it looks at them, figures out what it has to do.
And then it like batches it up and then does it all at once.
Pretty wild.
Yeah.
So I thought this was, you know, kind of interesting.
I think it's a little bit just looking at the patterns here.
I feel like it's a little tiny bit limited because it's targeted at, I believe they're still at
least then, right?
So when they came up with it and it's still active, I think they built it for running a
Python two, right?
Remember this 2016, they'd been running for a while.
So some of their APIs, I don't think like, for example, they don't use the async and await
keyword.
I think because that didn't exist.
Like they supported Python three, four where asyncio was, but async and await didn't come
along until just a tiny bit later.
I don't think so.
Anyway, a bit of a grain of salt, but I think, you know, this will be a pretty interesting thing
that people can adopt and use for these types of scenarios.
Certainly if it powers Quora, it's probably pretty good.
Yeah.
Neat.
Cool.
Absolutely.
Yep.
Another thing that's cool is Talk Python Training.
Thank you.
We got a lot of stuff going on over there.
Actually, we've got a ton of new courses coming.
course for people who generally live in Excel and should be adopting the Python data science
tools.
So that's coming really soon.
We've got a getting started with data science.
I just actually, last time we spoke, I said, hey, I'm writing this course.
I started writing a course called Python Memory Management.
I finished it.
I recorded it.
It's like a five hour course.
It's going to be awesome.
So now I'm on to writing a new course, Python design patterns.
Oh, nice.
Yeah.
So that'll be out in a few weeks as well.
How about you?
Yeah.
I just wanted to highlight again.
I have the URL pytestbook.com set up to go directly to Arata because I get a lot of people
asking, hey, your pytest book, is it still good for, it was like in 2017, still valid?
Yes, it's still valid.
But there's a few gotchas and I list them out.
Very easy to read at pytestbook.com.
It directs you to an Arata page to show you.
It's just a couple tweaks to the source code you got to make.
You got to pin TinyDB and a couple other things.
And we'll try to get those changes out to the download link on Pragmatic as soon as possible.
That's still in the works.
But there's also a link to, if you have any issues, there's a link to the official Pragmatic
Arata page where you can ask questions.
And if you haven't run into anything, I'd love to hear about it.
And I'm excited to get a lot.
Lately, a lot of the people that have been contacting me said they're excited about reading the book
are machine learning people.
So it's kind of neat to see data science and machine learning people add testing to their workflows.
That's exciting.
Absolutely.
So I have a final call to action for people out there.
If you want to make sure that we have the time and energy to keep creating stuff like this podcast and the other things we're doing,
you don't necessarily have to get our stuff, but how about recommending it, right?
If your company needs to get up to speed on Python, recommend that your company buy the courses for that team.
Or if a company is doing a bunch of testing, have everyone on that team or the engineering group get Brian's book.
That would be great.
Yeah, and then individually to remind people that we do have a Patreon campaign going.
So people can contribute a buck or two a month.
That would be great.
Yeah.
Now that we go anywhere, we don't buy coffee.
Yeah.
Next, I want to talk.
This sort of ties into your async thing.
Yeah, yeah, for sure.
That's interesting.
But they use Memcached.
But I wanted to talk about Redis.
So I've not used Redis myself, but I know that a lot of people do for caching and for other things.
And so this is an article.
It's actually on the Redis site, but it's an article called Redis Beyond the Cache in Python by Guy Royce, I think.
I knew that Redis did more than just a cache for a backend database.
But this is kind of neat.
So these are good, clear examples of Python code using Redis for more than just caching.
So the first example talks about how to use it as a queue.
So you can set it up as a fast queuing system.
And apparently there's a couple calls called rpush and blpop.
And actually, to tell you the truth, I picked this article because of blpop.
I think that's one of the best function names ever.
I don't know what it means, but maybe back of the list pop?
Not sure.
But it's good.
I thought you picked it because of the various, from the code example about putting stuff into queues here.
That felt close to home.
Did it?
Yeah.
It's about Bigfoot sightings.
We've got a sighting near the Columbia River and people were chased by a tall, hairy creature and so on.
Oh, yeah.
So like asynchronously adding Bigfoot sightings from the general Pacific Northwest.
Yeah, that's good.
Sorry, carry on.
Didn't mean to derail you.
No, no.
It's good.
So using it as a queue, using it in a PubSub model.
Apparently there's functions like publish and psubscribe.
So you can do publish and subscribe models.
Data streaming, using it as a search engine.
The search engine seems like a little more hardcore because it looks like they're, it's almost like SQL queries that you're using.
But apparently you can do that.
And of course, you can also use it as your primary in-memory database if you want to, as long as you don't need to store it somewhere.
So, or use some later thing.
You know, I guess I'm just winging it here.
I don't know how you get, how you hook up a Redis database to a normal database.
But I know you database people know how to do that.
But I probably use, I like the idea of using it as a queue system for like multi-threads and multi-processes.
That sounds kind of fun.
This is a really cool article because I just often think of Redis as cache, right?
But yeah, there's a bunch of neat stuff here.
And yeah.
So often you think like, oh, I'll just write this cool data structure.
We'll just do this thing.
And it's great.
And you're like, oh, wait, but hold on.
When I deploy that to the web server, it forks off like 10 copies of micro whiskey.
And so I'm going to have like 10 separate DB copies and all this, like, there's just certain
times you're like, I just need a thing to hold this stuff.
And like Redis seems pretty cool for that.
Yeah.
And the examples use, apparently there's a bunch of different Python libraries to access Redis.
And this one uses AIO Redis because there's async and await calls to access everything.
Yeah.
It's beautiful.
It's a real nice example of async and await as well there.
Yeah.
So I'm sure, Brian, you've heard of little Bobby tables.
Yeah, of course.
I don't know.
I think we've brought it up on the show.
Yeah.
I don't know if we've actually, have we featured it as a proper joke?
I don't know what we have.
Nonetheless, this one is no joke.
This is just little table.
I don't know what I was thinking.
I know what I was thinking.
I was curious.
I didn't want to commit as much effort as it turned out to be into having like a broad discussion about this.
But I thought, okay, well, we have dictionaries.
And so I can go and find a single key, pass in a certain key, and then get the thing back or not.
Right?
So if I've got like, I don't know, users, I could have the user ID.
And then the user object comes back if I index the dictionary like that.
Totally simple, right?
Yeah.
What if we wanted to ask that question two ways on the same data structure?
What if I wanted to say, give me the user by ID and give me the user by email?
So one possible way, I guess, you could just cram all the IDs and all the emails into the dictionary.
But then things like, you know, enumerate over dict.items breaks because you get, you know, every now and then it's integers or it's strings.
And then it's a duplicate of the users like in .items or .values.
So it's not really a great one.
So I said, does Python have like a structure that is not a database?
Because I do not want to do database stuff.
Like if I wanted to do that, I would just use a database.
A thing that is lightweight and in memory and easy to use that lets me put something like a user in there, but then be able to ask, give me the user by ID.
Give me the user by email.
That is fast.
Right.
So dictionaries work because they're indexed and they're insanely like near, you know, oh, one type of performance on getting back the content that's in there.
Right.
Yeah.
So I want to be able to do that both with email and ID not.
I'm going to go on this rant some more later.
I'm actually trying to pull together all the responses I got because I got a bunch of things given back to me.
A lot of people suggested pandas, but I want to store non-tabular data.
So I'm not sure pandas, which is tabular-ish makes sense.
Nonetheless, one thing I did come up with that's probably the closest to what I was asking for without me doing any work, which I'm not against doing work.
But if something exists, you know, let me pip install it.
Right.
Is this thing called light table by Paul McGuire.
Sorry, not light table.
Little table.
And it gives you a schema-less in-memory thing that's kind of like a dictionary, but gives you ORM-like access to the objects.
Okay.
Okay, so it's like, think of like an in-memory database, basically, that you don't have to go create table, you know, set column type, name this to, you know, var char 16 type.
And like, you don't have to actually define the table like a full-on database, right?
You just say it has, you know, put these things in it like you would a dictionary, and then you can access all the elements.
What do you think?
I think I'd like to try to solve your problem also.
It's a fun programming problem, right?
But this thing is pretty cool because it lets you do like greater than queries.
It has indexes on all of the columns or the columns that you say you want them on.
Like, all you do is say, it's like create a dictionary and say, I'm going to put in a thing by ID.
I'm going to put in a thing by email.
I'm going to put in a thing by city.
And I want to index for all of those.
So it's like dictionary-like speed, which is pretty cool.
It even does like in-memory joins and all sorts of stuff.
So, yeah.
Okay.
That's neat.
And the result of like a query can be like another little table.
So I could like do a filter and select only a couple of columns.
And then out comes a little baby little table.
A little, even littler little table.
Anyway, I thought this was a pretty cool thing because it lets you kind of do database-like stuff without the effort.
Right?
Do it dynamically.
Some people said, hey, you should just use SQLite.
I'm like, yeah, SQLite's cool.
But then I've got to come up with a full-on schema for defining the thing.
And that gets to be a pain.
There's also some other options.
But little table looks good.
Yeah.
I'll have to get an example.
Get your actual problem statement again and try it.
But this looks neat.
Yeah.
Yeah, absolutely.
Yeah, well, I'll come back to that for sure as well.
So because I want to bring together, like I got so many good recommendations and ideas that I think is probably worth just doing a segment on that.
But little table.
Nice.
This is something I'm surprised we didn't talk about already.
Maybe we have, but I've forgotten.
pytest Timeout.
This was a listener's suggestion.
And I think it's pretty much an essential plugin for any test suite that you're running, especially if it's not something you're running where you're watching it.
So if it's something running on a server or continuous integration or something, or if it's a long-running test suite, it's a very simple-to-use plugin.
And what you want to make sure is that none of your tests run longer than a certain number of seconds.
All the people out there that are, like, scratching their head thinking, wow, there's a test that runs longer than a second.
Yes, there are tests that run longer than a second.
Especially if they're trying to talk to hardware or external things.
Yeah.
And that thing might not be there and it's just waiting.
Yeah, there's more to testing than unit testing.
There's also system testing.
But anyway, this one's great because you can set up a configuration in the config file.
You can throw one number in to say, like, say you have, like, you know, five minutes or something like that.
Or even just down to, like, three minutes.
I want to make sure nothing runs longer than this.
And just to make sure that the server doesn't just sit spinning all night long.
And then, well, let's say you even tighten it closer to try to kill off a test if it's running longer than a certain amount.
But there's, like, maybe two of your tests that are longer or a few of them that are longer.
You can put a decorator on those particular tests and give them more time.
And then the rest of them shorter.
It's very easy to operate and just kind of a must-have for long test suites.
Yeah, that's super cool.
Yeah, I mean, sometimes you'd just rather have the test fail if it's taking way, way, way too long.
And you're like, I'm pretty sure this is going to fail, but not right away.
I would recommend just trying it out and kind of, like, look at the time of your tests and stuff.
And then set it so that it actually kills one of your tests in the middle.
Or stick a spin in there or something like that.
Just to verify it does.
Because it is sort of operating system dependent.
And there's some configuration allowed in the plug-in to be able to use either signals or kill commands or process killing.
There's different ways to stop a test that's going too long.
So test it before you deploy it.
But it's a good thing.
Do a meta test.
Yeah.
Test of your test.
Exactly.
Super cool.
Okay, that's a great one.
And, you know, use case is super straightforward.
I have got one for you that has got me really, really excited.
It's called events.
So in Python, we have functions as first class objects, right?
You can pass a function around super easy, right?
Like if there's some part of your program that's going to run and you want to get a function called when it's done,
you can pass that function, it'll do its work, you can call it, right?
You have this kind of observer style programming, right?
Yeah.
What requires programming on your behalf is to have that happen for more than one thing.
Like I would like parts of my program to subscribe to being notified about events and one or more of them get called when this thing happens.
So a friend of mine, Nicola Aroshi put together a really cool project called events.
And the idea is that it adds event subscription and callback to the Python language.
Oh, cool.
In like a super simple way.
So go to a function that is an event.
If I want my function to be called by it, I would say like, like if I want the event on change, I would say my class dot on change plus equals some function to call.
And if there's already one there, it's just going to add it to the list of all the functions that will be called when that event fires.
And if at some point I decide I don't want to hear about it anymore, I just go to my class dot or my object dot on change minus equals the function I want to take out of that subscription list.
And that's it.
Oh, that's neat.
Isn't that slick?
And then to call it, you just say object dot on change and you pass the arguments and then all those functions get called in order.
Oh, this is cool.
Yeah.
So it's if you have to do any sort of observer design pattern event subscription stuff like this is super, super nice.
And it's inspired on the C# language base event keyword, which is based on delegates, basically function pointers.
It doesn't really matter if you know about that or care about it.
But if you know about the C# version, this basically brings that to the Python language.
Yeah.
I kind of want to build up a finite state machine using this.
It's cool, right?
Yeah.
I mean, it could make it really readable.
Yeah.
I have a gist that I'm working on or I have some code I'm working on.
I'll post as a gist that people can check out that is like a lot better than what they have in the documentation.
So the documentation takes like this raw event source and shows you how you can subscribe and unsubscribe to it.
But what I've got is something that's like here's how you have a class, right?
Like, you know, a thing on the screen.
And then you could have like subscribe to when the location changes or the size changes or, you know, those kinds of things.
And it's more of like a natural programming analogy.
So I'll put up the gist for that.
I'm just working on a few things to see if I can make it even slightly better.
I'm seeing if I can use descriptors so that the event triggering happens behind the scenes without you even have to program it as well.
So like right now the from the outside using it is really easy.
But you do have to sort of like know when something's changed and then call that raise that event.
I think I can use descriptors to maybe make it seamless on both sides.
But I'm still playing with that.
Now, do you know if this if all of the events get called by the thing changing the making the event happen?
Yes.
They do?
Yeah.
Okay.
Yeah.
So they get called by the thing that whatever decides to raise the event.
That's the thing that's doing the calling.
The events just basically manage what are the functions to be called in what order.
And then like you call it and it just like delegates onto them.
Also, you get to just arbitrarily pick the parameters that gets passed that get passed along.
But it seems like a good idea to say this event always takes these kinds of arguments and whatever.
There's not a lot of structure there.
You do get the only real safety is you can say when you create it, you can say these are the only allowed events because it's kind of just full on dynamic programming.
But you can say these three things you can subscribe and unsubscribe and call anything else.
We're going to say it doesn't exist.
So that's pretty nice.
Yeah.
It provides a little safety.
Cool.
Yeah.
Well, that's our six items.
Do you have any extras for us?
Not really.
Just I sort of talked about it.
I was going to talk about it here.
But I talked about it in the we talked about what we're doing, how people can support us.
I finished the Python memory management course.
The thing is so cool.
It's a five hour course just diving into the internals of like Python memory management algorithms.
And what I thought I would create was something that was like understanding Python memory management.
But there's actually a ton of techniques I discovered that actually let you run your code in ways that are like, well, now it uses half as much memory and it's 30% faster and stuff like that.
So I didn't think there would be a lot of actionable stuff coming out of it.
But there is, which I think is pretty cool, actually.
Oh, nice.
Yeah.
How about you?
I'm pretty excited that pytest 6 is out.
A couple weeks ago, we talked about the 6 being in sort of a beta release, but it's out now.
And I wanted to mention that episode 125 of Testing Code walks through those changes.
This is due to the miracles of time travel.
This has not been recorded yet, but it will be recorded and released by last week.
Perfect.
Time travel.
I love it.
You've chosen the perfect joke.
So the only question I have for you before we do the joke is, am I the school administrator IT person or am I the mom?
Oh, you be the mom.
Okay.
So the phone rings.
I pick it up.
Yeah.
Hi, this is your son's school.
We're having some computer trouble.
Oh, dear.
Did he break something?
In a way.
Did you really name your son Robert?
Robert single quote, parentheses, semicolon, drop table, students, semicolon, minus, minus?
Oh, yes.
Little Bobby Tables, we call them.
Well, we've lost this year's student records.
I hope you're happy.
And I hope you've learned to sanitize your database inputs.
Be on the lookout for that sequel injection, baby.
I love it.
This is so good.
This is absolutely one of the most classic computer jokes there is.
Yeah.
I love it.
Because it probably would actually work.
It reminds me of the guy who said that he got his license plate to be the characters N-U-L-L,
null.
Yeah.
I heard about that.
Yeah.
And he ended up getting all the like automated, you know, you drove through a traffic light sort of thing, tickets for all the records that were null.
Yeah.
Anytime they didn't have data, it went to him.
Any police officer that forgot to enter the license plate, it would go to him.
He thought he would get out of it because they wouldn't be able to send it to him.
But oh, no.
That's hilarious.
Awesome.
All right.
Well, great to chat with you as always.
All right.
You too.
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 Python Bytes.fm.
If you have a news item you want featured, just visit Python Bytes.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.
Thanks.