Python Bytes - #310 Calling All Tools for Readmes

Episode Date: November 15, 2022

Topics covered in this episode: Tips for clean code in Python Mastodon is picking up speed Some FastAPI news, and some great READMEs. Closevember Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/310

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 310, recorded November 15th, 2022. I'm Michael Kennedy. And I am Brian Ocken. And I'm Adam Hopkins. Welcome, Adam. Great to have you here. Awesome. Thank you. I'm excited to be here. Yeah, people mostly know you, I would imagine, through Sanic, your web framework.

Tell people about yourself. Yeah, that's correct. Well, first, I just noticed episode 310. So two more episodes and you guys pass the Python version. So congrats. Thank you. That's a milestone. Six years.

We just passed six years, two weeks ago. Yeah, that's exciting. I remember when you guys started it. So this is a great resource for the community. Cool. So just to introduce myself, I'm Adam Hopkins. I am one of the developers of the Sanic project. My day-to-day job, I'm a director of software engineering for Packet Fabric, where we, you know, day in, day out, I do web development. So that's my gig.

Right on. Fun stuff, it sounds like. Yeah, absolutely. Cool. day out i do web development so that's that's that's my gig and on fun stuff it sounds like yeah absolutely cool yeah well brian you want to kick us off with our first topic here yeah sure um so this is a a little bit of an easy topic uh tips for clean code in python um i was this is from uh bob belderboss from pybytes um i was playing with this dark mode on and off. It's kind of fun. Anyway. Dark mode is always appreciated in my book. Yes. Well, so this resonated with me. So I'm going to blast through the tips really pretty quickly. They're just good things to think about. I think it's good occasionally to remind yourself of when you're organizing your code. So using smaller units. I'm going to come back to this, but essentially it's thinking about if you've got huge functions that

do a whole bunch of stuff, maybe breaking it up. Like I said, I'm going to come back to that a little bit. Magic numbers, always good. Constants are better than just numbers sitting in your file somewhere. I'm kind of on the fence on the void. Avoid global scopes the third but um there's nothing really global in python it's module level but still if you've

got large files global scope can still be confusing so watch that using linters and uh narrowing or uh is a good thing um i'm not actually i'm not going to run all through the through all the tips there's some good tips here. So go ahead and read the article. But the thing I wanted to come back to is just this one, this first one, smaller, smaller units, because I just ran into this. So I'm, I'm working on refactoring the pytest check plugin. And currently it was, it's just all in one. I mean, most of the code was in two files, like the basic plugin hookup, and then all of the rest of the code. And people have added a couple other people have added features. And that's a good thing. But I have had my had a hard time keeping my head around

all the code in there. And it was confusing myself. So I've been working on splitting it up. So I split up all the code into, and I split it up into this notion of the single responsibility principle. I thought about this plugin as the features. And it's either large features that kind of take up their own, they're enough to be their own module, or some related features that are kind of all together. And I've split up the code into different modules about those sorts of pieces. And the nice thing about that is I've also done that with the tests. So I've split the test up into focusing on a feature at a time. So the tests are in multiple tests.

So it's a lot more files now, but each little piece is just a few windows full of code. So it's pretty easy to get your head around, oh, for this feature, all of these things But each little piece is just a few windows full of code. So it's pretty easy to get your head around, oh, for this feature, all of these things work together. And it's really been great to work with now. So I haven't published the final yet, but the smaller units thing, people do talk about large functions and that's something to watch out for.

But large files are a thing to keep a mind to and sometimes sometimes breaking it up you can go too far too if you got like like 100 different modules that are all are like 10 lines long that's that's too far um but you know so i really like the idea of smaller units and you know both files and for like functions or classes or whatever and one of the ways that I think about it is if I'm looking at a chunk of code, maybe like an inner part of a loop or some other thing,

I'm like, oh, I should probably put a comment to describe what that does. Alternatively, I could make it a small function and give it a name that tells you what it does, right? Like if it's, you know, update last login for user, that could be a comment or that you could highlight those five lines of code, extract method and give it that name.

Right. Like it just, there's sort of a natural, if I'm, I'm looking at it and I don't understand it, how can I, how can I make it easier to understand? Like that's, that's a really productive way to do it, I think. Yeah. Especially if that bit of code really isn't the focus of the function. It's just some other stuff that has to be done. Moving it out of the function proper is good.

And then the function name. Yeah, just name it something clever. I think one of the things you also really kind of hit on there is breaking up the test files too, right? And so I'm kind of curious to hear, like, you know, typically, you know, maybe for a smaller package, I mean, do you try to keep sort of one test file for one module and keep a module or um you know sometimes i i feel like when i've done that even even trying to iterate and all the different things that i might want to test in one file it could still end up being you know a couple thousand lines long i'm i'm focusing on features so um uh trying to keep the like for instance the one of the functionalities for a PyTest

check is, is stop on fail working and work correctly because I'm, you possibly could have multiple failures in, in a single test. So how to stop on fail work. Well, there's a, is there's a defined way we've defined it for the plugin. And so I've got like one test file that tests the stop on fail functionality. So I prefer breaking it up into user functionality instead of modules, internal modules. But yeah. Right on.

