Python Bytes - #172 Floating high above the web with Helium

Episode Date: March 13, 2020

Topics covered in this episode: Python in Production Hynek * How to cheat at unit tests with pytest and Black* Goodbye Microservices: From 100s of problem children to 1 superstar Helium makes Selenium-Python 50% easier uncertainties package Personalize your python prompt Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/172

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 172, recorded March 4th, 2020. And I am Brian Ocken. And I'm Michael Kennedy. And this episode is brought to you by DigitalOcean. And they've got all sorts of cool stuff we'll hear about later. Who's going first? I always forget. You know, I guess I'm going to jump in on this one because I've got some cool stuff from Hank.

Hank? You even messed his name up worse than I do. Henyik? Okay, cool. All right. Sorry, Henyik. I have to give you a bad time because he gives me a bad time all the time. Yeah, well, it's a cool but unusual name, which is probably going to result in some mispronunciation.

He's got a cool article he tweeted about a little while ago a week or two ago and i just thought it was really interesting and basically it's his thoughts on running python in production so it's kind of a look back on some places he heard interesting discussions on people running python in production as well well as maybe got some nice little callouts on things that seem solved but aren't solved that are interesting to talk about and whatnot. So I just thought I'd maybe talk about that a little bit. Yeah. Yeah.

I mean, I definitely relate to this being someone who runs Python in production. So in order to keep the two podcasts, the courses, and various other things, other services running. There's like eight servers and whatnot. So there's a non-trivial amount of DevOps-y production architecture stuff. It's not anywhere near Facebook, Google, or whatever, but it's way more than a $5 host running some WordPress thing. So it's meaningful, I guess. So anyway, his article, basically,

the premise is that he's missing a key part of the public Python discourse in that it seems like people really aren't talking about running Python in production, although maybe the exception of Instagram or Spotify, right? Yeah. That's pretty interesting. And he listened to this podcast episode or recommended or I guess listened to this podcast episode sort of kicked him off down this path of thinking about it. Like there was this podcast, and I'm trying to remember what was it called. Here, I'll pull it up. It's called, well, Running in Production. Actually, it's a pretty interesting one by Nick Gentakis.

Probably mispronounced that name as well. But Nick's got an interesting thing where he talks to people from all sorts of different technology backgrounds javascript or ruby or python or whatever and he interviewed this guy named gareth thomas from the uk where they have some plone i believe it's plone app that is actually running like 10% of, getting like traffic from 10% of the UK schools or something really interesting in this. But it was more interesting to just think about listening to that episode, looking at Hank's article

and saying, when do I agree with them? When do I disagree? And he said, look, I disagree with a lot of their choices actually. I think they're using microservices a bunch and he was like thank goodness there are no mark no i'm not doing microservices basically and uh it's really interesting even if you disagree to think about the trade-offs that people made because while you might make different trade-offs that might be because you have different

goals or different things you're optimizing or different experiences or things that you need over what they need, right? So I just think this idea of exploring how people are running Python in production, how they're solving problems, it's pretty interesting. Yeah, I also kind of have to agree that I like the idea of hearing more about the pathway of why people are where they're at, what decisions they made and what things they faced and why they made those choices. Because that's almost more interesting than what end product they came up with is what the path they took to it. I mean, like Lord of the Rings would be nothing without the path to the end, right? Exactly. Oh yeah, they get the ring back. Yeah. Yeah. So his article, like all good

complaints, comes with a suggestion. And he says at the end, here's a bunch of things that could get discussed more. And so here's an offer. I would love to encourage people doing interesting stuff with Python, running websites or APIs and whatnot, to tell them basically to do talks at PyCon, at meetups, and in blogs. And I think he even offered to help mentor people to get those kind of talks accepted more frequently at conferences. I think that's a great idea. I think it's a great idea.

And maybe we should do that at the PDX Python West meetup. That'd be fun. Yeah. Yeah. We can think about that. But yeah, I definitely like this idea because on one hand, if it's kind of always the same story it's not that interesting but i do think there's a lot of trade-offs that people are making and i think it's it's pretty fun to see what's working and it's clearly going on we're just not talking about it because we're i mean you and i have noticed that there's a lot of people

in the python community that are in the website or the website of the Python community. And it's way more than just the Instagrams and Dropboxes of the world. So yeah, absolutely. Absolutely. Yeah, it's really cool. And there's a bunch of more stuff that I'm not covering in this article, but I mostly covered it because I love his offer of like, hey, let's get more of this conversation out there. You know, we could do open spaces, we could do Python, PyCon talks, suggestions, proposals, things like that. I guess one final thing to throw out there is Dan Bader

