Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 413, recorded December 9, 2024.
And I'm Brian Okken.
And I'm Michael Kennedy.
This episode is sponsored by us, so check out the links in our show notes,
but also check out Talk Python Training and PythonTest.com.
There's courses over there.
And of course, thank you to Patreon supporters.
And we have links.
If you want to get a hold of us, you can reach us on BlueSky or Mastodon.
The links are in the show notes.
And also, if you're listening to the show, thank you.
And please share it with a friend.
Also, if you'd like to participate in the discussion while we're recording,
you can head on over to pythonbytes.fm/live and see when we're recording next.
But usually it's Monday at 10 a.m. Pacific time.
Sometimes it shifts, though.
And during the holiday season, who knows what we might do.
But so far, we're sticking with that.
And if you'd like to get the links in your email inbox, go ahead and go and sign up for
the newsletter at pythonbytes.fm.
And we will send you all of the links in the show notes right in your inbox.
So, Michael, let's kick it off.
Let's kick it off.
I want to talk about a little bit of jitter.
Maybe I've had too much coffee this morning or something.
I don't know.
What do you think?
Jitter is a thing from the folks at Pydantic.
And the idea here is they need really fast JSON parsing as the foundation of Pydantic.
Basically, Pydantic is about how do I exchange, validate, and transform JSON data with Python
classes, right?
Into Python classes.
Okay.
Yeah.
So, you want that to be fast.
The folks over at Pydantic created this thing called Jitter, G-I-T-E-R.
And it is a fast iterable JSON parser.
Now, if the Pydantic usage does not catch your attention, OpenAI is also using Jitter, which is
pretty interesting.
Ask ChatShiftPT about it.
So, the reason that they were interested in it is they want to be able to work with,
I believe Pydantic as well, but they want to work with responses coming out of LLMs.
And anyone who's used LLMs until maybe very recently knows that they kind of like spit out
the answers in a little progressive way, right?
And so, with this, you can parse parts of data as it comes down, which is pretty cool.
So, there's some examples of partial in here.
You can go look for somewhere, I think maybe on the docs website or something like that.
But, you know, you can give it like a partially formed string and it'll come up with like
perfectly good answers for it.
So, that's pretty neat.
And that's one of its features.
The other is that it's faster than what I think the default Rust JSON parser is.
Even for non-iterable, just straight parse it, which is, that's pretty impressive.
Okay.
And then there's also, this is why we are talking about it, there's Python parse, which
parses JSON strings into a Python object.
So, you can go and run that as well, which is pretty cool.
Shooter example.
Yeah, yeah, yeah.
Anyway, yeah.
So, you can go and parse it into different pieces using, basically, if you need a really
fast JSON parser with Python, you can use Python parse and it'll parse into a structure, right?
Yeah.
So, awesome.
I thought people might be interested in both an iterable, iterating JSON parser, and back
to this one.
Iterating JSON parser and also a really fast one.
Plus, it's being built by the folks at Pydantic, Sam Colvin and team.
And yeah, excellent.
Nice work.
Oh, yeah.
I think I've got several uses for this.
This is cool.
Yeah, cool.
Yeah.
I recently had Samuel Colvin on with David Seddon to talk about building Rust extensions
or integrating Rust with Python and things like that and talk Python.
And he talked about this as one of the things they're building, which is like, oh, okay, this
is pretty interesting.
Yeah, definitely.
Well, I'm going to talk about Python pre-built a little bit.
This is big news, Brian.
I'm glad you're covering it.
So, Python build standalone is a project that we've talked about on the show, but mostly we
talked about it in association with uv.
Because if you use uv sync or uv install Python or uv virtual environment or uv vnv and then install
and use Python there, if it can't find it on your system, the Python in your system, it's
going to pull it from Python build standalone, which is a separate project, not part of uv.
So, we've discussed that.
But the big news right now is that Python build standalone is now part of Astral or under the
Astral umbrella, which is huge.
So, yeah, we're going to link to an article from Charlie Marsh, head of Astral, saying a new
home for Python build standalone.
There's also a, it just says we'll be taking over, we'll be taking stewardship of this project
from Gregory Zork, I don't know, cool last name.
Anyway, the foundational project for building and installing portable Python distributions.
And there's a link to Gregory's announcement also.
And the discussion around that, like the Python build standalone powers UV, powers Rai, also
PipX and Hatch and more.
And it's got like 70, 70 million downloads so far.
Wow.
Pretty big project and definitely instrumental to going forward with Python or with Python
packaging and using Python.
So, Astral is really like trying to make uv with along with this Python build standalone project, the new way to install Python.
And for me, it is.
I'm using it all every day now.
So 100% same for me.
So pretty short article talking about this.
But it is kind of interesting.
It talks about what the project is at first.
It talks about the future of Python standalone Python distributions.
Also, what they have in mind for the project.
It looks like they want to keep the project up to date with Python releases, of course.
And then upstream changes to the CPython build system, possibly.
And then remove some of the third is remove some of the project's existing limitations.
What are the existing ones?
It ships some MUSL-based Python builds.
They're incompatible with Python extension modules.
I don't know what that means.
I don't know what MUSL is, so I'm going to move on from that.
Okay.
And then improve the project's Python build and release process.
Just a good stewardship for this project, and I'm really happy about that.
Along with this, I was interested to read a thread from Charlie Marsh about what said Python build standalone has exploded
in popularity with over 70 million downloads all time.
I'm going to put a link to this thread on Blue Sky into the show notes also, because it's an interesting discussion.
And I learned something through here that I didn't know before.
It said that the Python...
I didn't know this.
That the Python.org download, the download from Python.org, it actually downloads an installer that builds Python from source on your machine.
For Linux.
Okay.
It says for Linux.
Okay.
So for Linux.
Yeah, because the macOS and the Windows ones install way too fast.
The building Python from source is like a 10-minute deal if it runs the tests and stuff.
Okay.
Yeah.
So I didn't think I was doing that on...
Yeah.
Anyway.
You didn't get the error VCVars bat that couldn't be found?
No.
I haven't seen that for a while.
So yeah, I guess a bigger deal for people that are not running Windows or Mac, but that's really like all the servers and stuff.
Yeah.
Well, I think the other thing that's really non-obvious here is like, what is this build standalone anyway?
Why don't we just download the installer and just run it or just take the result of the installer and clunk it out into your machine or something?
So my understanding is the non-standalone one depends on other foundational things in the system, especially in Linux, but also in other places.
If you want to be able to just copy it over, you can't do that.
And so one of the things that they're talking about, one of the four points of the direction that they're trying to go that Charlie laid out was trying to upstream some of these changes back into CPython itself.
I think it might be number one of the future.
Yeah.
Upstream the...
No, number two.
Yeah.
Upstream the changes to the CPython build system because they have to patch Python in order to make this actually build, which is why it's a pain in the butt to maintain.
And then how many combinatorial variations of that do you get for different platforms and stuff, right?
Yeah.
And so trying to say, look, we've done these things to make it build more simply with fewer dependencies.
Let's maybe make that part of Python.
I don't know about you, but I have not seen a single problem with uv Python, Python build standalone Python, compared to system Python.
It's not like, oh, well, the certificates don't validate or this thing doesn't work or it doesn't have SSL or some weird thing like a dependency might be missing.
It seems fine to me.
And actually, I would be more worried about installing it separately and building it on each of the machines I'm installing it on than I would having one install that goes everywhere.
Yeah.
Anyway.
Yeah.
And I can tell you that Pythonbytes.fm is powered by Python 313.1 based, derived from, or gotten from, this method here.
Yeah.
Anyway.
Big news that actually probably doesn't mean much to individual users other than I think that we can try, we had a little bit of concern about whether or not, you know, this one project, it was sitting heavily on one person, one developers to maintain.
And I'm glad that it's Astral helping out with this now, too.
Yeah.
I agree.
And if you read Greg's announcement there, transferring Python build standalone stewardship to Astral, that he talks about how the Astral folks actually for a while have been core contributors to the project.
And they've been working from the outside to help keep this thing going because they realize how important it is to this feature, right?
Yeah.
And also, I read, I don't know if it was in this or somewhere else, but I essentially read that the project was, I mean, Astral was really working on it for several months anyway.
Yeah.
Exactly.
This is mostly an official announcement is all.
Yeah.
But one final parting thought, Brian, is right there in where you are.
It says, as, this is in Greg's announcement, as I wrote in my Shifting Open Source,
priorities in March.
Yeah.
This is an interesting challenge that people can run into with projects that are run by one person, right?
Yeah.
The guy had a kid, wanted to spend more time with the kid, was feeling worn out by the projects and decided.
Well, and also talks about how he really just cares way more about Rust than he does about Python these days, which is fine.
Like, you're not married, you know, for life to a technology, you know, go where your heart takes you.
But that's a challenge for projects that are run by one person.
So I think it's worth reading this thing as well, just for people to get a sense of, you know, when open source projects take off, but it's not necessarily a good fit.
Yeah.
He's also known for the PyOxidizer project, which came close, but didn't quite get us a single binary of our Python apps.
Yeah.
Interesting.
Okay.
Yeah.
I really am.
It's really cool that he made sure that this was in good hands before shifting it over.
Yeah, absolutely.
Absolutely.
All right.
On to the next.
On to the next thing.
So I talked about, there's a theme here.
I talked about the jitters from having too much coffee.
Well, let's talk about mocha.
Maybe if we put some hot chocolate and some sugar in with it, it'll be better.
No, probably not.
So this project, this project is by Delario and it's called Mocha Pie.
So Mocha, let's like work our way inside out.
So Mocha is a high performance concurrent caching library for Rust, not a concurrent caching server like Redis.
Think SQLite, but for caching, right?
SQLite is written in C, not Rust, but it's an in-process sort of deal,
which is pretty, pretty neat.
And it's this itself is inspired by caffeine for Java, right?
This is kind of like turtles all the way down, like ports all the way down.
So it provides a caching implementation on top of dictionaries.
They support full concurrency of retrievals in the high expected concurrencies for updates.
All right.
So thread safe, highly concurrent in-memory cache implementation, sync and async can be bounded by the maximum number of entries,
the total weighted size, size aware eviction, like kicking large things out versus small things.
You can have cache controlled by least frequently used, by last recently used.
Like I want to kick out things that are over two minutes, but if you've got room based on something, that's fine.
You can give them a time to live, a time to idle, right?
Idle is a really cool, interesting one.
Like when was this last access?
So if you've got something that's old, but is used all the time in your app, and it's something that's somewhat new,
but it kind of hasn't got used that much, it'd be better to kick out that new one rather than the old one, right?
Oh, yeah.
Okay.
So that's all just straight Mocha.
Mocha Py is Python binding for this.
Here we go again.
Rust library for Python.
They're probably getting VC money from this.
I'm telling you.
Okay.
No, just joking.
Sort of.
So for the Mocha Py thing, it has a synchronous cache, which supports basically thread save memory.
It just like wraps the thing.
So time to live, time to idle, size of concurrency, all these things that you can imagine.
And so there's a couple interesting ways.
You can just say cache.set some value, or you can say cache.get some value.
That's one way to use it.
Another one is you can use it as, this is actually pretty amazing.
You can use it as an LRU cache function decorator alternative.
Oh, wow.
Right?
So one of the things you can do that's really easy to speed up Python code with not writing
much code, you don't have to maintain much, is you just put a decorator, functools.lru
cache onto it, and it'll look at the hash value of all the inbound parameters and say, if you
pass me the same parameters, you're getting the same output, right?
Yeah.
And it just does that, just straight in Python memory.
But this would be backed by this high-performance concurrent Rust internal library.
It's still in process, right?
Yeah.
So you can say, yeah, go ahead.
Sorry.
With the time to live and time to, you know.
Time to idle, yeah.
Especially.
That's cool.
Yeah.
This is pretty cool.
And there's so much talk about the thing supporting the Mocha itself, the Rust version, supporting
asynchronous behavior, right?
I'm like, okay.
If it has all these asynchronous capabilities, what's the story with Python and its async and
await, right?
Yeah.
So I filed an issue, which I don't really like to do, but that's how you ask questions,
apparently, and then you close it.
So I said, hey, cool project.
Since it says thread safe, highly concurrent in-memory implementation, what's the Python
async story?
Great.
And so they responded, this will work if you put the decorator on there.
So remember how I was complaining that it's sort of weird that the func tools and iter
tools don't support async?
Yeah.
This, this func tool like thing, supports async and sync functions as well.
Right?
So they just have a implementation in the center that says, is it a coroutine?
Do this else do that.
So you can use the cache, the caching decorator.
Like we talked about, like the LRU cache thing already async on async functions and sync functions.
So that's fine.
And then I said, well, what about cache, get and set?
And Deliro says, probably doesn't make sense to do it.
It takes 230 nanoseconds.
So you can do 4.4 million calls a second and set is a 1.3 million sets per second for a
cache size of 10,000.
That's fully occupied on a simply M1 Mac.
So, you know what?
Hmm.
Probably not, but there might be some, some, ways to expand this in the future.
I don't know.
But yeah, I would say probably not, probably not needed because you're going to probably
add more overhead just to juggle the async stuff.
Right?
Yeah.
And also just if the, if the supported,
method is through the decorator and whatever you need, you could just put like your code
in a function to do.
Yeah.
I mean, if that were Redis, you would absolutely want an async version because you're talking
to another server.
Yeah.
And there's that latency in the network and all, but yeah, if you can do 4 million a second,
then probably I doubt you can do 4 million awaits a second.
So that it's much lower.
So the cache get and set really are just that where you, the benefit of those is, is probably
just for, because we want a really fast caching system or something.
Yeah.
Yeah, exactly.
And you, there's plenty of times where you say in this situation, I want to get this out
of the cache and then keep it for a while.
Like if I had a user who logged in and I want to just hold their user account with all their
details and I've used their ID as the key and their actual user object as the object that
goes in, that's fine, but you wouldn't, you wouldn't use that as a cache decorator because
typically you might see that coming out of a database, something like that.
And then if you pass the same user in, it's like, it's similar, but it's a different database
object.
Right.
You can run into real weird situations where they're equivalent, but they're not equivalent,
you know, and then you end up not using cache.
So anyway, I think that might be where you would do it.
But anyway, I think this is pretty cool.
People can check it out.
Yeah.
And it's, it is not, I don't believe it is like super popular here.
And you know, a hundred stars, it kind of shine a light on it.
But if you go over to the Mocha thing, you know, it's got a thousand, 700 stars and this
is kind of just a Python UI on top or API on top of it.
Yeah.
But it's, it's pretty recent.
I mean, it's a few weeks old.
Looks like.
So it's just a baby.
Just a baby.
It's okay to have a hundred stars.
Pretty good for that.
It's pretty good actually.
Yeah, it's pretty good.
It looks cool.
So now, you know, all right.
I want to shift back to uv.
I'm kind of in a uv mood.
I'm missing the sun apparently.
But the, there's an article from SAP, from, from the SAS Pegasus blog about uv and in-depth
guide to Python's fast and ambitious new package manager.
And a lot of people have written about uv already, which is great.
But I really, I have been really excited about when I thought, when I learned about uv sync
and started using that and all the different ways to use uv.
It's a pretty powerful tool.
So it's not really one thing.
It's designed to be a lot.
So, so I appreciate, you know, articles like this, but also I really like this one.
So it starts out with pretty much who is, which is a funny meme of, of a whole bunch of different
commands to install, install Python and update it and install, create a virtual environment
and sync your requirements.
And all of that is just done with uv sync.
Now you can do it all in one, which is pretty sweet.
I don't use uv sync.
I use UV, V, and V, dash, dash, Python 3.13 or something.
But, you know, same.
Yeah, I'm using both depending on whether or not I have a project set up already.
So it talks about what is UV, why use it.
And we're just going to assume that you already know if you listen to this podcast because it's
really fast.
But a lot of discussion of different workflows talks about installing, adopting uv into your
existing workflows, doing install.
But I'm going to pop down to the end, adopting uv into your workflow.
There's this cool cheat sheet.
This is pretty much what the entire article talks about, the different parts, is you can
use uv Python install to install Python.
You can use virtual environment or VENV to create virtual environments.
It's really fast.
And then install packages with uv pip install.
But then also you can build your dependencies.
Like we would have used pip compile.
You can use uv pip compile.
But it's all in one place to all these different commands.
And these really are the commands.
The commands listed in this article are really the way I use uv as well.
So that's why I appreciated it.
And then a discussion about how to adopt this into your workflow and what that means to
get, you know, talking about.
I mean, a lot of people might not have used sort of lock files before.
But using lock files with UV, it's so easy that, you know, why not?
And pinning your dependencies.
Just some good workflow.
It's good Python project practices anyway.
So why not?
Yeah.
That's great.
And there's even a few more that you could throw in for the tool, like the equivalency
table there.
Yeah.
You know, there's you.
There's you for installing CLI tools.
You could say pip X.
Yeah.
And just create a virtual environment and install the things and make that in the path and all
those sorts of things versus uv tool install or uv run.
Right.
Those kind of things as well.
So, yeah.
Yeah.
It's missing that, which is, you know, I'll feed it back to Corey.
So one of the reasons why this came up on my radar is I'm working on a project that uses
SAS Pegasus.
So I'm in touch with Corey a lot.
Yeah.
But like the UV, the tool thing, instead, I'm not using pip X anymore.
I'm the uv tool install is like super cool.
So, yeah, it's super cool.
It is.
I've also started using Docker for certain things as well.
So, yeah, it's kind of kind of similar.
But like, for example, Glances, which is a Python based server UI visualization tool,
you can just say Docker run Glances versus installing Glances.
And you just leave this machine a little more untouched.
Yeah.
One of the interesting things about this article was the point of view, because at the start,
Corey talks about how he's not usually somebody to jump on like multi-tool fads, like pipenv
or pyenv for installing.
For doing virtual environments better and big project-wise.
And I like Hatch, but I'm not really a using Hatch for my entire workflow sort of person.
I was using it just for a packager.
So, yeah, I'm in the same boat of like, I didn't really need an all-in-one tool, but this one changed my mind.
And I really like this all-in-one tool.
So, yeah.
I'm still not bought into the project management side, but I love using uv for the stuff.
Yeah.
Anyway, what do we got next?
We have a quick bit of follow-up here.
Okay.
I just did some searching.
So, over on PipX.
So, one of the things that, you know, you say like, you could use PipX or there is an open issue on PipX that says integrate uv in some way.
Right?
Because PipX is really just a wrapper around create virtual environment, pip install package, pip install dash U package.
Right?
And so, if they just change the internals to say uv pip install, then PipX would all of a sudden become super awesome.
This recommendation is unfortunately over half a year old, but it does have 21 upvotes.
So, you know what?
Yeah.
Who knows?
That's there.
Yeah.
Okay.
Yeah.
Okay.
But that's not what I want to cover next.
Come on, computer, respawn.
There we go.
I think that's it for our items, right?
We're on to extras.
Let's have extras now.
Yeah.
Let's extra it up.
Extra.
So, registered for PyCon, I did.
Oh, cool.
Yeah.
Registration came out two days ago.
I don't know.
Whenever I posted some message on Blue Sky and Mastodon saying, I registered.
How about you?
Whenever that was, that's when the announcement came out.
So, I think a day and a half ago or something like that.
So, there's early bird pricing and all details on there.
If you want to go and check it out.
It's normally $450 for individuals, but you could save $50 if you register for January,
which is pretty cool.
There's a bunch of stuff.
It has all the detailed timeline, which is always interesting.
You know, like, if I want to make sure I attend the PyLadies auction, when do I need to do that?
When is the main thing?
When is the job fair?
Et cetera.
So, most importantly, main conferences, May 16 to May 18, 2025.
So, there it is.
And congruent with current times mask policy.
Hooray.
Optional and encouraged, but not required.
Yeah.
How about that?
Yeah.
Cool.
Okay.
Got a few more real quick ones here.
I recommend, you know what?
It's something I came across just thinking, like, why don't I support more open source projects?
Looking at my dependencies and stuff that I'm working on.
Like, how much, you know, if everybody who used Flask put $1 towards it per month.
Everybody who used it in an important way where it's not just like, oh, I did a tutorial with Flask.
But, like, no, I have a project that is important to me and I use Flask.
If everyone put $1 towards it, it would transform that project.
If everyone who used G-Unicorn put $1 towards it, that would transform it, right?
So, I decided, you know what?
I'm going to just go to some projects and find the one that I use most.
And, yeah, I found four that had sponsorships that were available.
I was going to support uv and Pynantic as well.
But they, for some reason, they do, like, corporate sponsorships.
Or I tried to do individuals and it didn't work.
And then some other ones, like Beanie, don't currently have sponsorships.
But, you know, are really important for the database layer and stuff.
But just think about, you know, put a couple dollars towards some of these projects.
It'll make zero difference to you if you have a job as a software developer.
And in the aggregate, it'll make a big difference to the health of the ecosystem.
Yeah.
It's interesting to think about like that.
Like, just, you know, a couple less coffees a month.
And you can help out.
You probably cover, like, three or four projects.
Yeah.
Anyway.
I want to encourage people to do that.
But, you know, can't.
Obviously, don't.
But I don't think it's a big deal.
Come here, computer.
Very slow for some reason.
Don't know why.
There we go.
All right.
This is the joke.
So I'm skipping the joke for a second.
We'll come back to it.
There's two things that I wasn't planning on covering.
But I'll throw out here really quick.
Yeah.
Here's my register for PyCon.
I also wrote a quick.
People said, oh, my God.
Hetzner.
We moved to Hetzner.
And they changed this huge thing where they changed their bandwidth and their price.
And it's like a no nothing sort of deal.
Like $5 a month more.
Anyway, I wrote that up so people can check that out on Mastodon.
And then, yeah, that's it for all my items.
Okay.
And then I just got the joke when you're ready for that.
So let's do yours.
I don't have much commentary on these.
I just have a few extra things I wanted to point out.
Pydantic AI was announced, which Pydantic AI is a Python agent framework designed to make
it less painful to build production-grade applications with generative AI.
I don't have really in the commentary about this other than I didn't see this coming.
But interesting.
Yeah, I've seen messages or tweets or whatever from people who do machine learning stuff saying,
you just need Pydantic.
I mean, a lot of this is like, I got a JSON thing here.
And then I'm going to call some other thing with other JSON and just suggesting, hey, you
could probably use Pydantic to make these connections.
I bet the Pydantic team noticed that as well.
Okay.
A couple commentaries on maybe society.
And anyway, I'll leave it.
Leave the couple other articles I thought was interesting.
Blue Sky announced, I guess this is old, this is from August, but anti-toxicity features on
Blue Sky.
And I just actually appreciate some of these.
I already have hit, I had a troll come by.
And so there's some things where you can, if people, you can detach a quoted post.
If somebody quotes you and you don't want them to, you can detach yourself from that.
Oh, interesting.
I had hiding replies.
I had some, a troll, you can't like delete replies, but I had somebody just, just idiotic reply to
something I said.
And it was obviously just a bot or a troll.
So you can, you can hide that.
And as, you know, as Blue Sky grows, we'll, we'll get trolls also.
If they're, if they're not affecting you yet, they, they may in the future.
So, so we do appreciate that there's, there are features around to protect yourself.
So there's, there's that.
And then, this, I don't know what to make of this really, but Wired, fairly mainstream
magazine, I think, has released the Wired guide to protecting yourself from government
surveillance.
Wow.
I'm, I just, this is a head shaker of like, I guess we need this.
I wish we didn't, but wow.
Um, yeah, there's that.
So, yeah, I can probably say that about some state governments as well.
Right.
Every state's different, but yeah.
Yeah.
Pitting on your gender and things, you know, it's touch and go some places.
Yeah.
Anyway.
So, that's a little bit of a downer.
So maybe we need something funny.
Uh, we do.
I don't want to spend all the time going down that, that deep rabbit hole.
Instead, let's go infinitely down the rabbit hole.
Yes.
So check this out, Brian.
Somebody who goes by bits, very personal on, on, Blue Sky posted what the comments
seem to indicate is probably a textbook.
A print is a printed, by the way, a printed textbook on a LaTeX.
Okay.
So, I'm going to see you in the index at the back.
And it says, see page 252.
I love it so much.
It's so simple.
I love it.
Yeah.
It's a really good, just like a little Easter egg in there, isn't it?
Yeah.
I, I've, I haven't seen it for infinite loop.
I saw that, somebody did that for recursion.
In some, yeah.
Yeah.
They, they, they're, if you look in the comments, it says that, Carrington and Richie has
the same, I guess that's probably C or something.
Yeah.
The same in, under the index for recursion.
And, it's pretty, pretty good.
People love it.
Yeah.
No, that's funny.
And there's somebody that says, for those who can't be bothered, search, Google search
for recursion.
Did you mean recursion?
Yeah.
Um, I kind of feel bad for people that actually really need to know what that means.
Good luck.
Yeah.
Good luck with that.
Huh?
Uh, so.
Wow.
Yeah.
All good.
All good here.
We know what recursion and infinite loops are, but we're going to break the loop and get
out of here.
Right?
Yeah.
Let's break the loop and say goodbye until next time.
So thanks a lot.