Oh, good tips, Bob. And nice find, Brian. One thing also I noticed that was in this article that I'm probably going to touch on in a little bit. Sort of that idea of the global scope because that's definitely something that I think can actually cause some problems down the road. And I'll touch on that in a little bit. Awesome. Yeah, absolutely. There's also a lot of tips in here that can be automated. You should write code that matches this kind of stuff already, but running the linters, running black um one of them is using yeah pre-commit one of them is using idiomatic code which you could use flint we talked about a bunch of things that like upgrade to you know python two to three um what's that pi upgrade i

think whatever yeah those types of things like you could a lot of this stuff could be brought in on the tool chain level too which is kind of nice yeah. Yeah. All right. Let's talk about Mastodon. So I don't know if you'll have heard Twitter's kind of going nuts right now. It seemed like a place that was just going to be around forever, but apparently maybe no. And so Brian, I think you maybe encouraged me to go over to Mastodon and check it out a little bit last time. And this was just like a week ago, man. You've like just went crazy. I have gone crazy. I'm telling you, but I think there's a lot of cool stuff over here. So, uh, I'm super psyched about it. Um, I just did a talk Python episode, but I'll pull up a link to that in a moment. But, um, what I found, so you kind of encouraged me to go over there

and I did. And what I found was there's a whole bunch of the people that we know and have been interacting with over on Twitter. Now they're all over on Mastodon, and it's a super nice active community. I expected to kind of show up there and go like, well, I'll wait until people show up. But they're already there. And like, Adam, I saw that you're over there. And Brian, obviously you are.

And I got the shows going over there. And so people can follow Python By on mastodon they can follow python uh i'll i'll put a link to all the various all of our profiles including adams over there in the show notes and we're all kind of learning at the same time so even the you show up and they've already got hundreds of friends there but they're like they're still learning also. So yeah. Yeah. Yeah, absolutely. They are. So Marco, yeah, go ahead. Go ahead. Go ahead, Adam. I was going to say, it does sort of kind of bring up an interesting question that I've sort of been, you know, feeling is, you know, are people starting to share in two different places now, you know, trying to have conversations in multiple places. And so there is a little

bit of an awkward and maybe, you know maybe we'll kind of just trudge through it and see how it works. But I definitely agree that it feels clean. It just feels very fresh. Maybe it's just because it's a new app to play with or one. I don't know, but I agree. I'm very happy to see that people that I'm already subscribed to, trying to see what they have to say are already there. And, and you're definitely interested to see, see how this develops because I think it's,

you know, it can only be positive. Yeah, I totally agree. My philosophy is kind of for the moment to be Mastodon first, not to burn down my Twitter account or to leave my community over there, but just like, all right, Twitter looks like it's trying to kill itself. Let me try to put some energy over here. And after Brian kind of got me moving, looking at Mastodon, it lines up way better with the ideology of open source and Python communities having this federated different bunch of servers. People can control them. They're open source. There's not one central choke point for it or whatever. But yeah, I think it's really interesting and I encourage people to check it out.

I was going to highlight that Marco in the audience said, me two weeks ago, is Mastodon good enough to replace Twitter? Me now, is Twitter good enough to have a replacement for Mastodon? Yeah, I'm kind of the same way.

All right, so I got a bunch of stuff I want to share real quick with you. So I'll go through it quickly. That is not it. Got to go in the right order. So I did a really cool episode with Gina Houska, Juan Luis, Simon Willison, and oh, I got to update my show notes because she dropped in last minute, Carol Willing as well. So people can check that out. The, these different places, you should really support them, these little instances. Like for example, the one that Brian and I are on is Fostadon, the free and open source software instance. It went from 2000 to 40 something thousand users in a week. And their hosting costs went from a hundred to a thousand dollars in the same period,

which is a lot. And it's just volunteer, right? That's a lot to be paying, but they have a Patreon, which is really nice. You go to their Patreon and you can sponsor them. You can also do that for Mastodon. If you look at, they have a sort of a statement breakdown of like, here's how much we spend on hosting, how much we spend on CDN and Bitwarden and all these different things and how it breaks down. It turns out, Brian, 2.5 cents per user will fund Mastodon. So I feel like we should be doing this. We can all spare 2.5 cents or maybe a dollar. Not everybody. And if you can't really, please don't. But most people who are software developers can surely do that. Put another way, out of those 40,000 people, if just 100 of them pay $10 a month, that will also fund Macedon. So it's very achievable

that we could end up in a world that is not ad-ridden, tracker-ridden, surveillance capitalism that's trying to trick us or manipulate us into do things, but these really nice open places that we can move around as our values match. I think the other side of it too is, you know, we need to, you know, make sure that the people who are the content creators, people that are, that have, you know, large followers and are, and are putting out information that people want to read, you know, make sure that they're, that they're, that they're supporting this as well, because, you know, where the content is, that's where the people will go. Yeah.

So hopefully, hopefully we can get more people, people paying for and supporting it. Yeah, I, I'm doing it myself and I definitely encourage people who can because it's fantastic. All right, what else did I want to cover about this? It's open source. It's Ruby, which is not the most amazing open source for Python people, but it is open source, which is very cool.

You can go get it. There's a Python package called Toot. There's also a CLI. We covered this a little bit last time, Brian. I said I'd go into it more, right? I think. Yeah. So one of the things I did, come back to that.