and I did have this conversation for TalkPython and the training and Python Bytes and whatnot, as well as for real Python over on TalkPython episode 215 at the last PyCon. We recorded that one. So we'll see what happens with this PyCon.

But that's a small contribution towards that. And that was a really popular episode. But I definitely want to encourage people to take Henik up on this, up on his offer here and get the word out a little bit more. All right. Yeah. Yeah. So, Brian, when I think about testing and whatnot, I feel like you should really be

honest in testing to tell a true story. And you should never cheat with testing, should you? Yeah, only, yes, you should definitely cheat. Cheat as much as you can. Tell us about this next one. So, this comes from, I think it's Simon Willison. The article is called How to Cheat at Unit Tests with PyTest and Black. It's got all my favorite things. Testing, PyTest, Black, and

well, I'm not a fan of the unit part, but we'll get there. The premise is, I'm going to quote this, in pure test-driven development you write a test first and you don't start on the implementation until you've watched a test fail. Okay, so the idea is it's the red-green refactor thing. So you write a failing test, you write code to make it pass, and then you refactor it so you're happy with it. And if I don't do that, I'm cheating.

Yeah, apparently. I think I might have cheated accidentally recently. Okay, well, yeah. My thoughts partly on that is there is no such thing as pure test-driven development. Even Kent Beck himself says he didn't make this stuff up. He rediscovered it from previous best practices. So there's no pure in test-driven development. We can't even agree on whether a MOX are good or evil or what a unit is.

So whatever works for you, man. So Simon's process really was to cheat on this. And I think this is just clever pragmatism. His cheat method was to write a PyTest test that calls a function. So he's been working on a function, and he thinks he's happy with it. And he writes a test that calls it, but then compares the output to, you know, something he knows won't pass. Like just the output equals false or something. And you know that assert's going to fail.

So you run the test, and when it fails, you take a look at the output. And if you're happy with the output, you just copy that, just highlight it, copy and paste it into your test, and now your test should pass. So this feels like cheating, but it's really just taking a manual test and turning it into an automated regression test, especially when you're exploring stuff. I think this is a great way to build up some of your test coverage. The bit about black is that the output might be this big, long blob, something like a dictionary or a big list or something and it might not be formatted well and that's where he just turns black on his test code and reformat it nicely and make sure it

still passes so i think this is a good time saver this is interesting i was working on some tests recently where i had a big chunk of test data that i wanted to compare against something kind of like he's describing here. And I was really torn. I'd love to hear your thoughts on this. You know, I put this at the top of my test file so I could reference it, right? I didn't put it in the test. I put it kind of separate because I'm like, well, this thing is, you know, it basically fills the screen. So I didn't want it to generate a huge test. I want to say, compare against that thing, right? And one of the thoughts I had was creating like a,

I don't know, a test data module where I could pull those things out, like put it completely into a different file and pull it back. And it sounds like that might also be a nice way

to organize things here, but at the same time, it takes what you would see as I'm comparing against this and it hides it away behind, you know, a label of whatever that test module is. What are your thoughts on that? Good? Bad? Indifferent? I think there's lots of times where that

is a good thing, especially like you said, it's a big structure or something that you're comparing against. One common method to do something like that is if there's, for instance, it isn't really what you're asking but if there's instead of comparing a whole bunch of different fields or something to actually compare structures so to create the expected data structure especially with data classes it makes it pretty easy you can just say this is my expected object and what i got back was this thing and compare those two um now if that, if all the data is huge and it makes it more clean to work with your test, to stick it in a different file, then go for it.

I think that's fine. I mean, there's a method of regression testing, which is kind of the model of I know it works now and I'm going to modify the code for some reason. So I, instead of trying to come up with thorough tests for everything, just running it with a bunch of logging and stuff and capturing all that. Yeah, absolutely. And then running it again and make sure all of your output and logging is the same and just comparing against that. It's yucky to work with in the long run, but in the short term, it's a pretty handy, quick thing to do. Yeah. Instead of changing your entire architecture so you can mock out everything, and then who knows if you get that right. You're just like, all right, I don't want it to change. Let's just start from like, keep it where it is. And if it breaks, then we'll figure

