Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 200, I can't believe it. Recorded September 16th, 2020. I'm Brian Okken.
And I'm Michael Kennedy.
200, can you believe it?
I actually cannot believe it. That is a ton of podcasting and everyone's been super supportive
and it's been great to do 200 episodes with you. I don't think we've actually done 200 episodes
because there's a few times you couldn't make it or I couldn't make it or we did some live thing.
So probably like 195 together, but that's still a ton of podcasting together.
Yeah, yeah, it is. It's pretty exciting. I've had a blast.
Absolutely. I hope people are finding this helpful.
Oh, I think they will find it helpful. We're really good at transitions.
Because we've been doing it so long.
Yeah. To transition into the next topic. Actually, the first. Batchelder wrote a cool article. This
is great on how to be helpful online. And this is the advice that he's giving is targeted towards people
that are trying to help other people online. So if you're answering a question on Stack Overflow or
just even an email question somebody sends you or on Twitter or whatever, these are good advice.
Actually, it's a pretty long article. There's a lot of advice there. So I want to highlight a handful of them. One of them is answer the question first. There may be other problems with their code that they're not asking about. And you want to get to the point of just helping them with their answer. All the rest of the problems on their code. Actually, I think that's really good. I've seen that people violate that all the time. The second point that he brings up is no third rails. And I don't even know where that term came from. I don't. That doesn't make sense.
any sense to me. But going off the rails, I've heard of that. He gives an example of, it should
be okay for someone to ask for help with a program using sockets, for example, and not have to defend
their use of sockets, especially if the specific question has nothing to do with sockets. And he
says things like, it's not sockets, it might be pickle or threads or globals or a singleton or
something. You might have really strong opinions about some design pattern or some code
that they're using or different libraries. That's not really what they're asking about.
Don't attack them for their design choices. Just maybe answer the question instead. No dogpiling.
I think that's self-explanatory. Once somebody's already answered a question, you don't have to
answer it slightly different. If you're very different and you think you're adding to the
conversation, of course, speak up. Meet their level. This is a difficult one. Try to determine
what they know and give them a reasonable next step, not the ultimate solution. A suboptimal
solution they understand is better than a gold standard they can't make use of.
That makes a lot of sense because, you know, I think also leads to one of the other ones is
your gold standard is encased in your context and your use case and so on. It's like the,
you're not Facebook, you're not Google, you're not LinkedIn, probably. You might not need their
gold-plated solution that's perfect for that situation. Yeah. And also odds are if you're
answering questions, you're a more advanced developer than the person asking, at least in that field. So
be gentle. The last one I want to highlight is use more words. IRC and Twitter and other online
mediums encourage short responses, but short responses are the exactly the kind of thing
that can be easily to easily misinterpreted. So use more words, especially encouraging optimistic
words. I think this, and you know, also just, there's a lot of stuff people leave out, but they
would say in person, they would say, Oh, it's cool that you're trying this problem. Let's look at it this
other way and let me know if you have any other questions, but they don't put that stuff in text.
And so I think it is important to use more words and, and, be more encouraging online. And there's a
whole bunch of other stuff like humility and understanding your motivations and their motivations
and trying to, you know, build a community. So great advice from Ned. I encourage the next time that you read
a question and your mouth drops open and your eyes stare in shock, maybe read this article before answering.
Yeah. It's a nice article and a good advice. Thanks, Ned.
I don't know how to transition to magic, man.
Magic is awesome. You know what else is awesome? Black is pretty awesome, right?
Yeah, definitely.
You know what is not awesome? Crappy code written in a Jupyter notebook that has no like proper editor
support. Like I don't need black that much because I use PyCharm and I can hit command alt L and it
formats it basically like Blackwood or in VS Code, I hit command shift P and type format document and it
formats it basically like Blackwood, but in notebooks, it's just stuck there and it's like permanent
icky form. And it's like, well, how I want to make this nicer, but I don't want to take the effort of
like developing it nicely. I want the tool to just fix it for me. Right. And black is really great for
that black super popular, but Jupyter doesn't have black, but magic can add black to your Jupyter notebook.
So there's a cool package called black cell magic. And so with black cell magic, you can load this.
It's an extension for Jupyter notebooks. You just say percent load extension, black cell magic once.
And then on any cell that you want to reformat, you just say percent percent black and rerun the cell
and then it formats it.
Nice.
Nice. Yeah. And so actually you type that command at the top of the cell, you rerun it, and then it
takes that away. So it doesn't stay there basically. Yeah. So anyway, you run it once and you can even
give like little command line arguments to the formatter when you put that special magic command,
the percent percent, I think those are called magic commands in Jupyter. So percent percent black
dash L 79 for like changing the line with the 79 characters instead of 80 by default, or there's,
you can pass stuff off to black that way.
This is cool. I like it.
Yeah. Yeah. And if you want to know if you like it and it's for you, you go to the website,
go to the link I provided and it has a cool animated GIF and you can see right away.
Oh, that's cool. I want that. Or no, that's, that's weird. I don't want that.
Yeah. I was watching that while you were talking.
Yeah. It's cool. Right. So it just, it's always a problem. Like I need to format my Jupyter notebook.
Why, why is this not built in? Well, now it's kind of sort of plug in a bowl, not part of the story,
but can we go back to the whole command alt L thing?
Yeah.
That's in PyCharm. It reformats your code or something.
It does. Yeah.
Okay. I'll just check that out.
It's pretty sweet. That only works on Mac and it depends on which bindings, you know,
there's like multiple keyboard bindings. So maybe in the Vim one, there's like a different one.
But if you go and you go find the menu command for like reformat document, it'll show you what the hockey is.
And you can do better than that. You can actually right click on the project and say,
reformat the project. And it'll like traverse down into all the files and it'll reformat like everything.
So that's okay. But I don't know of a hockey for that, but you can like right click and say reformat this tree of stuff.
Yeah. But if I'm doing a tree of stuff, I'll probably use black.
Yeah, exactly. Yeah.
I never use that, but generally command alt L or control alt L probably on windows or Linux.
We'll do it. But black cell magic will add it to Jupyter. Now what's super annoying is you got to type that command every time on a cell and it does it one cell at a time.
So if you've got a hundred cells, you got a lot of percent percent black you're typing.
There is a guy named Tobin Jones who wrote a NPM package that will use this over top of it and reformat all of them.
And I linked to the repo, but then when I go to it, it looks like it's archived.
So I have no idea whether it even works still or anything. I haven't tried that one.
So people can check that out, but it would be nice if this was like leveled up to apply at least to a notebook, even if you run it on demand.
Yeah, definitely. It would be cool to be able to blackify a notebook.
Yeah. But nonetheless, this is better than what it was before. So it's pretty good.
Do you know what else is really good?
What's that?
Learning awesome Python from Talk Python training.
That is pretty awesome. Yeah. So this episode is brought to you by us again.
And if you're in the market to learn Python, we've got a ton of courses.
We're coming up on 200 hours of highly edited courses. So that's a ton of content.
And we have a special enterprise plan. So if you're looking for team training and team events that are online, digital,
you know, just shoot me a message and I'll get you info about that.
And pytest.
Yeah, definitely. If you are considering pytest or considering testing your code, please do test that.
And I would like to actually highlight, I brought up, somebody made a nice comment today.
I wanted to bring it up.
Ken Ewens Clark, this came out a couple of days ago, says he picked up my book, Python Testing with pytest and started reading it.
He was excited. And just one hour later, he posted another comment and said,
I've just finished the first chapter and I can see I've barely scratched the surface.
So I'm already learning something new in one chapter.
So that's cool.
Yeah, that's really cool. Maybe help people test smarter, not harder.
Yeah, well, actually, you know, that is the goal of the book.
But I also wanted to highlight an article by Luke Plant called Test Smarter, Not Harder.
And this is not like a huge article.
It's some nice opinion.
I like opinionated testing articles.
Good opinions there.
There's a lot of great advice, but I wanted to pull out a couple of his suggestions
because I don't think that they're talked about much.
So the first suggestion that Luke has, or the first one I'm highlighting, is write your test code with the functions or methods or classes that you wish existed,
not the ones you've been given.
So if an API you want to use doesn't exist yet, you just use it anyway, but then you have to make it exist.
So this is actually huge advice, I think.
And people don't really, I think they think about it while they're coding, that you try to write the code you want, the API you want,
and then make it if it isn't there.
But forget to do it while testing.
And while testing, it's even more beneficial, I think, because you've got to be able to read your test code really fast and understand it quickly.
The other thing I want to highlight with that is if you are responsible for the API or the API that you're testing against is something you control,
then pay attention to those tendencies to say, I really wish I had an easier API,
because that might tell you that maybe that new API should exist and maybe you should add it to your interface.
Yeah, I think this is one of the really big values of testing is that it lets you step back from the code you're writing
and look at the API or the classes or library or whatever you're building, look at that from the outside and go,
does that make sense?
Is that the best way I want to use it?
It's sort of your first chance to put it into practice as a consumer rather than a creator of it.
So if you're not the person in control of the API and you're just using a different API,
you can write a wrapper around that to just highlight the thing that's important for the test
and not have to pass in a bunch of stuff that doesn't matter to the test, but you have to pass it anyway.
I think those are great suggestions.
The next suggestion is only write necessary tests, specifically tests whose estimated value is greater than their estimated cost.
This is a judgment call, of course, but it does mean that at least some of the time you should be saying this test isn't worth it.
And now this is a controversial sort of opinion, but I go by this.
And if you have trouble convincing the people that you have to convince to skip a test,
you can just say I'm prioritizing my tests and that one's lower on the priority.
Maybe we can get to it later.
The flip side of this, that's good advice.
The flip side is that I think is not initially thought of by a lot of folks is you have to maintain your tests as your code changes.
I mean, if you've got a static API and it's just fixed and it's on PyPI, it's fine.
But if this is an application you're building, you might dramatically change the way things work.
And when you do that, you might have to rewrite your test to correspond with that, to recreate objects in some new way or whatever.
And the more maintenance burden that your tests carry, the less you're going to like writing tests and the less you're going to keep them running.
And so it's not just, is it worth the value of creating the test?
It's worth the value of creating and living with that test.
Yeah.
Test code has the same maintenance cost or more maintenance cost than production code.
Also, different parts of your workflow.
So early on in a project, you're really learning how to do the problem and you're learning about the code.
So write tests that help you with that learning.
Don't write tests that solidify the API so it's hard to change.
That's the point.
Yeah.
Write the ones that help you learn about your code while you're putting it together.
Very nice.
So this podcast is pretty awesome.
And for episode 200, I wanted to get something good, a package that's good to talk about.
It might be the greatest package of all time.
Really?
Well, it's self-proclaimed.
So a bit of a grain of salt.
It sounds really simple.
It has a crazy name and it actually is really quite useful.
So this next one is called US, as in the United States, the greatest package in the world.
That's literally the name of it.
So this goes to us.
Yeah.
So Jerry Carbaugh reached out to us and said, hey, I created this package.
I don't know.
You think it's useful or not?
I'm like, oh, okay.
It's kind of interesting.
It's a Python package on PyPI for working with states.
States, zip codes, those types of things.
And the United States.
Right?
Okay.
And it seems like this could be motivation for things like the EU or some other place where
you want to understand the geography of it.
But this is really quite involved.
So I envision like, okay, well, maybe it's got like a list of the states and it's got the
abbreviation or something.
It's got that.
It's got all the territories.
It has the postal abbreviations.
It has associated press style abbreviations, which I don't really know.
It has FIPS codes.
I have no idea what FIPS codes are, but they're like lookup codes, different kinds of lookups
you can do.
Okay.
Capitals, the year of statehood, the time zones.
You can even do phonetic name lookup.
So like if you can't spell Mississippi, but you can make Mississippi sounds with letters,
you can put that in there and it'll go and find it.
So like it basically do like lookups on misspellings, but if you get it like sounding right, it can
still find it.
So maybe you accept typed input or some text field that says the state, but then you can
do a lookup on that to get a more canonical representation, whether the state is contiguous, like Oregon,
all one thing stuck together or a very nice place like Hawaii.
That's broken into a bunch of islands where there's continental or not similar difference
there.
That's pretty cool.
If you want the geographic boundaries of them for like geospatial work, it comes with
URLs to shape files that come out of the U S census.
At least they're accurate up to 2010.
Okay.
Well, also one of the flags is, is obsolete.
I was wondering if there's obsolete states.
There are obsolete states.
Yeah.
So I think more territories are obsolete.
I don't think there's states that are obsolete, but there's territories that are, for example, like
the Philippines, I think used to be a U S territory, but it's no longer something like that.
There's a few examples in the docs.
Oh, okay.
Cool.
Yeah.
And they also have a, an environment variable to indicate whether Washington DC becomes a
state.
You can set a flag that will like trigger that to show up.
So it's like future proof a little bit.
Okay.
And it has a CLI.
So you could type states space MD for Maryland and you'll get a big, long description of information
about it.
Well, with the prefix of the great state of.
Yeah.
That's interesting.
So is this more than you expected out of it?
Like when I thought, I thought it would just be like a list of states and stuff, but like
all this lookup, all this information, this is pretty awesome.
Actually.
It's pretty in depth.
Well, no, it's pretty cool.
I just didn't, I don't know if I'd say it's the greatest package in the world.
Oh, all right.
Well, there's always a PR.
You could always a pretty good package with respect to state management in the world.
Yeah.
Okay.
No, actually, if you work with states, this seems super useful, regardless of whether you
agree with the name.
Yeah.
I've got kids that are at home right now.
One that's a started school, but started school like online.
So it's a, it's sort of an anticlimactic big beginning to school.
Yeah.
And we still have like some, a lot of time that they're devoting that I'm glad they're doing
this.
They're allowing teachers sometime during the, during the week to prepare for all of this,
which means they've got kids have more free time than they had before.
So one of the things I was looking for was good learning software coding related learning
activities for kids that are, have some spare time, especially early on in the school year.
I can't remember who suggested this.
Somebody on Twitter suggested this, but there's a video series that's part of Ted Ed that's
called think like a coder.
The title says it's a 10 episode series that will challenge viewers with programming puzzles
as the main character, a girl and her robot companion attempted to save the world that has been plunged
into turmoil.
So I was trying to evaluate whether or not to highlight this on the show.
And I got like four episodes in just this morning.
Although it says it's a 10 episode series, but I only count nine.
It's zero.
It's you start counting.
It's a zero base.
So it's off by one for programmers.
I don't know.
It doesn't really teach.
I haven't got at least the first four episodes.
It doesn't teach like actual coding, but it talks about the concepts.
And that's what I really like about it.
It's an interesting story.
The animation is pretty good, but it'll introduce words and terms like loops for loops and tell
loops, while loops, conditionals, variables, path logic, permutations, how to do searches,
tables and recursion, and even some big O notation and some other things.
But these are like terms that in software and in programming, we use all the time and just
assume everybody knows what we're talking about.
One of the things I really like about this is just defining and using those terms in an
entertaining story so that when you really do start learning how to code, it's not going
to be surprised.
Highlight with that.
I'm also reading to my daughter a book that I picked up called Girls Who Code, Learn to
Code and Change the World.
And it's a lot of inspiration.
There's actually a Girls Who Code project that does teaching and stuff, but I don't know
what they're doing right now during COVID.
But the book is great and it's not any language specific stuff.
I think there is some Python in there, but that's not really the focus of it.
The focus really is teaching a lot of the concepts and just getting people excited about it.
So I wanted to highlight these two.
That's one of the biggest challenges.
It's getting people feeling like this is interesting and this is for me and I should pay attention to
it.
Yeah.
That's cool.
Also, I want to throw a shout out to CodeCombat.com.
That's another really nice place that sort of has some of these ideas, go through and do
like a little dungeon exploration and solve problems.
I think it would be a good follow on to this series.
Like you've got the ideas from the series and then you can go write like super editor supported
Python code to like in a little game world.
So that'd be fun.
Yeah.
We'll link to all that in the show notes.
Absolutely.
So this next one is interesting.
I ran across this just a few days ago and I thought, oh, I definitely want to talk about
this because how many programmers out there have this idea of I've been building this software
for other people, for other companies.
And I just want to, I have this idea and it doesn't exist and I want to build it and put
it out there into the world.
Like surely almost every programmer has had this, this idea of some in some form or other,
right?
Yeah.
So there's this project that is a pretty new project that goes along its path and it's
called keep the score.
So keep the score is like online software for scorekeeping.
Basically, if you've got like a soccer tournament, rock climbing competition, whatever, like those
things probably don't exist anymore.
But when we could be around other humans and when we can, again, this is going to make
a lot of sense.
You could have like a, a little online scoreboard that the parents could pull up and keep track
of or whatever, something like this.
Right.
That's basically what this app is.
It's a Python flask app and they wrote a blog post called the cost of running a Python
web app with 55,000 monthly users.
Okay.
So this explores like the infrastructure and how much did it cost to actually put it together?
Uh, how are they doing it?
And so on.
So I thought it might be fun to just kind of talk through that a little bit and then do
maybe a little comparison over to some of the talk Python stuff.
All right.
Yeah.
So I'm leaking over the thing.
Their site's pretty cool.
It's hosted on digital ocean as is all of our stuff, Python bites, talk Python and whatnot.
So that's a really fair comparison that I'll make.
And they're using digital ocean and Firebase currently have around 55,000 unique visitors
and they have their servers and database over on digital ocean.
And I think they might be using Postgres as a service on digital ocean rather than hosting
their own database server.
From what I can tell, they also have Amazon web services.
Yeah.
So for the numbers, digital ocean has cost them about $95 a month.
They have some AWS metabase stuff running over there.
It's $60 a month for like reporting and whatnot.
They have Google cloud for a whopping $1.32 at Firebase.
DNS hosting of $5.
Discuss $10.
They said, of course, you can have a free one, but they put ads there and they don't like
that.
So $10.
They're paying for that.
And they said, well, okay, that's $171 a month.
Is this worthwhile?
Obviously, if you were Roden Schwartz or you're Talk Python training, like it would be obviously
$171, like no big deal.
Right.
But this guy points out like, I'm an indie developer.
I have no revenue yet.
And I'm just trying to get this thing off the ground and I'm paying $171 a month.
But that's a lot of money for just trying to do something nice for everybody.
Yeah, I agree.
And it's mostly free and they're trying to figure out the monetization.
And I think it's a cool project.
I actually hope they're successful and it's cool they're building it with Python.
But I don't know.
It's an interesting trade-off.
I feel like so many people, I don't want this to sound at all critical of this guy.
Like what he's doing, it's working for him and that's great.
But I feel like a lot of people just in general, not necessarily this example, they envision
a world where like things are so much bigger and more powerful and more awesome or more
like there's more users and it's like more awesome.
And they got to be ready for that because when they get, when they land on like Hacker News
and all the people come, they've got to be ready for like a 50x traffic and stuff like
that.
And I don't necessarily think that that's how it goes or, you know, if you're in the cloud,
something like that happens.
Just push the make it bigger button.
And then it goes like, you don't have to do that beforehand.
And actually one of the things they said they ran into is they started out with a smaller
server and they said, oh, we want to make sure we have a bigger server just in case.
And they upscaled it.
And part of that upscaling like changes the, I think it was probably the file system got
larger, the disk got larger.
And once that happens, you can't downscale it again.
You're like stuck without, unless you recreate it from scratch, you can't downscale it again.
And so they have two servers.
They're like deploying to one.
And while they're deploying to one, they take the floating, the elastic IP and they switch
it over to another one that's keeps it running.
And then they deploy to the other one and it switches it over to the, like, there's like
this back and forth swap going on.
And that's actually how I do it at Talk Python on training site and stuff like that as well.
Having like two servers.
That said, this feels really high to me.
I'll give you some stats on Talk Python.
Just talkpython.fm, the website for the podcast, not the training site, not Python Bytes.
The reason I chose Talk Python is it's very similar to the numbers that this guy is using
on the same infrastructure.
So Talk Python gets about 40,000 monthly visitors.
It's super hard to talk about unique monthly visitors because so many developers, especially
in the developer space, because so many people have ad blocking turned on, which is how you,
you know, like third party cookies from apps like Clicky or whatever, say you get this many
visitors and like 50% of that's blocked or something.
Right.
So anyway, you got to kind of estimate like, well, how much is blocked?
Is it 30% or who knows?
So anyway, it's around similar numbers, a little bit smaller in terms of visitors, but the podcast
clients, oh my goodness.
The podcast clients are crazy.
They're just pounding the server like all the time asking for the RSS feed.
So we get about 3 million requests for the RSS feed monthly.
That goes through, it goes through Python.
It talks, it does some database stuff.
It talks over the database and it gives back an answer.
I could cache that as a file, but then there would be like latency and inconsistent.
I just, there's no need to not have that happen.
Right.
But that, that does.
Right.
So that comes through and that's about 120 K requests.
So that's 320 gigs of traffic and 3 million requests just to answer the question.
Can I go download the file?
Which is much bigger month of weekly.
You know what I mean?
So that's a ton of traffic and the servers back in that.
I have two servers cause I do this flip as well.
So there's zero downtime.
Most of the time.
One of them is a $5 server.
And because I wanted to splurge, the main one is $10 because, Hey, this is my whole business.
Like it's worth five extra dollars a month, but it could easily handle it on five, on five bucks.
So for example, I have it pulled up right now and it's running at like 8% CP usage, 6%.
You know, it kind of varies.
Right.
Right now.
If it was on the $5 one, it would be like 12%.
It would still be fine.
And then there's also a dedicated MongoDB server that handles everything, but that's like $10.
Total cost, 25 bucks.
Okay.
Well, 25 is, okay.
Okay.
Devil's advocate here.
$25 is way better than 171, but even $25.
Yeah.
I could do it at 20 if I wanted, if I, if I just went down to the $5 server, which I could,
but even at 20 a month, that's what a $240 a year for trying to do something nice and free
for everybody.
Yeah, I know.
What's really lucky is that I don't have to pay for the bandwidth for the, the stuff going
through digital ocean.
Cause that would be like another thousand dollars a month at least, but that's included.
So it's fine.
I feel like you could turn stuff down a lot.
Like for example, I think he's using Postgres as a service, which is probably, I don't know,
I'm sure there's probably 50 bucks a month.
You could probably put that on a $5 server and just manage Postgres yourself.
Okay.
Is that worthwhile?
I don't know.
Like how much of a pain is that to manage yourself versus like, how do you do backups and all that
kind of stuff.
But in the really early stages, I think you, if you're worried that the extra $100 a month
is a big deal, you know, maybe you do it that way.
Also though, by the way, my AWS bill is over a thousand dollars last month.
So, but that's just video delivery.
That's a different story.
That's just bandwidth.
That's, and that's because of the training.
Yeah.
Okay.
So I could do it cheaper.
I could do it a lot cheaper, but it would be less good for people.
And for that, I'm trying to pick the best possible option.
So that's how that goes.
But anyway, I think it's interesting to sort of think about like, what does it cost?
And your point about if I'm doing something nice for everyone, right?
It should cost less.
Yeah.
Well, I mean, you know, motivation doesn't really get into it, but it's a very real thing.
It's a barrier to entry for, for people that maybe that, I mean, they had to scrape together
just to get the laptop in the first place to start coding.
And yeah.
And if you're not in like a Western democratic place where currency is pretty valuable or the
pay rate is pretty high, all of a sudden $175 could be 25% of your monthly income, which
that's a huge number, right?
Yeah.
So it could definitely vary depending on where you're located.
Yeah.
Anyway, pretty, pretty cool.
I think it's worth looking at and digging into, and I wish them the best of luck with this project
because it seems cool and it's built Python.
Finally, if you want to hear like a deep dive into all this stuff that I was talking about,
Dan Bader and I had a long chat about the infrastructure behind Talk Python and some behind
real Python over on Talk Python 215.
I'll link to that as well.
That's pretty serious, man.
We should do something funny.
Yes.
Tell me a joke.
Okay.
So somebody shared this with us on Twitter and originally Netlify posted it.
It's a conversation between two people.
Oh no, we lost the hackers.
Where did they go?
I don't know.
They just ran somewhere.
That's so awesome because I didn't get that joke reading it, but when you say it like,
oh yeah, perfect.
Well, I'm very concerned about making sure that everybody has a happy work environment and
that they're safe.
And I've had to fill out some contracts and stuff.
It's so ridiculous, man.
I've had to fill out like vendor stuff for podcast advertising and they make me go through their
stupid vendor onboarding thing at some of these big companies.
And I've got to answer like the general vendor information.
So what is your information?
Like what is your location?
What is your bank account information so we can pay you?
What is your OSHA health policy?
Is there a chance that somebody is like, are there dangerous ladders that people could climb?
Will it be forklifts?
I'm like, dude, this is podcast advertising.
There's no ladders and there's definitely no forklifts.
Why are you sending me this huge 50 page form?
I got to fill out like two pages apply to me.
Anyway, let's take this and turn it into the programming joke.
So, you know, you've seen those like number of days since serious injury at factory seven.
We're doing great.
Nobody hurt this week.
So how about this for our programming sign?
Number of days since I've encountered an array index error.
Negative one.
I love this joke.
It's a good joke, right?
Yeah.
Negative one.
So that's really big because you probably overflow.
Well, you don't know how big though.
Is it a short and unsigned?
Is it like a, if it's a short, it's like negative 32,000.
But if it's a long, that's a really huge number.
It's like 4.2 billion, 9 billion, whatever the overflow wrap is there.
They probably just allocated a byte for it.
So it's like 255 or whatever.
Yeah.
Less than a year.
Awesome.
All right.
Well, thanks, Brian.
Congratulations on 200, man.
Thank you.
Oh, we overflowed.
We're into the 200s now.
Congratulations.
Oh, wait.
Let's celebrate on 256.
Yes, we will.
That's going to be the full cycle.
Yeah.
Awesome.
All right.
Well, thanks again.
Thank you.
Bye.
Thank you for listening to Python Bytes.
Follow the show on Twitter at Python Bytes.
That's Python Bytes as in B-Y-T-E-S.
And get the full show notes at Python Bytes.fm.
If you have a news item you want featured, just visit Python Bytes.fm and send it our way.
We're always on the lookout for sharing something cool.
This is Brian Okken.
And on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast
with your friends and colleagues.