One of the things I did on, one thing that's annoying, if you're logged in, it's really hard to pull up an individual tweet on your own instance without it being in the show here. But one of the things I did Saturday morning, Brian, do you see the third button in the second row of my stream deck here? Okay. So I wrote and I integrated the Mastodon API into my stream deck. So now whenever we start a show, I just push that button and off it goes. I think actually I might've pushed the one for

TalkPython this time because they're the same screen, just slightly different. But anyway, we can push that button and it'll kick it off and that'll just post a toot, I guess we would say. And then I still can't get over that. It's just funny. It's a little much, isn't it? All right. And then finally, finally, one thing that's really nice is if you have a Chrome based browser like Vivaldi or one of those or Brave, you can right-click on the tab and say install. Mine says install Fostedon because I was on Fostedon.

But if you were on Mastodon Social or whatever it's called, it would say install that. And then you get a progressive web app that is, I would say, probably the best app on the desktop for doing Mastodon. Ooh, neat. Got hotkeys, all sorts of fun stuff. Lots of, you can do like the advanced view with columns

and all of these things. So I encourage people to check this out. One more thing on Toot. We'll come back to CloseVember in a little bit. Maybe this is relevant here, but this is a library Python package that you can use to talk to Mastodon. I have no idea how to use it.

It's completely opaque. It's like star, star, star, star, star, KW args callable. Or I mean, you just, there's, it doesn't have any structure. It's all like run, done up at runtime. You can't tell like, what are the functions? Even if you dur it, like it doesn't have any functions or anything you can call. So how it's used, I have no idea. It's, it's, it's hard to use.

But the one thing you can do is it has a CLI that will generate your OAuth login tokens and then you just use that directly with requests or ACPX or something. So as far as I can tell, it's not particularly useful until some sort of example is written. Even the tests don't seem to help very much. But what it does do is it'll generate your access tokens that you can use in the rest of your code, which is pretty cool. Okay. Nice. Yeah. All right. Yeah, well, people definitely should check that out. Adam, you're up next.

All right, so I guess a little bit of a back story to a couple episodes ago, you were talking about an article that I posted on my blog about this new feature that we invited and brought into Sanic about a month ago. And well, I was on Twitter at the time, but I sent a tweet to you kind of that we invited and brought into Sanic about a month ago. And I, well, I was on Twitter at the time, but I sent a tweet to you kind of with a little bit of a correction. And so I guess that's kind of why I'm here

is I just wanted to kind of clear up a little bit. The feature that we added into Sanic is this worker manager. And the idea covered in the blog article is sort of what an implementation of that might look like. So really kind of what the article was trying to cover was how to build a Celery-like clone. Can we take a step back really quick and just have you give the elevator pitch for Sanic, just for people who maybe haven't used it? Sure. So Sanic is, it's an async framework,

web framework for building web applications. One of the things that it comes with is a built-in web server as well. So it's both a web server and a framework. So it does both parts. So you don't need a micro-Wizgear or G-Unicorn or something along those lines? Correct.

You can use something like UVCorn if you wanted to. So it can operate as an ASGI app. So that is a possibility. But generally, I find that most people that use Sanic will use the integrated Sanic server because it's sort of built for high performance. It's optimized to work with the framework. The framework itself is generally very unopinionated and sort of tries to get out of your way

and provide you with the tools that you need to build an application, but not dictate specific patterns. So that's the short and long pitch of it. Last year, I put together a book on different patterns and how you might build production applications in it with Sanic and what are some of the possibilities that are outside the scope of just these documents here.

So specifically, one of the things that we kind of had noticed and really drove us to what ultimately became the worker manager feature is that, you know, Santa comes out of the box with, you know, auto reload, the ability to scale up multiple workers, all that kind of stuff that you would sort of expect. But you might in older versions, you might have a different experience when you're doing development versus when you're in production mode. And so we wanted to kind of get rid of that so that every single time that you boot up Sanic, whether you're in whether you're local host or you're deploying it,

you get the same experience. You've got one process whose whole job is to sort of manage the whole show. And then one or more of these worker processes that can be individual servers. And the idea, once we have that, it really provide us the ability to take that abstract abstraction and turn it into something a little bit more and allow individuals to inject arbitrary processes into it. So the example in the article was this cellular-like worker manager, but one of the other big use cases that we see a lot with Seneca are people that are trying to build chatbots, maybe something for Discord or something like that. So this would really make it very simple for you to run both a web application and a chatbot all from one process and have it all managed without having

to scale out multiple instances. Nice. Yeah. Yeah, so does it, when you run these worker processes, can it run in, does it run in a background thread? Or one of the things when I first talked about this that was a little unclear to me is, you know, once you have, when you go into production,

you farm out to a bunch of worker processes, typically, right? You know, you say like, we're going to run four worker processes and they're all going to, you know, round robin, handle these requests. But how does that management correlate back to these worker processes?

Because if they all are kind of managing their own, then you're going to end up with a whole bunch of them. Correct. So when you start up the application, and this actually is the whole reason, you know, going back to Brian's thing from earlier about, you know, trying to keep things out of the global scope. And why I encourage people to do that is under the hood, you know, we're using the multiprocessing from the standard library. So, you know, it's very easy to make some mistakes. And if you've got some code that is kind of sitting in the global scope, you might accidentally run it in all these different work processes that you don't necessarily want it to. So trying to keep your abstractions nice and tight and keeping everything instead of functions and callables kind of avoids that. So to answer sort of your question is when you start up a worker process, there's two kinds, right? There's the processes that are meant for