out if that's a change we wanted, right? But just to know that it didn't change is really helpful. And that's a quick, easy way. I like it. Right. And I mean, change detector tests are a smell that you need to be aware of because they're not, you want to be able to change your architecture. As long as you can make sure that you're checking for, you don't want the behavior to change sometimes, those are good things. Yep, I agree.

Be a pragmatist. For sure, good advice. You know what else is good advice? Work with DigitalOcean. Yeah, definitely. We've been working with DigitalOcean, and we've got a lot of our infrastructure there, and we've been really happy with it. And so one of the things they've got, Work with DigitalOcean? tricky and getting into that going from just building on your own computer to dealing with all of this some people might not know how to do that and so that's one of the reasons why digital

ocean launched their new support center so the support center makes it easier to find the answers to your questions and to get help that you need right when you need it you can search across product docs or community tutorials and forums and it's all in one place and you can get all your answers. So I'm sure that's going to help a lot of people really a lot. So you check this out. You can visit pythonbytes.fm slash do support to see their tutorials. And of course you can use pythonbytes.fm slash digital ocean to get a

hundred dollar credit for new users. Their tutorials are pretty awesome. And I just want to tell people how helpful they have been. So typically, especially when I was getting started, I'm like, man, how come this micro-whiskey thing won't start? It seems like it should work when I run it,

but it won't. It's probably something like the login file I didn't have permission to write to or something weird like that. You go search for that. And it's very likely that one of these tutorials is going to come up but you know i just went and put micro whiskey into their tutorial thing here and it comes up how to serve a flask app with micro whiskey and nginx on ubuntu 1804 but then it has a drop down oh would you like to do that on 1604 or 1404 or maybe on cent os 7 or whatever, and you can actually change the operating system it's running on

and the tutorial will adapt. I mean, it's ridiculous how involved it is. Yeah, they've really done a lot to help novice users come up to speed to get things running well. Yeah, I just remember how helpful that stuff was for me. So yeah, check them out at pythonbytes.fm. Get that credit, but then use their support center to actually get going. You know what I'm glad I don't have to support?

Hundreds of microservices. Yeah, me too. So I think I found this from a Henyuk's article when he was talking about how people were running in production and whether or not they should have microservices or not. And that podcast I told you about, I believe those people were using microservices. He's like, yeah, no way, no thank you. And referred to this article by Alexandra Noonan, who works for a company called Segment.

And this is like a retrospective on their experience. So they had started out with a monolith app. I believe they're doing JavaScript, but it doesn't really matter. Basically, it's like package managers and maintaining versions that talk to APIs. The same story for Python. You can just switch the code samples or whatever, and they're not really relevant. So there's this article called Goodbye Microservices from 100 Problem Children to

One Superstar. And it talks about how Segment was founded during the height of microservices as the architecture du jour, right? Architecture of the day. And how to sort of decided that was going to solve all their problems. And at first it did, but as they grew and grew and grew, it turned out to be such a huge headache. So they had three software developers, and eventually they said, basically their three software developers were spending almost all their time tracking down broken tests

across these hundreds of different variations of microservices and all sorts of stuff, and they were just going nowhere. So it talks about how all the benefits that microservices should have like improve modularity reduce testing burden better functional composition isolation team autonomy and all that and how many of those things turned around to actually become like molasses in their world and slowed them down instead of letting them work faster so basically it's a really concrete

story about how they took a step back from microservices, how they actually made that step backwards, because with 100 microservices into one app, that's kind of a beast to pull off, and how it helped them basically get everything under control again. So what's really interesting is basically the places where things broke down. So for example, each microservice was talking to a similar but slightly different api like customer integrations and stuff and they had slight different needs so over time some of the like the core bits of those libraries were slightly different across the different apis and it became instead of having things you manage separately for each endpoint,

you actually ended up with 100 different services, all of which you had to manage. And if you're going to make a big change, you've got to test it against all these variations. Their tests were super slow to run. There's just a lot of things. Also dependencies, as in requirements.txt type dependencies, they wouldn't upgrade all of them at the same time

because they wanted to make sure that they'd had to test it and whatnot. And so if you're going to be running on, say, requests 2.1 over here and 2.2 over there, are you sure if there's a problem with that, how do you deal with that? Now, I'm a big fan of the big monolith-type apps and keeping a little more control over it that way.

