Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 236, recorded June 2nd, 2021. I'm Michael Kennedy. And I'm Brian Okken. And I'm Anastasia Timosuk. Hey, Anastasia. So great to have you here. Nice to have you on the show. Thank you for inviting. Yeah, absolutely. Why don't you tell people a little bit about yourself before we get into the topics?
So I'm joining from Germany, Berlin remotely right now. And I have a little one, a baby doc joining as well. You might hear him on the stream. I am originally from Ukraine. I'm not German. I moved to Germany around five years ago, maybe five and a half. And my passion is Python. I used to be a C++ developer, game developer, and so many more languages. But the best one, I think, for me is Python. So I decided to stick with it for around eight years now.
Oh, how cool. I started out doing my professional programming in C++. And I I know Brian still touches a little bit of C and C++ in his world. So that's cool. Yeah, it's half my life. Nice. And what kind of games? Well, they were adapted first for iPad. They were like two and a half D games. And then later on, it was mostly 3D games with Unreal Engine. Oh, cool. Yeah, that's awesome. All right. Well, once again, welcome. Welcome. So glad to have you
here. Brian, do I have the first item this time around? No, you do. Go for it. Okay. What do you got for us? Well, accessibility isn't really something I probably should think about accessibility more, but I don't really. But I probably should. So I was excited to see there was a tweet recently by Matthew Feikert that said, I need to give some serious praise to a fellow scikit hep dev, Hans Deminski, on his excellent monolens tool for interactive simulations of color blindness. So I checked this
out. So monolens is this is a Python package and you can pip install it. And as Matthew said, you can pip x install it. So you just always have it around, which is nice. And it just pops up this tool, this, this really cool window. And you can just, you just drag it around. And it makes the whatever the windows over all over your desktop, it just makes it black and white instead of color.
So you can see what it looks like in grayscale. So I, one of the things I really liked about this is, is the, the, the example showing it with, with Matt plotlib and plots, because plots are really where you're using color to distinguish between the two different sets of data. So you really kind of want that data to look different, even if people don't see color. So that's, that's an important thing. So that was neat. And then somebody that replied to that and said, Hey, I always try to use C,
C masher smasher. I'm not sure. It is a, to make sure they're colorblind friendly. So I'm like, I've never heard of this. So I went and checked out smashers. And what it, what it is, is it's a bunch of color maps. So you don't really have to think about it. So you, so there's all these great named color maps and they're, they're actually fairly attractive color changes, but the, it shows you what they look
like in black and white also. So they, this isn't, it's kind of a little demo what the top that we're looking at on the stream, but the code that you have to, you just, it's just kind of built into Matt plotlib already. Like it's an extent, it's also kind of an extension to Matt plotlib and other things that use color maps. So you can just say, when you're plotting, you can just specify a color map like rainforest or something. And it, it automatically is a colorblind, friendly
color map. So you can do your plots and have it still look nice everywhere. So. Oh yeah. This is really cool. And Matthew friend of the show. Thanks for sending that in. I never really thought about this and I should have, you know, I mean, I feel like maybe I should go over my websites and go, do they look terrible for people who have, you know, color vision impairments? Yeah. So really cool. And it looks like it's this independent thing that will just go over.
You just move your mouse around. It works on anything. It doesn't necessarily have to do with Jupyter or Matt plotlib or something like that. Right. Right. So the model lens is just a, it's just something that works on anything. I could, I drug it over even my desktop, my background, uh, and it showed, showed the picture in black and white. So, it is cool. The other thing is, wait, there's a color maps. I can just add to, Matt plotlib. That's cool.
Like rainbows and stuff. How neat. I didn't know you could just do that. So that's a, that's kind of a neat thing. And then you can like, for instance, the, the, one of the examples that they have on the CMASH or read me, is just, just sort of a simple plot. And when you're in Matt plotlib kind of just picks colors for you, unless you specify colors for different plot lines. but you can just, you can give it a color map instead of a, a specific,
uh, list for each item. so, and that just kind of nice. That's super neat. Yeah. Why not do it? Anastasia, what do you think? Oh, it looks amazing really. And it's super helpful. Yeah. when you were doing the video games, but that would be great to use it as well. For sure. When you were doing games, did you have to think about this kind of stuff? No, actually we were not that far at that time. It was around seven years ago, eight.
Yeah. So, yeah. The, on the, on the monolens site, one of the examples they show is using, um, having one of the plots use some sort of pattern underneath and not just color. And that's, that's, I'm not sure how to do that. So people that are great at Matt plotlib probably know how to do that really right away. But that's kind of a neat idea also to have like one of the, one of the graphs has hashes versus stars or slant lines or something like that.
Oh yeah. I have it like some sort of ASCII differentiator. Yeah. Yeah. Very nice. Yeah. This is super helpful. And Matthew again, thanks for sending in and, joy. Yeah. Welcome to the live stream. Thanks for, for being here for the recording. So the next one I want to talk about is something called rapid fuzz. Yeah. So last time I talked, when we had Vincent on, I saw the fuzzy, fuzzy, fuzzy, fuzzy text matching for that, that chat bot that he was showing off. I thought,
Oh, fuzzy, fuzzy is cool. So Mikel Honkala sent in a rapid fuzz and it's very much like fuzzy, fuzzy, but it turns out to be a whole lot faster and it uses some of the same ideas, but, you know, coming back to the, some of the things we were talking about, it is basically written in C++ using the Levenstein distance algorithm for words similarities, but obviously has a Python API that we all work with. And so, yeah, it's pretty neat. It's really easy to work with. You just,
again, pip install it. And then you can come down here and do things like fuzz.ratio and you can give it two sentences. This is a test or this is a test exclamation mark. And it says that's 96.5% the same or, you have fuzzy, fuzzy was a bear. I guess these are, yeah. Fuzzy, fuzzy was a bear. I guess those are the same. No, was he fuzzy. Oh, was he fuzzy. Yeah. I got it. I got to read better. Was he fuzzy was a bear versus fuzzy. Was he was a bear? Oh my goodness.
Uh, that's 90% the same. Given a bunch of, phrases, you can sort them by similarity. You can say, kind of use selection, like, you know, to call in sort of call center type of automation, given three choices and given some text, you can say, find which one, you know, like Atlanta Falcons, New York Jets, New York Giants, and so on. Somebody says, you know, lowercase New York Jets instead of uppercase, it'll say, well, here's the likelihood that that's a match, but here's another possible
match that's, you know, and it gives you the ratios of how good of a match it is. So if you've got a select set of choices and you're asking for input on it, you can just say, well, give me the closest match. And if it's anywhere close, you can just run with that. So yeah, pretty neat, right? That is pretty cool. Yeah. And the other thing that's interesting is the performance. And before people tell me that all, all benchmarks are broken and they don't work, you know, sometimes at least
they give you a sense. So here's some of the things that, they've got in terms of performance, save versus fuzzy wuzzy and the numbers are like 10 or 20 times faster. Definitely broken. It's definitely broken. I think it's because it's written in C++ instead of Python, at most of its core, you know, probably. But anyway, if you're looking for fuzzy text matching, fuzzy wuzzy is a good option. And apparently thanks to Mikko rapid fuzz is as well. So yeah, pretty neat. Yeah. We probably
should do a segment on benchmarks at some point. No, no, no, no, no, we should do it, but I've written blog posts and stuff on it. And it's just an endless battle of you're doing it wrong. Your situation is not my situation and my situation. It's not as good or it's worse or it's better or you're yeah. No, I, I hear you. It would be interesting, but at the same time. Yeah. Okay. There we go. We just had a section on, benchmarks. Yeah. I've already just explained like the emotional
trauma that I'll go through from receiving all the feedback now. And it's what do you think about this, fuzzy text matching? Well, maybe next time we can organize a battle between them. That's right. Yeah. We'll bring some in. Yeah, sure. Do you have any use for this fuzzy text matching, string matching stuff? Well, actually, yes, at work, we have, lots of, matching algorithms, but we're using, different tools and I'm not a data scientist person, but I would love to
try that actually. It looks super cool. Yeah. We, we use some C++ libraries. Yeah. Yeah. Robert out there in the live stream says we would have to benchmark the episode if we had an episode about benchmarking. You see, it's like recursion. Save that thought for the end of the show, by the way. All right. And Stacia, you're up next. Structured logging. Tell us about it. Uh, well, a few years ago, I, went to meet up and I heard a talk from my Marcus Holterman about
struct log. That's the first time when I heard about this and I decided to give it a try. And actually I fell in love with it. and I'm using it, since at least two and a half years, maybe two. it's awesome way to bring a bit of structure to your logs to make them more visible and more usable because usually how we log, it's like just one huge sentence, which is readable by humans, but it's not machine
readable. And the idea is here, to bring more structure, to build some dashboards based on, different keys and then values and then see what's actually happening with the system without touching the logs, without scrolling through the whole log. And then just reading all bunch of things. and I already used it in production. It looks pretty well. If, you try using JSON format, just fantastic. Oh, how cool. Yeah. You can pass it all these like processors and type stuff. So you can
say render out the print that, you know, stack info, the log level, all those kinds of things. That's neat. We added a bunch of, processors like custom made, which were specifically designed for our applications, which made a life of our devops parsing the logs way easier because they didn't
have to write them by hand. And if you use a structured logs for all applications, not just one, but, uh, for example, for example, microservices and you pass, the key ID or like trace ID or something that will identify the path, which, the log goes through, then you might see what happened before the bug happened or maybe because, if you want to see, how the system is working, you also need to be either one of the detectives of the system or use the struct log.
Yeah. It's interesting when you log out stuff, it looks like you can just do key keyword arguments and those will add to the log really nicely. So you don't have to create a message that you're going to send that embeds, you know, the value equal, you know, variable equals valuable, very equals value. You just pass them to the log message and they become part of the message like that. That's cool.
Yeah. And you can also use, the initial message, which is an event like greeted here, um, as some kind of key, which would give more clues where this message is coming from and what type of event happened instead of a usual message. Yeah. Nice. Very cool. The other thing it says is if you have Colorama installed, it will automatically render in nice colors and that's very neat. I love Colorama and I love
having colors in, in the code that we look at, it really makes a nice difference. So yeah, you get things like the colored, whether it's an info message or an error and whatnot. Yeah. Very neat. I like it. I keep meaning to use this more and I know I'm glad you brought it up because I definitely want to try this. Definitely try this. Yeah. Yeah. This is a really good one. This is new to me, but, quite neat.
All right. Not new to me, but also quite neat is our sponsor for this episode. So this episode is brought to you by Sentry. So how would you like to remove a little stress from your life? Do you worry that users may be having difficulties and encountering errors with your app right now? Would you even know until they send that support email? I mean, yes, maybe using struck log,
but are you watching the struck log now? You don't know, right? So how much would it, how much better would it be if you had that error or performance details immediately sent to you with the call stack and local variables and active user and all that stuff. And with Sentry, it's not just possible. It's easy. We use Sentry on all of our web apps, Python by set up M talk, Python training, all those kinds of things. And we know if there's some kind of problem.
It's unfortunate if someone hits a problem, but it's better to know and be able to fix it right away. In fact, one time somebody ran into a problem over at Talk Python Training, getting a course and got the message. I could see who was logged in when they had the problem. And I actually fixed the bug and was about to push out the changes. And I got an email. Hey, I'm having a problem with your, your site. I'm like, yeah, I know. I just fixed it. Try again, please. And they were quite a surprise.
So surprise and delight your users today. Create your Sentry account at Python by set up M slash Sentry. And please, when you're signing up, click the got a promo code redeem option and enter Python bytes. It's not automatic. And they'll make sure that you enter Python bytes as the promo code. Otherwise they won't know us from us. You'll get a bunch of cool stuff, two, three months of the team plan with many more errors and events and other features as well.
So check them out at Python bytes set up M slash Sentry. That's pretty awesome. Brian, I guess you should probably also test your code maybe before you end up with errors. What do you think? Definitely. And actually, before we go on, I think I've mentioned this before, but the graphic on that is on the Sentry page is so cool. I know. I really like it too. Like, I love the upset console terminal reading a paper.
Yeah. So this is, this is kind of like inside baseball, maybe, but I don't know, maybe three people might care about this. But anyway, I'm one of them. So X fail now works with by test subtests. So that's, it's neat. But I got to explain it a little bit. So subtests are kind of this weird feature of unit tests that came along in Python three, four, and it's a way it's a context manager so that you can have possibly several places where your test might fail, but continue. It doesn't stop
if it fails. And that's a, that was within unit test. pytest had, well, pytest said pytest check, the plugin that I wrote that allows something similar context manager. But then pytest subtests came out, which was a plugin in about 2019 that started that, that allowed you to run the unit test subtests within from pytest. But there's also a pytest style of doing subtests also. They're a bit quirky. So I'm going to, we, I'm linking to, to two resources, an article by Paul
Gansel and an episode of testing code where he and I talked about subtests. And so they're a little, before you jump in and use them right away, you should know some of the quirks about it, but they're still cool if they work for you. But one of the quirks that was around for a long time was that X fail didn't work. And X fails a way to say, I know my test is going to fail. Uh, but you know, and then you get to decide whether or not you want to make market as an
X pass or market as a fail, if it, if it fails. and the, this, anyway, X fail didn't work with subtests, but it does now as of like the start of the month. So somebody named maybe Sibber on, GitHub, maybe, merged a fix or submitted a fix as a pull request and it got merged and it's now in version 0 5 0. So X fail, if you wanted to use subtests, X fail now works with them. So that's
the good news. Yeah. Yeah. This looks really interesting. So the basic idea is I want to loop over a bunch of scenarios or whatever, and maybe test them all and then have the test fail if any of them did, but actually just go through them all before. Yeah. So like in, on the, on the subtests, site, there's a little example. So like, let's say you're looping through a range and you want to, you want to run all of them within, not, not a parameterized, just within the test,
you're doing like several things and you can, yeah. And if something fails, you want to actually report all of the failures. and this is, this is, you know, sort of helpful with loops, but you know, why not just use parameterization? but the, the, the one part where it does really help is if you really are checking like four or five different things and you really want to know, like, let's say you're measuring something or you're checking, several dimensions of something and, and
having all of the failures together would help you determine what the real problem is. So, so it's, it's, it's when you have to have all the information, this is a good idea. Very cool. Anastasia, what's the testing story in your world? Well, we use mostly parameterized testing because we don't have the subtest need. We don't need to test it multiple times, maybe in the future. Yeah.
Yeah. parameterized works. I'd stick with it. So yeah, it's definitely good. All right. Another thing that I think is really neat to talk about, but I feel like it's almost down to the benchmark type of situation is what do you do with the secrets in your application? There's to get, ssh get, which is always terrifying. If you go here, you can see, oh, here's all the code that we found in this branch of this GitHub repository. For example, here's your, you know, database
connection string with username and password right there. Right. So you can see all kinds of issues. If you go over here, like even a live stream, if it doesn't feel bad enough, you like watch the live stream of all the things that are coming in. Like right now, apparently there's some username and password in a URI and some kind of private key and whatnot. So you don't want that. So what do you do? Well, there's all kinds of things you can do. Do you encrypt those secrets and put them in source
code? Well, then where do you store the encryption key? There's some kind of certain types of vaults you can install on your server, kind of like one password, but for servers, you could do that kind of thing. There's just leave it in there and hoping for the best. There's putting it in environment variables. That's a very, very common one. Right. But still, no matter what you pick, you kind of got to
get that data back and deal with it. So I want to introduce you to Pydantic. Brian, you've heard of Pydantic, right? Yeah. In fact, I didn't know this had anything to do with secrets. Yeah. If you go to Pydantic right here at the top, I believe there might be some nice little comment here. Oh, yeah. I thought, I thought you were in here, apparently I'm in here right now. I think it toggles between us. Anyway.
Yeah. So we've known, the point is we really talked about Pydantic a lot. It's a really cool way to create these classes that are kind of like data classes, point them at some data source, and then they validate it and adapt it. Right. So if I've got like a JSON document and it has a field in it, and that field is a list of something I could say in my model, this thing has a list of integers. And if it happens to be quote a string or a number that has quotes on it, it'll just, you know,
automatically do the int pars type of thing to get it fixed. Or it'll tell us that it couldn't figure out what to do with the third value, something like that. It's really fantastic. But what I also didn't know was that it has a built in support for working with these user secrets. So Dennis Roy pointed this out to me. And there's all kinds of things. You can have the .env file. You can have Docker secrets.
You can have environment variables. And all of these things has your secrets. And if you just derive from, instead of base model, you derive from base settings, then this will automatically determine any of the fields that are not passed to it from the environment or from .env files. What do you think? Well, that's cool. Where do the .env files go? Not in GitHub. Okay. You know, you store them somewhere else, right? You probably, what ideally I think you do is you
would store like an .env template file that has, you know, put this value and then the real value here, this value and the real value there. And then you, of course, ignore, .gitignore the other one, the real one, right? So you at least have a structure. But so the idea is you come down here and say, I've got these settings and we've got like an API key and off key. We've got a Redis connection,
all those kinds of things. And you can even say, I'm going to put a prefix on it. So in your environment variables is fine if you've got one app in one server, but if you've got 10 apps running or 10 APIs running on your server, what is the API key referred to? What is the database connection string with the database name in it referred to? Which one of those 10 apps, right? So you can put a prefix. So you
could have like login app API key or, you know, login app API key. And you put that in there and it automatically will just let you access it as if it's API key. So you can sort of configure in the environment a little bit better. There's just lots of really neat things that you can do in here to make that work. you can say whether it's case sensitive, let's see, let me pull up, I had to take notes,
some other things that were super cool. So it's a regular Pydantic model, which means it'll do all the conversions and the validation. So if something is missing that's required from your environment, it'll let you know exactly what's missing. It'll do those conversions. yeah, all sorts of stuff. It has support for raw sequence files as well, which is like a slightly different way to do it. You can have differently named ENV files, like a prod dot ENV versus
U and a D dot ENV or whatever, all sorts of settings. So I've always thought Pydantic is amazing and I had no idea it had this built in support for working with this. The other thing that's really cool about this is if you go back to the top where it describes it, it says it will try to get these values from the environment if you don't pass them over. So if you're in say a testing environment, you want to actually pass values that would control it, you could just explicitly pass them along
instead of, you know, having them come from the environment. So it's really easy to test, you know, set the test values instead of trying to configure a test environment. Nice. We do use it by the way, base settings, but we didn't use prefixes. Yes. Yeah. Which is a good idea. Yeah. The prefixes are cool. If you have a bunch of apps, if you just have one, yeah, it doesn't really matter. Right. Yeah. Yeah. Of course. Cool. You like this? It's working well for
you? Yeah, it's working perfectly well. And we are committing on the development version with some dummy keys just to have them around. Of course. Of course. Oh, wow. How neat. Okay. Well, cool. Well, that's neat that you're using it. Brian, you got the next one. Is that right? You've already done it. No, but I just wanted to mention the, oh, wait. Nevermind. I had the wrong thing. Oh, here we go. Yeah. The quote I think you were looking for was from FastAPI. Oh, yes. Yes. Of course. Of course.
Yeah. It is. I'm over the moon. Yeah. Super excited about it. Yeah. FastAPI. Thanks. Yeah. We use it. I love FastAPI as well. And to me, like Pydantic and FastAPI, they go together because I learned about them at the same time. I know there are different people and different projects, but you know. It works like magic. Yeah. Yeah. Absolutely. It really is. Yeah. And if it's not magic, maybe you should document it. Or maybe it is magic. You should document it.
Definitely. Definitely. Actually, I'm the one who is usually bringing this topic to the team, how to write documentation. And first, the question is why to write documentation? Everyone knows that we need documentation, but it's hard. It's time consuming. It's annoying. And how it usually happens. Someone leaves the team. And then the last days are about handing over everything. And... Oh my gosh. I remember I've had this experience twice at least.
Right? Where it's like, oh, you said, where you said you're going to, you've given me your two weeks. So your next two weeks, your two weeks notice that you're going to leave. Your next two weeks will be to start writing documentation for everything you've ever worked on and anything that people might need to do. So your next two weeks are to begin writing documentation that you should have been doing the whole time. In Germany, we have notice period of three months. So like it's three months.
Oh, that's a lot of documentation writing. Yeah. Just kidding. But normally, even if you leave the team, like you, for example, move from one team to another, you don't, it doesn't mean that you have to leave the company. Still, you have to hand over everything that you worked for, let's say, in a year or even half of the year. And for example, in my experience, when I started with Python, I didn't know any Python. I had to learn it. And of course,
I didn't know about Sphinx or Read the Docs or any kind of documentation for Python. And what did I do? Nothing. I didn't write it. And half a year later, I was wondering who wrote this code. So I did get blame. And of course, it was me. And I was like, what a stupid person. So yeah. And I suggest to start writing documentation now, even if you're not leaving the team. The reason why I'm bringing up the Sphinx
and Read the Docs is that it will allow to have continuous documentation. And with Sphinx, you can easily write just some doc screens, which will explain what the function does, what the class is doing, add some input output parameters, and then you will automatically generate it. So there's no need to write it somewhere on Confluence or any other source. Because if there are too many
sources, that's where the documentation will die, because no one will go and check it. And during the handover, usually it happens like that you write documentation somewhere where nobody knows where, and nobody reads it. Yeah, you pointed out that you've got it in Jira, and you've got it in GitHub, and you've got it in all different places. Google Docs, yes. Yeah. Especially Google Docs. Oh, yes.
And then you share like 10 Google Docs with different people, and then they lose the links, and people are leaving. It's nice when people are leaving the team, but it's not nice to the people who are leaving the team to another team, because they are getting all the questions for a year. Where to find those? How can I get this function? How to get this data? Yeah. Yeah. Very good advice. You know, for a long time, Sphinx was like synonymous with restructured
text, but now we've also got the Markdown with the missed parser there. So that's very cool as well. I'm a fan of Markdown instead, yeah. And also it supports the Sphinx itself. It supports different types of documentation. For example, you can write code reference, then you can go through all the code, and then you can also write extra documentation, like Markdown. Even ReadMe can be included into documentation. And you can also style it. Oh, nice. Yeah. Yeah, very cool.
Yeah, there's lots of great themes to it too now. It really looks attractive. Yeah, you did recently cover that, right, Brian, the Sphinx themes? Yeah. And actually, when the Markdown, the support came on, that's when I went back and started looking at Sphinx. So some of our documentation is done in Sphinx now because it does Markdown. And you can even make it do, it's not built in, but you can make it read doc strings and interpret doc strings as Markdown. So it's cool.
Yeah. Very cool. Very cool. Robert out in the live stream has an interesting addition to continuous integration and continuous delivery. So can we deploy yet? Only if the documentation is complete. Definitely. Very cool. All right. Well, that's it for our main topics. Brian, you got anything you want to share? Any extra stuff you want to throw out there?
Mostly, I'm curious about pytest uses. So I'll drop a link in the show notes, but basically I've got a pinned tweet on my Twitter, and I'd like to have people tell me where they see where they're using pytest. So I've got some examples. And then I kind of went, I, my first question was people projects that have switched. But I was looking at just the, just the guts of how Python works. And there's some amazing projects that use pytest,
like wheel, tip, setup tools, warehouse. Those all use pytest. That's pretty cool. Wow. How interesting. Yeah. And those are sort of almost inside of Python, which is interesting because they're not using unit tests, right? Yeah. So, and then I just learned about recently, even if it's proprietary, that'd be interesting. I just learned that Stripe and Lyft went through a pytest conversion recently. So that's kind of neat.
Yeah. That's cool. Yeah. Yeah. Very cool. Anastasia, anything else you want to throw out there or let people know about while we're here? Yeah. Maybe using exceptions. Don't use space exception. Yeah. I agree. Custom exceptions. Custom ones that like a four-year app or have certain, absolutely. I definitely second that idea. All right. This, Brian, this was in danger of almost being an extra, extra, extra,
extra, extra hero about it. So I'll just go quick. So Matthew Feikert's getting a couple of shout outs on the show. So he also pointed out that, whoa, super cool. PipX, which we've talked about on the show before, it lets you install Python tools, kind of like Homebrew or Apt. They're not part of a project, but you want to have them managed and installed in their own isolated environment. So you pipX instead of pip install the thing, which is great. That is now officially part of PyPA,
the Python Packaging Authority. Nice. So yeah, pretty cool. So pipX is now sort of officially part of Python, not Python, the distribution, but the group, you know. Next, I will be presenting-ish. It's recorded, but then there's like a live Q&A afterwards. Manning is having a conference on developer productivity. I don't honestly remember what my top talk is going to be about. Oh yes, here it is. It's 10 tips and tools you can adopt
in 15 minutes or less to level up your developer productivity. So I'm going to be speaking on that. All sorts of fun things. So if you want to check that out, it's free to register for. It's later this month, I guess. Here's just a thought I would throw out there for you. I don't expect an
answer, but yikes, cloud bills can pile up. Alex Chan, who is teaching, I guess I don't, I could figure out exactly the context of this, but put out a tweet that said, I have a panicked student in my DMs who accidentally racked up an $8,000 AWS bill. My suggestion of talk to support is no good. Apparently they won't issue a billing adjustment. Anyone got ideas out there?
Oh no. Could you imagine as a student, I mean, as a professional, it's still a lot of money, but as a student, $8,000 is like a ton of money. Yeah. It's like a term of bills. It depends on. Yes, exactly. Yeah. Like a semester of studies or something. So, maybe other students and basically all people out there put up billing alerts on, on whatever cloud thing you're doing, on whatever, whatever places I have, including AWS, I get periodically, I get an announcements like
you, your bill is now at $50. Your bill is at a hundred dollars. Your bill is now at $500. Your bill is now at a thousand dollars. And if it goes beyond that, I'm going to have to start paying a lot of attention to what's going on with my AWS account. So just, you know, put these alerts on there. It's usually easy with whatever platform you're on. anyway, don't be that poor student. All right. What's next? Brian skin, shout it out. Hey, this might not
be a total new item, but maybe we can mention it. Maybe it's interesting. Developed a flare mentioned, a flake. It didn't develop it. I don't believe a flake eight plugin for FastAPI. So if you're doing FastAPI, there's different ways to do things like routes and whatnot. And there's like the natural way, there's sort of a clumsy way. And so here's a flake eight thing to make sure you're using FastAPI.
Nice. Interesting. Yep. And I think, yeah, and I think this is my last one. It is my last one here. So Sal Shannon Brook tweeted JupyterLab three will have localization. So localization means like the menus and the help text and the button hover tips and all that kind of stuff are localized for different languages. So JupyterLab three will have localization making it more approachable for
people who don't want to work in an English UI and their crowdsourcing translations. So if you wanted to contribute to Jupyter and you were good at programming and in a language that's not English, but it's already done in English, you know, go check that out. That would be kind of cool. What if anybody just messes with people and like does wrong translations just for fun? I'm so afraid of that. Yeah. I think they do.
I bet they do. I bet they do. And maybe not really obvious, maybe in real subtle ways. Yeah. Yeah. Yeah. Nevermind. Don't, don't, don't, don't have any ideas. Brian, don't give people ideas. This is not, that's a good one. All right. Well, that's all the extras as well. So how about a joke? Yeah. Okay. So imagine you're learning programming, you're learning Python, take one of these computer science courses where they talk about weird things like recursion. So cursion is the idea that the
function calls itself with different parameters, right? Like a really common example would be factorial. So if I'm going to calculate a factorial, it's just N times N minus one times N minus two. So that's just N times factorial of the smaller number. You can just like work your way back. Right. But there should be an exit condition. Like if N equals one return, don't keep recursing. So here's a nice little graphic under the banner of only programmers would understand. And it's got
the four squares. It's kind of like screen sharing. We got that infinite view. So learn to program in one corner, next corner, make recursive function, third corner, no exit condition. And then it just repeats and repeats and repeats down to smaller and smaller and smaller. I love it. This is bad. No, this is good. That's how you learn. That's right. No. Yeah, exactly. It's like when you share your screen in zoom or, or maybe Google
meet, but you've still got the window up or something like that. But it's about recursion. It's beautiful. And then you silence basic exceptions and you cannot exit the program. Yeah. Do you know if, yeah, you know, if Python has a tail recursion optimization, sorry. I'm thinking, I'm thinking no, like, so the whole point is here, Brian, that we would run out of a call stack space really quickly. And that's usually the error stack overflow error. If you recurse too deep type of thing. Yeah.
But with trail recursion, it basically becomes an infinite loop. So you run out of time instead of memory. Okay. So, but I don't, so that would be the advantage of tail recursion. I have no idea if it is there or not. Yeah. I mean, there's some languages that do the optimization, so they don't, they don't generate a new call stack because there's nothing to save. So yeah. Yeah. Anyway. Yeah. I don't know. I'm sure we will find out before next week.
Yeah. One of the reasons why I like asking open-ended questions on the podcast. So yeah, that's awesome. Yep. Well, Brian, thank you as always. And Anastasia, thank you for being here. It was great to have you as a guest. Thanks. Thank you for inviting. Thank you. Yep. Bye.