for Sanic servers and then for anything else that you might want. The reloader is going to be one. We also have in the extensions, we also provide out of the box an inspect utility. So it basically would give you a CLI command line utility that you can sort of check the status of any operating workers. So you can see, you know, how many things are running. If you wanted to sort of see, you know, how many requests are on each of the workers, you could kind of, you know, get that information. That's so hard to tell in production. You're like, it's kind of slow and this one seems stuck, but I don't know what the heck's going on. Absolutely. And this is really sort of the thing that this has opened up because what happens and for anyone that's ever done anything that's using multiple processes in Python,

one of the things that that the package does provide you is these different primitives where you can short share state between them. And in older versions of Sanic, there was no way that you could do that. But one of the things that we now have is you could have, say, one queue object, and every single one of your workers is able to push and pull information from that queue. You can have shared counters and it really kind of gives you a lot more flexibility that just didn't exist before. Cool. Well, it looks fantastic. And the other thing that you put in here is cashews.

How's cashews related back to this? It's not related back to this at all. This is just something- This is your second topic, right? Yeah, yeah. Okay, sorry. I put it in the wrong order then. We'll come back to that one then. Sorry. Okay. Awesome. All right. Well, this is just something. This is your second topic, right? Yeah, yeah. Okay, sorry, I put it in the wrong order then. We'll come back to that one then.

Sorry, okay. Awesome. All right, well, this is really cool. And it's something that a lot of web frameworks don't have is this ability to richly manage stuff that shouldn't be processed during a web request. And a lot of times people end up running whole different servers,

you know, Redis plus Seldry or something fairly complicated. So this is really cool that it's kind of like tightly tied together there. So one actually kind of use case that just kind of give people a little bit of understanding of how you might actually use this in production. So I use Celery very heavily as well as Sanic. One of the things that anyone that's used Celery knows about is there's this service called

Celery Beat. And basically the idea there is you're sort of scheduling these cron-like jobs that are going to run periodically over some defined schedule. Well, when you put all these things into Kubernetes applications, containers, your DevOps guys come knocking on your door and say, how do I know that this thing is still running? Like, I want to be able to ping this and make sure that things haven't died. And so that, like Kubernetes, that's sort of the, one of the things that it does for you, right, is it kind of checks the health of your applications and kind of restarts things. And it's very simple to do from a web application, not so easy to do from a service like Celery Beat. So what we did is we built

Celery Beat into a Sanic worker process like this. So basically what it does is it's kicking off these jobs every, I don't know, say every 10 seconds, some period, and it's sending a ping, HTTP ping over to the Sanic service that's running it. And then we can keep the state there. And then it's super simple for Kubernetes at that point to sort of see

what's the health of this application and is it still running? Yeah, very cool. That's a really interesting news. Awesome. All right, Brian, can we talk about our sponsor this week? Yeah, let's.

Awesome. All right, well, this week, once again, we have back Microsoft, such great supporters of the show. And if you've not yet checked out Microsoft for Startups Founders Hub, you definitely should. As we all know, starting a business is hard. They provide a bunch of support, both in financial grants for compute and other cloud services, as well as access to a mentorship network and other types of advice, basically, and connections.

So it's a free service. All you have to do is apply. You don't have to be third-party validated. You don't have to be VC-backed. You just apply, and then once you're in, you're in. And unlike the requirements that go live in San Francisco, Silicon Valley, New York City, one of these places where there's a community of founders and mentors and experts, you get access to a similar network from wherever you are. So it's not about who you know, but or who you

have access to because you can use their network. So they give you access to hundreds of mentors across a range of disciplines like idea validation, fundraising, management and coaching, sales and marketing, and a whole bunch of specific technical stress points. And you'll be able to book a one-on-one meeting with these mentors, many of whom are former founders themselves. And it'll really give you a leg up making connections and keeping your company on the right track. In addition to that, you get a bunch of Microsoft Cloud credits, a bunch of GitHub credits. They partnered with OpenAI,

a global leader in AI research and development to provide exclusive benefits there as well. To make your idea a reality with the critical support you'll get from Microsoft for Startups, join, as a join, just visit pythonbytes.fm slash Founders Hub 2022.

The link is in your show notes. So as always, thanks to Microsoft for supporting the show. Yes, thanks. Bye, Brian. What's next? Well, I wanted to touch on FastAPI a little bit. And specifically, there was a new release that caught my attention. So the 0.87.0, we should bug them about being zero verse still.

Um, but so yeah, come on. It's, it's definitely production ready by now. Um, so anyway, uh, well, so what I wanted to talk about is some of the, some of the interesting bits here, which I thought was really kind of cool of Sebastian and others to, to handle. So one of the things is they upgraded to Starlet, and I think it's Starlet 0.2 or something. Anyway, I'm not sure which version of Starlet,

but the Starlet version they changed to had a test client update and updated from requests to HTTPX. And that's pretty interesting. So FastAPI gets that also. But what happens with that is the test client actually had some breaking changes with it. And somebody named CluedX said, or just decided to create a tool called Bump Test Client. And this is pretty cool