So I'm all behind this sentiment. But I do feel like they could have actually done a lot of work on the DevOps side to make this dramatically better. And maybe, who knows, maybe they would have never switched. Yeah. Did somewhere I catch that there was a limited number of developers? I think there was like three or something. At one point there was three working on all these things.

And, you know, microservices are often touted as being really great ways for dev teams to have autonomy. But when your dev team consists of three, you know. You don't really need autonomy. You're already autonomous. Yeah, exactly. Like that's one team. It doesn't need more than one thing to be autonomous, right? Generally, basically speaking, but you know, so for, let me just like take a step back and say, for example, like one of the big problems I said is we've got a hundred different services that behave similar, but not the same with slightly different integrations against different API endpoints. And we're feathering out or fanning out requests to those services based on which

thing they're kind of integrated with. And the big problem was the dependencies. Well, if they had used something like Docker and Kubernetes and they forced them all to say, we're going to install the same runtime environment with the dependencies pre-configured and the only way you get to release a new version is you get your little thing to work with the latest image that has a uniform set of dependencies across the board. Well, that sounds like that would have completely taken out one of these problems to me, right? I mean, sure, you might have to do a little

work to replace a new version of some thing, but you're keeping it in sync, right? So it seems like there's a couple of things like that that they could have done. There's other issues on the testing side that were caused by these variations. And I feel like there's a couple of things like that that they could have done there's other issues on the testing side that were caused by these variations and i feel like there could have been some uniformity stuff done especially around docker that could have made this a lot better but still i think there's a lot of interesting lessons there yeah i think i'm looking forward to reading this because that sounds like an interesting story yeah yeah it's pretty good well done has nice pictures yeah neat oh neat. Oh, I like pictures. Speaking of tests and running them on the web.

Yeah, so one of the workhorses of front-end web testing is often Selenium. And Selenium's awesome, but it can be abused. And also, it takes a little bit of knowledge. So there, I think we've covered others. There are some higher-level that use Selenium under the hood but have a different interface. And I'm a fan of a lot of this sort of stuff because if it simplifies your life, go for it. One of the things we're going to cover today is Helium. It's a newer, oh it's very much newer. It's only a few months old Python library for automating web browsers. It's a project that's built on top of Selenium, and even though it's fairly new, it's already got like over a thousand stars on GitHub.

That's cool. The claim is Selenium Python 50% easier. Helium is the best Python library for web automation. Well, of course, it's saying that to itself. But it does look pretty clean. There's some pretty clean drivers to be able to control Chrome, control your browser, and then navigate some stuff. So it looks good. Yeah, I really like this. I think Michael Herrmann did an interesting job on this. And the reason that I think this is neat is it takes you away

from working at the structure level so for example just like selenium you say I'm going to open up this website right so you say start chrome github.com slash login but instead of doing some kind of css selector to find the the text box you just say right if you want to like set something into a text box you say write this text into and you just you know give it like a short bit of text like the label that is right before immediately before the text box all right so write something into username and that'll just fill out the username thing then write something into password and that'll type in the password and then click the button they say click sign in and it

just finds the button with the text sign is what it's nice is like what a human sees about the page is how the code interacts with it and you might say well that's unstable right what if somebody changes the text well if you've ever had to work with css selectors and then somebody redesigned the site and your automation stopped working it's not a whole lot better so uh you might as well make it easy for humans as as far as i see it yeah and the i mean the api is like so clean and short so you've got like i think like function calls like click and with you just give it like the tag of thing the the button tag that you're going to click on so like yeah it's pretty sweet and to fill in a username for instance in a username field it just is right and then you give it two parameters that

the name of the field that you're going to write into and then what you're going to write in there so this is pretty slick i like it yeah for sure too many things get the for humans tag in python but this one kind of could get that yeah Yeah, and so since this is new, I'll be curious, and there's a lot of web testing going on. I'll be curious to see where this goes. Keep an eye on it. Yeah, absolutely.

And the easiest way, if you want to get a sense of like whether or not this is interesting for you, is just go watch the, there's a little GIF, animated GIF. Just watch that for 10 seconds, and you'll have a quick idea what you can work with there. We've said this before, animated GIF. Just watch that for 10 seconds, and you'll have a quick idea of what you can work with there.

We've said this before. Animated GIFs of how things work are a good thing to get people excited about a project. This project also includes a cheat sheet of some of the common things you might want to do. Single page with a whole bunch of stuff. It's kind of like an FAQ, but just sort of no questions, just answers. Yeah. So I'm pretty certain that's a good idea, but sometimes you're not certain. Yeah, lots of times.

