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 Okken.
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.
Yeah, that's exciting. I remember when you guys started it.
So, this is a great resource for the community.
Cool. Thanks.
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.
Fun stuff, it sounds like.
Yeah, absolutely.
Cool.
Yeah. Well, Brian, you want to kick us off with our first topic here?
Yeah, sure.
So, this is a little bit of an easy topic.
Tips for clean code in Python.
This is from Bob Bilderbos from PyBytes.
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.
You know, I'm kind of on the fence on the void.
Avoid global scopes the third.
But 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 narrowing is a good thing.
Actually, I'm not going to run all 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 units.
Because I just ran into this.
So, I'm working on refactoring the pytest-check plugin.
And currently, 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 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 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 in mind, too.
And sometimes breaking it up.
You can go too far, too.
If you've got like 100 different modules that all are like 10 lines long.
That's too far.
But, you know.
Yeah, I really like the idea of smaller units in 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.
Like if it's 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 looking at it and I don't understand it.
How can I.
How can I make it easier to understand?
Like 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, for 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, you know, sometimes I feel like when I've done that, even trying to iterate in 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 focusing on features.
So I'm trying to keep the like, for instance, the one of the functionalities for pytest-check is stop on fail working correctly.
Because you possibly could have multiple failures in a single test.
So how does stop on fail work?
Well, 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 it 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.
Pre-commit.
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 Python 2 to 3.
What was that?
Py upgrade, I think.
Yeah.
Whatever you.
Yeah.
Those types of things.
A lot of this stuff could be brought in on the toolchain level too, which is kind of nice.
All right.
Let's talk about Mastodon.
So I don't know if you all 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 I'm super psyched about it.
I just did a Talk Python episode, but I'll pull up a link to that in a moment.
But 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 till people show up.
But they're there.
They're there.
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 Bytes on Mastodon.
They can follow Python.
I'll put a link to all of the various, all of our profiles, including Adam's 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, we'll kind of just, you know, trudge through it and see how it works.
But I definitely agree that it's, it feels very, it feels clean.
Like it just feels like very, you know, fresh.
Maybe it's just because it's a, you know, a new app to play with or one.
I don't know.
But there's, I agree.
It's, I'm very happy to see that, you know, people that I'm already, you know, subscribed to and trying to see what they have to say are already there.
And you're definitely interested to 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, I think it's, it's really interesting and I encourage people to check it out.
I was going to highlight that Marco out in the audience said, me two weeks ago, is Mastodon good enough to replace Twitter?
Me now.
Is Twitter good enough to replace it for Mastodon?
Yeah, I'm, 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 a, 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.
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 Bitward 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,
I feel like we should be doing this.
Like 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 Mastodon.
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 we need to make sure that the people who are the content creators, people that have large followers and are putting out information that people want to read, make sure that they're supporting this as well.
Because where the content is, that's where the people will go.
Yeah.
So hopefully, hopefully we can get more people paying for it and supporting it.
Yeah.
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.
You cover it.
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 is 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 from 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.
Nice.
I think actually I might have pushed the one for Talk Python 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.
I still can't get over that.
It's just funny.
It's a little much, isn't it?
All right.
And then 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 Fostadon because I was on Fostadon.
But if you were on, you know, 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 that out.
Yeah.
So I encourage people to check this out.
One more thing on toot.
We'll come back to close Vember 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, kwr, callable.
Or so 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 do it, like it doesn't have any functions or anything you can call.
So how it's used, I have no idea.
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 HTTPX or something.
So to, 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.
Yeah.
Nice.
All right.
Yeah.
Well, people definitely should check that out.
Adam, you're up next.
All right.
So I guess, you know, a little bit of a backstory to, you know, 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 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-wiz gear or G-in-a-corn or something along those lines?
Correct.
You can use something like uvicorn if you wanted to.
So it can operate as an ASG I-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 sort of different patterns and how you might build
production applications in it with Sanic and sort of what are some of the possibilities
that are sort of 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, Sanic 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 a 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 provides us the ability to take that 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, you know, one of the other big use cases that we see a lot with Sanic are people that are
trying to build chatbots, you know, 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 multiple instances.
Nice.
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, you know,
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, is under the hood, you know, we're using the multi-processing
from the standard library.
So, you know, it's, it's, it's very easy to make some mistakes.
And, and if you've got some code that is kind of sitting in the global scope, you might accidentally run it
on all these different worker processes that you don't necessarily want it to.
So trying to keep your abstractions nice and tight and keeping everything's instead of functions and callables
kind of avoids that.
So to answer sort of your, your, your question is when you start up a, a worker process, you know, it's,
there, there's two kinds, right?
There's the processes that are meant for, for static 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, a,
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.
That's cool.
Um, 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.
Um, and in older versions of, of, of Sanic, there was no way that you could do that.
Um, 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.
Um, you know, you can have, you know, shared counters and, 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.
What, how, what's the, 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.
Okay.
Sorry.
I put it in the wrong order then.
We'll, we'll come back to that one then.
Sorry.
Okay.
Awesome.
All right.
Well, this is really cool and it's, 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 celery 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, that just, just kind of give people a little bit of understanding of how you might actually use this in production.
Um, so, so, I use celery very heavily, as well as Sanec.
Uh, one of the things that anyone that's used celery knows about, is there's this, function, this service called celery beat.
And basically the idea there is you're, you're sort of scheduling these crown like jobs that are going to run periodically over some defined schedule.
Well, when you put all these things into, you know, Kubernetes applications, you know, 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.
Um, and so that, like Kubernetes, that's sort of the, one of the things that it does for you, right?
Is it, 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.
Um, so what we did is, we built celery beat into a Sanec 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, some period.
And it's sending a ping, HTTP ping over to the, to the Sanec 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, 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 and 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 requirement to 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 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.
To join, just visit pythonbytes.fm/founders hub 2022.
The link is in your show notes.
So as always, thanks to Microsoft for supporting the show.
Yes, thanks.
Hi, 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.
But so, yeah, come on.
It's definitely production ready by now.
So anyway, well, so what I wanted to talk about is some of the interesting bits here,
which I thought was really kind of cool of Sebastian and others to handle.
So one of the things is they upgraded to Starlet, and I think it's Starlette 0.2 or something.
Anyway, I'm not sure which version of Starlet.
But the Starlette 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 Cluedex 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 one of the things he added was a help maintain FastAPI.
I say he, but I think there's a lot of people working on FastAPI now.
So I'm not sure who added it, but help maintain.
And I think this is really pretty great because let's see if I can find it.
Yeah.
It's focusing on like this section of help maintain it focuses on a couple of things that people don't think is very glamorous, but is hugely helpful for open source projects.
And that's helping with the issues because 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 a poll reviewing pull requests.
And both of the both of these topics have 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 is asking and maybe 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 lend to 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 pytestCheck 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 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 key features, why you'd want to use it.
But it really feels like a sales page also somewhat.
But 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 readme.
And look, Talk Python training is there, too.
So go, Michael.
But that's an interesting way to 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 do gain.
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.
A couple of thoughts I have here.
Okay.
One, just 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, you know, we get it.
We get some traffic from that.
And 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.
Yeah.
I think it's working really well for Sebastian.
Because you can see I'm not the only one up there.
Am I coming in?
And 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 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 buying into it.
Right.
You're buying into the project.
Because, you know, the idea is you're starting to build something.
And so you're going to be putting a lot of investment into that.
So, you know, I think it's sort of, you know, especially with some types of projects, it's a little bit more important than others.
If you need to specifically kind of buy into a specific philosophy and how you're going to be building something with it.
So, absolutely.
You know, we have do something a little bit similar, you know, trying to make sure that, you know, sponsors have a little bit, you know, 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, you know, read the docs if it's getting, if it's, you know, 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, you know, that, so, so I love to see that, that right up front.
You know, the catchy logo.
You go and say, like, 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 what I do.
And exactly.
And you end up on some page, you know, 10, 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, a lot of people don't know this, but a lot of, on PyPI, the homepage often links to the GitHub repo.
It doesn't have to.
People can link it to whatever they want to.
But this often links to the source code.
But, yeah, the source code right there on Sanic is pretty good.
Hey, you got sponsors too.
Neat.
Yeah.
I see the images and load in there, so maybe I need to look into that.
But.
Well, I think it loads on the GitHub thing.
Okay, that's good.
Yeah.
But while we're looking at readmes, I did want to also mention Will, because, you know, we have to.
Will McCugan.
It's Tuesday.
Yeah.
So, one of the cool things that he's got on both.
Is he unmasted on yet?
Yes.
I believe so, yes.
Yeah.
Okay.
So, on both rich and textual, there's a feature in the readmes of these dropdowns.
So, you can, like, 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 readmes 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, PyPy.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.
Oh.
Neat.
Amazing.
It's a TUI embedded in a Webby.
And I have seen this other places, too.
I think, I can't remember where, but there's a couple other open source projects that use these dropdowns that I've seen.
So, anyway.
That's probably enough on this topic.
No, it's not, Brian.
No, it's not.
Okay.
Let me just, 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 Talk Python episode on awesome tools for managing your readme and your changelog and, like, release notes and stuff.
I think that would 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 want to 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, tweet them to me, email them to us, however you want to get them to me.
I don't, that's fine.
But it would be really helpful if I could find, you know, five, ten 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.
Cool.
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.
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, Closeember dev is coming up soon.
So, Closeember, 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 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 .gitignored 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.
So, the idea is like, well, let's go and kind of help people with these aspects of it.
Right.
So, there's, it talks about it being a two-way street and trying to do some of the healthy things to help people.
Right.
It also laments my challenge of like stale PR.
So, it has two aspects.
It has them for maintainers and for contributors.
So, for maintainers first, it says, keep in mind that the fundamental point of Closed Zember 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, like on our physical desk, cruft on our computer desktop, cruft in like all the email and other things.
And really cleaning those things out.
It's really nice.
Like, 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 at the sink.
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 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, 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 Pythons right at the top for all of them.
So, TQDM, NumPy, IPython, SciPy, Notebook, Spyder, Bolium.
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 this 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 on 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, overall, there's, like, a scoreboard type thing.
It says, overall, there's, of the 16,531 issues, NPRs, 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 AstroPi is just right behind it.
SciPi is up there.
And it tails off from there.
So, anyway, thanks, Brian Skin, for sending this in.
And, you know, 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, you know, 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 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's going to come on, you know, and create an issue, I say, well, great.
No, you can 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, you know, project, there was just one also in October.
There was a Hacktoberfest.
Yeah, Hacktoberfest, yeah.
So, I guess maybe something's coming in December.
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, cleanup and closing out.
Yeah.
So, all the people from Hacktoberfest created a bunch of PRs and now they need 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 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 in 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, you know, was talking about retiring a specific feature, right?
And it was sort of, you know, 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, you know, write a couple of lines or even in GitHub, where you go and you just click, you know, a little thumbs up or whatever.
They saw all this interaction that people do care about this feature.
And, you know, it really does impact, you know, as a maintainer.
If you, you know, the more people that are engaged in discussion, the better it is to decide, you know, sort of how to steer the ship.
Yeah, absolutely.
Maybe it's just, hey, somebody suggested this.
I'm not sure.
What does the community think, right?
Having an opinion might be helpful, right?
Yeah.
Yep, absolutely.
All right.
You know what else is helpful?
Cashews.
Well, they're definitely delicious, but...
They are.
So, yeah, 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, you know, at its core, what Cashew 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 up and running.
You know, 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, you know, I think this is really sort of, you know, provides some really good foresight on how to build a very nice, clean API that can be used in a lot of different situations.
So, you know, on their GitHub Remi, which I think is pretty well done, it gives you sort of how you might use this on a typical web application to cache, you know, 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 I kind of wanted to, that really struck me as really interesting is, number one, they provide support for, you know, doing in-memory caching.
Also, Redis, which is very, very common.
And also, 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, the disk version of that caching.
And also, dill, instead of pickling, you dill things.
So, you can store more, 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 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 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, you know, computer science, there's, you know, there's two hard things in computer science.
There's cache invalidation, naming, naming things and off by one errors, right?
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 cache invalidation.
You know, 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, you know, if you use a package like cache use, you know, you're getting two different, you know, two different requirements for one right here because, you know, it can, it can do the, you know, 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 to try to 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 of the example there.
Then you get, you basically get banned from calling it for a while.
So instead of saying, we're going to scale it by, 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.
Similar with circuit breakers for errors.
If there's too many errors, it's just going to stop for a while.
Yeah, exactly.
And, 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, for cache invalidation is there's sort of this, because it's using asyncioN under the hood, it looks like it's got this ability to sort of refresh your cache automatically.
So, 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, the, 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, you know, in the background, right, give them the answer that that's cash back, but then actually call it so that you, you know, if it takes 30 seconds to compute this thing or whatever, right.
It takes a long time, but 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.
Yeah.
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, is, is here. You know, there was just a big vote in, in the U S we, I live in Israel.
We just had an election season here, but now we've got Python elections coming up. So, 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, to do a nomination, but anybody that wants to, can go onto their discourse.
And, and, and, you know, if there's a candidate that you, that you support, you can, you know, you can reply to the comments, you can engage in the conversation.
And I think that's really cool and really, you know, a super way for people to sort of, you know, engage with the larger community.
Yeah. Very nice. And I actually have something related to that. Where is it? It's hiding.
So the, to pull out of my notes, maybe I didn't pull up, but the PSF survey. Oh yeah, here it is. It's just there.
David Lord put this out here. Speaking of web frameworks, we've covered them a lot. Let's bring Flask into it as well.
So over here on Mastodon, David says, take the PSF developer survey. It's closing in a few days. 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 is 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 was Sanic. People can check that out as well. So excellent. Let's see this one. No, that one is, that one's just a joke.
So I think actually, Brian, that's all I got for extras. So.
All right.
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 couldn't show you the other stuff.
And by the way, Samuel Colman just showed up on Mastodon as well. He wasn't there yet. So people go of
hydantic 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's 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. And 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.
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.
I mean, yeah, we've been, we've been going strong since, 2016 or so.
Wow. That's awesome. All right, Brian. Thanks everyone. Thanks for being here.