because the idea is you've got some test code already that depends on test client and you can run this Bump Test Client on your test code and it upgrades it to the new interface. Cool as that. That's just pretty cool. That is cool, yeah. Nice extra bit of upgrade help for people.

The other thing I wanted to point out is that there's a lot of documentation changes. So there's one of the things he added was a help maintain fast API. I say he, but I think there's a lot of people working on fast API now. So I'm not sure who added it, but help maintain. And I think this is really pretty great, because see if I can find it. Yeah. It's focusing on like this section of how help maintain it focuses on a couple things that people don't think is very glamorous, but it's hugely helpful for open source projects. And that's helping with the issues. Because a lot of a lot of issues are

really just questions or a user doesn't understand how to use it or they're using it in a weird way. And it's just a knowledge gap thing. So helping those people out, great help for the maintainers so they can focus on building new features. Also kind of helps to point out maybe that there's documentation holes.

The other bit is reviewing pull requests. And both of these topics pop into bigger sections. So like the helping with GitHub issues, talk about how to do that. So there's some documentation on how to help, like understand the question that somebody's asking and maybe change the question if it's not clear. Trying to reproduce other people's problems,

suggesting solutions. You know, if you think that it's been solved by somebody, if it's solved, but it's still open, ask if you can close it. These sorts of this sort of help, especially with large projects, helps a ton. And so I think it's cool that this has been focused on. The other thing I wanted to point out, which I thought was cool, was we covered Ruff earlier on one of the other episodes, and it's a Rust-based linter, but FastAPI is now using it internally to lint their FastAPI code. So that's kind of fun. Yeah, that's fun. Now, one of the reasons why I was looking at this is coming back to the little project

PyTest check that I'm working on. I'm refactoring it. I also thought the readme is lame. So I was looking at the FastAPI readme, which is pretty interesting. And so I'm looking at different readmes to see if getting inspiration from others. And the FastAPI readme is an interesting thing that I don't think I've seen in very many other open source projects. There's the there's a logo, of course, and then some links to documentation and source code, which actually,

I think are really handy to have right there at the top of the readme. And then some features of why key features why you'd want to use it. but it really feels like a sales page also somewhat, but the, the, the sponsor list is interesting. It directs right to some of the direct sponsors of the project and having sponsors that actually show up in the read me and look, tech talk, Python training is there too. Uh, so go Michael, but the, the, that's an interesting way to, you know, pay for large open source projects. Kind of cool idea. And then opinions, like people that liked it and references. This definitely feels like a single page.

Before it gets into the meat of the normal stuff that you kind of see in a readme, it's like a sales pitch page or a single page landing page. And kind of maybe that's what a readme should maybe be to try to encourage people to use it i mean we're not buying a product but we we do gain uh it is growing a project if more people use it so selling them on the project it's kind of a cool idea yeah i think that's great uh a couple thoughts i have here okay one just uh on the sponsor thing that's one of the reasons it's really appealing to sponsor FastAPI is the visibility that you actually, it's not much,

it's not much to get a link back to your site, but it's a little bit and it's better than just the good feeling of, well, I paid to support this project and maybe buried in the contributors.md somewhere, there's like my company name, but no, it's like a little bit of give back and we get some traffic from that and it's really nice. And I no it's like a little bit of give back and you know we get it

we get some traffic from that and it's it's really nice and i think it's one of the things that other projects could do that have decent sponsorships is just to give a little visibility back like that um i think it's working really well for sebastian because you can see i'm not the only one up there and my company's not and then there then there's some of these listed here, but then if you go to the documentation page, it has like even more sponsors. Right, exactly. Those are like the gold sponsors that get the picture.

Then too, I'd like to hear Adam's thoughts about sort of marketing your web project and presenting it in this way because with Sanic, you're in a pretty parallel situation. Yeah. I mean, absolutely. We do. I agree 100%. It's definitely a sales pitch and to your point about, you know, you're not necessarily buying anything, but you're, you're buying into it, right? You're, you're buying into the project is, you know, you're, you're,

you're the, the ideas you're starting to build something. And so you're going to be putting a lot of investment into that. So, um, you know, I think it's sort of, you know, especially with, with some, uh, some types of projects, it's a little bit more important than others. Um, that if you need to specifically kind of buy into a specific philosophy and how you're going to be building something with it. So, so absolutely. We have do something a little bit similar, trying to make sure that sponsors have a little bit, have some visibility as well. So I think, but, and this is actually one of my pet peeves.

One of the, in my opinion, one of the most important things you touched on it is putting those links up at the very top. You said that, you know, there's a link to the source code and the documentation. And the source code, I feel like, is the one that's almost always missing. You know, usually these readmes don't just show up in GitHub, right? They show up on pypy.org. You know, maybe they show up in, you know, the, show up in read the docs if that's where it's going to. And it drives me nuts when I land on some sort of documentation website or something like that, and I can't get back to the source code. So I love to see that right up front, the catchy logo. You go and say, edit the documentation in GitHub

so that you can navigate back up the tree. Like that's probably my easiest way back, right? That's not how it should be. That's what I do. And exactly. And you end up on some page, you know, 10 levels deep inside of the project and that's not where you want to go.