So I remember, I don't know where I learned more about this. Either this was in physics or this was in statistics or something. I think it was one of my science classes in college. I've promptly forgotten it. So there's no way I could work with uncertainties in measurements really well. Maybe it was even engineering. I'll tell you a quick example and then I'll ask you a question. You can't look ahead and don't cheat because I have to answer the notes further down. So imagine we're back in school or you're solving a real problem. Jane, she needs to calculate the volume of her pool so she knows how much water it'll take, right? So she measures the length, the width, and the height.

Now, of course, you can't measure it ultra precisely. And also there's probably some variation in there. So she determines the length is 5.56 meters plus or minus 2.5%. Like that's her guess on the inaccuracy. And the width, three meters, plus or minus 2.6%. And the depth, three meters, plus or minus 3.7%. So what is the uncertainty, right? That plus or minus a little bit, that uncertainty, what is the uncertainty in the volume, which is the length times the width times the depth? Oh, I can't even remember. Do you multiply them together? Yeah. Do you multiply them together? Yeah. Do you multiply them? Do you add them? Do you average them? Like what the heck? Do you take the max? I don't know.

Well, there's actually very strict rules about how you do it. So when you multiply things, apparently, I didn't remember this, but I've looked it up. Apparently you add the uncertainties when you multiply things. So in this case, it's 2.5 plus 2.6 plus 3.7 is 8.8% uncertainty. That is super tricky. And these kinds of calculations are the kind that ends up with spacecraft burrowing into like a desert or into a moon because they're like, oh, did we get that wrong? Whoops, right?

Did we use the wrong units or did we get that wrong? Whoops, right? Did we use the wrong units or did we get the wrong uncertainty or whatever, right? So there's this really cool library called Uncertainty. And it comes with all these different math operations. Like it has values, like a float. And it has a sine, right? Which is like, you know, sine, cosine, tangent sort of thing. So you can do mathematical

computation. But instead of having a regular float, it has an uncertain float, a U float. So you create like x would say like a U float of one is the value and then comma point one is the uncertainty. And then if you were to do math with it and print it out, it'll say like two times x would be two plus or minus 0.2. And so it always carries its uncertainty and then as you take the sign of it or you multiply or you square it, it will actually

integrate and consider all those different uncertainties to give you a final uncertainty in your output. Isn't that awesome? That's very cool. Yeah. This is useful in lots of fields. Yeah. If you ever have to compute with uncertainty, this seems so glorious. This and pint, right? If you could put this and pint together, then it's on.

Because pint lets you work with different units of measurement and then add and multiply and divide them. And then you throw the uncertainty on top of that, boom, you're golden. Yeah. Yeah, that'd be cool. We had worked with once with a measurement value that it was a power level for a cell phone and the uncertainty ended up being um plus or minus like the amount of power that the sun produces so it's like we essentially don't know the answer

if that's the uncertainty right right right it It could take a AA battery or it could melt the earth. We're not really sure which. We're not sure which, yeah. Not ready for shipment yet. Exactly. Maybe we've got to get more accuracy there. Anyway, this comes from Tim Head who mentioned it on TalkPython where we recently did an episode on Binder,

which is super interesting but not yet released. So eventually we'll talk more about that there as well. Anyway, uncertainty, cool little library if you've got to do any sort of computation with this kind of stuff. Yeah, I think it's cool, but I'm not sure about it yet. Yeah, well, can you ever be? No. But you can be sure about the level at which you can't be sure using it.

Yes. Awesome. I'm pretty sure that I wish my Python prompt was cooler. Well, I'm okay with my Python prompt. Are you? I don't know. I mean, come on. Think of all the options.

You could do anything you wanted. And I never thought to do that. I mean, I do it with my, like, a bash prompt and stuff. You know, we put our virtual environment name in there. It's stuff like that. Get status, get branch, all that kind of stuff. Yeah, definitely. So you can change those things.

So why not? This article comes from, I think, Arpit Bayani, and it's called Personalize Your Python Prompt. Those three right angle, right, what is it? Greater than signs that are together when you're doing interactive Python. Apparently you can muck with those. There's a sys.ps1 variable that if you sign to that,

you can change it to whatever you want. And, of course, the author didn't stop there. He said, oh, it can be dynamic also, but you have to have a non-string object to make it dynamic. So he gives a little example to where you can, and the way you do that is you have an object that has a dunder stir method. If that

has dynamic action, that gets called every time, so for every prompt. So this is pretty neat. He has an example of doing some stuff, but I wanted I didn't have time to do it this morning, but I was working on it. I was trying to get a prompt that would mimic the Windows command prompt

because apparently I want that on my Mac because that would be fun. You just want to confuse people like, what are you doing? This is insane. I mean, C colon backslash greater than was easy, but I wanted to also put the path in there and flip the direction of the slashes and stuff like that.

Yeah, that's really cool. And I didn't, one, didn't know that you could just set that import sys.ps1 equals something. And that now is your prompt. But I didn't really think that it could be a dynamic object that has a stder. That's pretty cool. Yeah, that is neat. You could easily set up something like that has a stir dunder stir that's pretty cool yeah that is neat you could easily set up something like the jupiter you have jupiter notebooks you have bracket one bracket two bracket three for your various calculations like five lines you got that in your python prompt if you want it it doesn't have very much value because you can't change the order

but still it's pretty interesting i think yeah yeah that's cool yeah quite cool all right well that's a good little find. A quick and easy to play with. Well, do you have any extra stuff for us? Oh, not really. I'll go and throw one thing out for you. So I finished my Python for Absolute Beginners course and so now I'm starting a new course

which is like adding a CMS to a proper data-driven web app. So if you've got a Flask app or Pyramid or Django or something like that and you want to let other people write part of the site proper data-driven web app. So if you've got a Flask app or Pyramid or Django or something like that, and you want to let other people write part of the site, and the rest is more like Amazon would be with, you know,

here's the categories, here's the products, here's the product page, and here's the review page. Like, you know, very structured. But you want to just let them, like, write freeform stuff. So I'm working on a course that lets you kind of add that to existing sites. So that'll be fun. I'm having a lot of fun working on that. Okay.

Interesting. Yeah. Is this kind of where the Markdown work that you were working on comes in play? Yes, exactly. So I decided the work that I did for Talk By The Training to build out the landing pages and the interesting stuff to basically make a whole section of that site just driven by Markdown and just editors and whatnot. I'm going to take that,

extract it, and sort of take it to the next level with rich Markdown editors and database backends and stuff like that. It'll be fun. Shall we close it out with a limerick? Sure. I'm not very good at limericks, so I'll give this a shot but this comes to us from

alexander a he said this over he had written it this is his he wrote it recently and this is uh submitted apparently there's some kind of limerick contest at manning you win free con of free content like books and whatnot if you submit a winning programming limerick. All right, so here goes. Coding environments in three parts. To this day, some prefer bbedit. VS Code is now getting some credit. Vim and Emacs are fine. So are Atom and Sublime. But it doesn't matter much if you don't let it. But wait, let's not forget IDEs. Using PyCharm sure is a breeze. Komodo, Eclipse, and Idea, CLion is my panacea, and Xcode leaves me at ease. But Jupyter Notebook is also legit.

Data scientists must prefer it. In the browser you code, results are then showed. But good luck when you try to use Git. I love it. It's good, right? This is great, yeah. Oh my gosh, it's so good. Especially that last line. I love it. It's good, right? This is great. Yeah. Oh my God, it's so good.

Especially that last line. I love it. Definitely makes the whole thing worth it. Yeah. Yes, indeed. So well done, Alexander. Thanks for sharing that one that's used on the show. That's great.

All right. Anything else? Do you got anything you want to share with folks? I guess I jumped ahead of you and did my limerick. No, no. No, it's good. We've had a whole bunch of great feedback from the recent Testing Code episodes.

So, it's been good. Yeah, what are some of the ones? I know you just did one with Anthony Shaw and his plugin. Yeah, so we talked about security. We've talked about Django recently. And just the most recent one is talking

about the most downloaded PyTest plugins. So Anthony Sotili and I talked about 28 of the top plugins. That sounds like the perfect show. That's really great. Really geeked out on a lot of stuff. I found some super interesting ones that I'm going to talk about in the next

show, but we'll leave it at that. Awesome. Thanks. Thank you as well. Happy to be here with you like every week. Bye. Bye. Thank you for listening to Python Bytes. Follow the show on Twitter at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at pythonbytes.fm. If you have a news item you want featured, just visit pythonbytes.fm and send it our way.

We're always on the lookout for sharing something cool. This is Brian Ocken, and on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast with your friends and colleagues.