Yeah. So Sanic looks like you got it right there. You got source code. Also, many of the, so a lot of people don't know this, but a lot of, on PyPI the home page often links to the github repo it doesn't have to people can link it to whatever they want to but um this this off often links to the source code but yeah the source code right there on sanic it's pretty good hey you got sponsors too neat yeah i see the i see the image isn't loading there so maybe i need to look into

that but uh well i think it loads on uh on the the github thing but okay that's good yeah um but what while we're looking at readme is the i want i did want to also mention uh will because you know we have to uh well it's tuesday yeah um so one of the cool things that he's got on both. Is he on Mastodon yet? Yes. I believe so, yes. Yeah. Okay. So on both Rich and Textual, there's a feature in their readmes of these drop downs.

So you can open up a section that maybe, like this, the Rich library talking about different ones, it would be kind of overwhelming to have the whole thing listed here, but having them collapsed is kind of a neat idea with little things. So, and one of the great things about readme is I don't know how he does this, but I can go find out because it's all in open source.

I can just look at the readme code and see how it's done. I believe, yeah, I believe it's a GitHub specific thing. So I'd be curious actually to see how that might carry over to like pyi.org or something like that. Well, look. Let's see if it works. So yeah, bear with us.

We're looking at to see if the dropdowns work on PyPI. And they seem to. So neat. Amazing. It's a 2E embedded in a Webby. And I have seen this other places too. I think, I can't remember where, but there's a couple of other open source projects

that use these dropdowns that I've seen. So there, that's probably enough on this topic. No, it's not Brian. No, it's not. No, it's not. I just want to put out a call to people because I tried this on the social medias and it didn't really get me far.

And maybe it's just going to go nowhere. I want to do a TalkPython episode on awesome tools for managing your readme and your changelog and like release notes and stuff. I think that'd be fantastic. I know there's things like release drafter and others, but none of them are big enough to be their own show. So I wanna do like a set of,

like here's a bunch of cool tools that you can do. So if people are using some, please just tweet them to me, toot them to me, email set of like, here's a bunch of cool tools that you can do. So if people are using some, please just tweet them to me, tweet them to me, email them to us, however you want to get them to me. I don't, that's fine. But it'd be really helpful if I could find, you know, five, 10 of these things. And then we could do a really cool show about like how to automate and do a bunch of these cool things as well as just talking about what you got here. I'll definitely send you a couple ideas. Awesome. I bet you got some. Yeah, cool. All right. And now let's talk about this thing

that Brian Skin sent in. Brian's been on the show before. Thank you, Brian. And he said, if you don't know, Closember dev is coming up soon. So Closember, like December, closing on December, closing open source issues and other work on december however you verbalize that it's live and so the idea here is let's open let's support

open source maintainers by helping them close issues and prs through november i said december i guess it's november so we're halfway through and it's a month-long initiative for maintainers and contributors and open source enthusiasts to go through and encourage healthier open source practices and raise awareness about maintainer burnout. So it's not about asking maintainers to do more, but it's like, how can we come in and do some of the tending of the garden and the cleanup of things? You know, when I go to an open source project and I see, oh, there's PRs for the last three months and they're all open. And like, I probably don't want to contribute to this because the chances are it's just going to be another thing sitting there for months and it's going to get ignored and I

don't care. Right. I mean, I want this change, but not enough that I'm going to do the work when there's a 90% chance that it's not going to get integrated. Right. I feel called out. No, no, no. chance that it's not going to get integrated. Right. I feel called out. So the idea is like, well, let's go and kind of help people with these aspects of it. Right. So there's it, it talks about it being a two-way street and trying to do some of the healthy,

healthy things, help people. Right. It also laments my challenge of like stale PR. So it has two aspects. It has for maintainers and for contributors. So for maintainers first, it says, keep in mind that the fundamental point of Closember is maintainer health. And so take care of yourself, you know, go diet, exercise. Also has some really interesting things about decluttering your digital life. I think that's actually really interesting. I mean, we all just kind of have cruft build up, cruft on our physical desk, cruft on our computer desktop, cruft in all the email and other things and really cleaning those things out. It's really nice. I just formatted my Mac

Mini after two years, about three days ago. And it's like, I got a brand new computer. I'm like, oh, I love to sit down with this thing. There's no new computer here. It's just the junk is gone. And so I think that's an interesting angle. It talks about what you can do to help as a maintainer facilitate this. So you can get people help with triaging, with infrastructure, with technical writing, for example, like that toot thing. If there was a tutorial or any form of example or any form of example or any line of code anywhere that said, here's how you use it, it would be way more used than if it's just, here's its name, good luck, you know? And so having somebody do a little technical writing or put together a tutorial or even translation, all those would be really,

really fantastic, right? So the idea is if you're feeling up to it, you can identify some areas that would benefit from that. You can edit your readme to have and create a close number issue to let people know that this is an option. And you can actually go over here and see that right now there's 729 repositories, like some that come to mind that are, this is a search for all languages. It just happens to be Python's right at the top for all of them. So TQDM, NumPy, iPython, SciPy, Notebook, Spider, Volium, like all of these are Python. I don't really understand how that's happening, but

maybe it's maybe the algorithm. Anyway, like you could go to any of these that inspire you and pull these up. All right. So that's on the maintainer side. It's like some things that you can do to help set it up, right? Just like label things and so on. And then on the community side, it says first, this is going to be on GitHub or GitLab. You need to know Git. So take a moment and learn Git

because this is how you work with these things. And able to just like run the tools, right? Like if I'm going to help you build a house, I should know how hammers work, right? At least a little bit. So then it says you can start taking a look at GitHub issues that maybe you've opened and see whether or not they're outdated

or you could close stuff that you've sort of put out there in the burden and then go through that list like I talked about. And yeah, then finally, there's like a celebration close boards. So down here, you can see there's a overall, there's like a scoreboard type thing. It says overall, there's of the 16,531 issues and PRs, 496 have been closed. And then there's like a scoreboard of the closed issues by project.

So like Datalad is the number one and then AstroPie is just right behind it. SciPie is up there and it tails off from there. So anyway, thanks Brian Skin for sending this in. And people who want an angle to get into open source or want to contribute a little bit more, especially with some holiday time coming up, here's something you could do that might mix up what you're doing.

Yeah, absolutely. One of the things that I try to do as much as I can, um, is try to advocate for people to get involved with sort of the small things, you know? And so I try to make, you know, if somebody is going to come on, you know, and create an issue, I say, well, great. No, you, you can go, you can make this PR. This is how you can go about and do it. So, so, um, as, as a maintainer, I think, you know, these types of, uh, go, you can make this PR. This is how you can go about and do it. So as a maintainer, I think, you know, these types of projects, there was just one also in October.

There was a Hacktoberfest. Yeah, Hacktoberfest, yeah. So I guess maybe something's coming in December, but. Hacktoberfest, I think, is a little more about creating, like creating your first PR or making your first contribution. This is more about like, I think, clean up and closing out. Yeah.

All the people from Hacktoberfest create a bunch of PRs and now they're closed. Yes, I participated in both. There you go. One of the things that I wanted to point out is we did talk about the, how to help, how to help maintain fast API. So that would be all of actually all the tips that I read on how to help maintain FastAPI. So that would be all of, actually all the tips that I read on how to help maintain FastAPI apply to every open source project.

So if the open source project that you're interested doesn't have really good how to help tips, the FastAPI stuff applies to almost everything, like reproducing bugs, answering things. And sometimes it's obvious from like a pull request or an issue that nobody's really excited about this thing

and maybe it should just be closed. So that's helpful also is to just bring that up and say, hey, core maintainer people, this seems like it should be closed. Should we go ahead and close that? So actually on that point, I won't necessarily name names here, but there was a project that, not one that I maintain, but it's a project that was talking about retiring a specific feature. And it was sort of, no one's really using it.

It doesn't really seem like it has very much activity. And they just put a little notice up there. And just because people were engaging in conversation and because people were looking and were willing to write a couple of lines, or even in GitHub where you go and you just click a little thumbs up or whatever, they saw all this interaction that people do care about this feature. And it really does impact you know as a maintainer if you you know the more people that are engaged in in discussion um uh the better it is to decide you know sort of how to steer the ship yeah absolutely yeah maybe it's just hey somebody suggested this i'm not sure what does the community think right having having an opinion might be helpful right there yep

absolutely all right you know what else is helpful? Cashews. Well, they're definitely delicious, but... They are. So this popped up in my, you know, you go into GitHub, there's the explore feed. So it just was in the top of my feed and it really caught my eye just because this is the type of thing

that I find myself building and rebuilding on every single project that I do. So basically, at its core, what Cache uses, it calls itself an async Cache framework for a simple API to build fast and reliable applications. And when you look at sort of what they're providing you out of the box, it's a very feature rich, but it's super simple to get it up and running. I think you just really basically need one line to call a setup. And after you do that, you're just adding decorators to stuff. And I think this is really sort of provide some really good foresight on how to build a very nice, clean API that can be used in a lot

of different situations. So on their GitHub Remake, which I think is pretty well done, it gives you sort of how you might use this on a typical web application to cache some information on the request. But you could really use it in a whole bunch of different features. So a couple of different things that really struck me as really interesting is number one, they provide support for doing in-memory caching, also Redis, which is very, very common, and also a write- a write to disk, which I believe uses SQLite. We talked about disk cache, which is, it looks like the foundational thing probably for the disk version of that caching. And also DIL. Instead of pickling, you DIL things.

So you can store more, a wider variety of items into your cache, which is kind of cool. I'm not familiar with Dill, but it sounds like it's probably good. Yeah, I don't know how much, you know, you combine Dill and cache use on a normal basis, but I guess it could be done. No, but so one of the things that I think is really neat that they built into this is there's a cache

on top of a cache. And what I mean is, you know, let's say you're, you know, putting all this information, these really expensive operations into Redis or disk cache or something like that. They also have what it looks like is maybe an in application memory cache where you don't even necessarily need to go do those network calls every single time that you want to go fetch data.

And I feel like sort of, you know, there's sort of like that old saying that in computer science, there's two hard things in computer science. There's cache and validation, naming things, and off by one errors, right? Exactly. So I feel like they sort of like are solving some of these problems and they've got a couple of really simple ways that you can you can do cash invalidation in ways that you can. It just it really strikes me as a very well thought out package. But one of my favorite things that I noticed is one of the ways that you can invalidate a cache is by rate limiting. Well, rate limiting is itself a huge area,

especially for web applications. And if you use a package like Caches, you're getting two different requirements for one right here because it can do double duty for you. So I think this is, I haven't used this yet, but it looks super clean. It looks like a very nice, very intuitive, and I'm pretty excited to try this one out for sure.

What an interesting kind of negative cache this rate limit thing is. So the idea is if you call it, you can put it onto a function. So if you call this function more than 10 times in a minute is the default example there, then you basically get banned from calling it for a while. So instead of saying, we're going to scale it by saving the answers to the questions you're asking to this function, we're going to save performance and CPU availability and whatnot by only allowing you to call too much.

And if you do it too much, like you're done, you're out. Similarly with circuit breakers for errors. If there's too many errors, it's just going to stop for a while. Yeah, exactly. And there's also this, there's also, you know, I kind of glossed over it, but one of the things that they did for cache invalidation is there's sort of this, because it's using async I under the hood, it looks like it's got this ability to sort of refresh your cache automatically. So one of the things that you often have problems with caches is, you know, you might have stale data in there

that you want, you know, how do you get rid of that stale data? And so you can basically set up, it looks like, like, you know, in the background, it's, it's called early, early refresh or something like that. And, you know, what it'll, you know, in the example that they give you, you know, if you've sort of, you know, called this, you know, within the given time period, it'll automatically go and sort of refresh it for you in the background, which I think is really cool. Yeah. Okay. So this one says, I want the cache time to be 10 minutes, but if it gets called on minute seven to nine, in terms of the age of the cache result, go ahead and recompute it so that in the background, right, give them the answer that that's cash back, but then actually call it so that you, cause you know, if it takes 30 seconds to compute this thing or whatever, right? It takes a long time.

Every now and then there's going to be those gaps where it expired and you hit it again, right? And so here's a way to kind of preempt that. So nobody sees the slow version. There's a lot of interesting ideas here. Yeah. Way to go, Cassius. That's cool. That's pretty cool. Yeah. Yeah. Very cool. Awesome. Well, good find, Adam. Brian, how about our extras? Yeah, how about them? I don't have anything extra. Do you have something?

Let's go to Adam. Adam, anything else you want to give a shout out to while you're here? Sure. I just noticed that definitely voting season is here. There was just a big vote in the US. I live in Israel. We just had an election season here, but now we've got Python elections coming up. So nominations for the Python Steering Council are open. I think the way that it works is that you have to be a core member to do a nomination,

but anybody that wants to can go on to their discourse. And if there's a candidate that you support, you can reply to the comments, you can engage in the conversation. And I think that's really cool and really a super way for people to sort of engage with the larger community. Yeah, very nice. And I actually have something related to that.

Where is it? It's hiding. The, I have to pull it out of my notes. Maybe I didn't pull it up. But the PSF survey. Oh yeah, here it is. It's just, uh, there, David Lord put this out here. Uh, speaking of web frameworks, we've covered them a lot. Let's bring flask into it as well. So, uh, over here on Mastodon, David says, take the PSF developer survey. It's closing in a few days. Uh, that was yesterday.

So people should go and do that if they haven't. Pretty sure I already did. I don't want to vote twice, but I also don't want to not vote. It's a dilemma. So anyway, it's really great that David put that out there. So another thing, it's not quite voting, but it's, you know, tallying your opinion there. All right. I got a couple other things. Also quick, you know, shout out to your book while you're here, Python Web Development with Sanic. People can check that out as well. So excellent. Let's see. This one.

No, that one is just a joke. So I think actually, Brian, that's all I got for extras. So you ready for a joke? I am. All right, over here. Again, I wish I could pull these up separately. I have to log out,

but then I can show you the other stuff. And by the way, Samuel Coleman just showed up on Mastodon as well. He wasn't there yet. So people go of pydantic fame. So when all this stuff with Twitter came out, I thought this was a pretty hilarious. You remember there was the switch of what did it mean

for the blue mark, the blue check mark to be on an account. It used to mean that you were verified and there was lots of rules about like showing your ID and having a Wikipedia page. And there's like rules to get that check mark. And then Elon said, well, we could just pay for that. And a bunch of people started impersonating people and doing all sorts of funny shenanigans. Well, this, this is breaking here. Um, we've just noticed on Twitter that the JavaScript verified account that it's the program, the, the, the twitter name is real programming language with 51 million

followers and there's a big message on it brian what's the message say it's it's been canceled suspended account suspended twitter suspends accounts that violate the twitter rules javascript has been banned from twitter for impersonating a real programming language. I love it. Yeah, that's funny. Yeah, it's pretty good. All right. Well, that's what I got for you this week in terms of jokes. JavaScript has been suspended on Twitter.

You know, and I just, speaking of Twitter, just if you want some humorous news, just Googling Twitter on Google News is hilarious. Just to me. I mean, it's also sad, but also funny. Yeah, absolutely. Well, Adam, thanks for joining us this week. And congrats on Sanic. It looks like it's been going strong for a long time. And it's got quite the community there.

Thanks for having me. Yeah, we've been maybe going strong since 2016 or so. Wow, that's awesome. All right, Brian. Thanks, everyone. Thanks for being here.