Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 366, recorded January 9th, 2024. Welcome to the new year.
I'm Michael Kennedy. And I'm Brian Okken.
And Brian, this episode is sponsored by us. Support our work by taking our courses,
the Talk Python training ones, the complete pytest course, and as well as through our
Patreon supporters. All those links are at the top of your show notes and your podcast player,
episode page, and so on. Connect with us over on Mastodon. You'll find us all on Fosstodon.
That's right. Michael, Brian, and the show. It has its own pronouns and gets thrown into the group
and has its own website and all that. So come see Python Bytes over there as well. And if you want
to be part of the live stream, you're welcome. That's certainly not required to take part and
enjoy the show. But if you want to be part of the live stream, pythonbytes.fm/live. Usually
you'll see some scheduled upcoming one. You can click, you can, you know, smash the bell,
crush the subscribe, all the things they say over there. Yeah, Brian, it's been a while. Welcome
back to the show. It has been a while. I'm excited to be back. I am too. Thanks everyone for, you know,
being patient with us while we took a little break over the winter break. It's always a little bit
tricky to juggle that kind of stuff, especially Brian, when you're on a beach and it's 80 degrees
Fahrenheit or 20 degrees Celsius, 22, something like that. It was, it was a windy day. It was,
there was one day it was windy. It was, it was rough. I'm really sorry about that.
Thank you. Thank you. I appreciate your balances. Yeah. Brian, can I, can we maybe not skip this
episode because I'm in Hawaii hanging out on the beach, sipping drinks? Yeah, no, no, no,
it was lovely. It's good to get away, but it's also really good to be back. So yeah. Yeah. And I
missed you. Yeah. I missed you too. And everyone missed, missed the audience. shall we shit it
off? Yeah. 2024. Let's get it. Let's get started. Let's get started. Okay. So, Anthony shot. So
one of the things that's possibly hopefully coming into Python 13 is Python 3, 13, sorry, we're not
all the way up to Python 13 yet. We're still in three, three that 13 is a jet compiler. It's,
and, and I'm, I'm with, because of like, you know, Java and other languages, I'm familiar with
jet compilers, but pythons is going to be a little different. So Anthony Shaw was kind enough to write up,
um, a article kind of walking through it and it's a really nice. there's a couple of things that I,
I recommend reading it. If, if you don't really know what a jet compiler is, or if like me,
you didn't know what a copy and paste jet compiler or jet, whatever implementation is. So that's kind of
where he goes with this. And he, he starts off talking about really what a, what a jet is. And
really it's, it's something that basically generates your, your semi, your compiled code
for a lot of times it's compiled code, machine code. but for Python, it's going to be, the,
not the compiled code, but the byte code. So getting the byte code ready, I think I may have gotten this
wrong. but, we, he walks through, kind of what a, what a compiler is or a jet compiler is
with, with the, as if you were writing it in Python. So he goes through a little example of making your own
Python version of the CPython interpreter, like, which is actually written in C, but if you were to write
in Python, it might look like this, like, switching on op code of load instruct load constant,
things like that. and you can see what those primitives are by using the disc, disc, module
for disassembler. And, and that's fun. The, and then he walks through kind of, okay, so that's
what a, what a JIT compiler might be. What is a copy and patch JIT compiler, not copy and paste copy and
patch. And, and that's a little, a little bit more harder to describe over audio, but he, but,
but Anthony does a really good job describing it. And, and then talking about really this thing,
it, instead of like copying a piece and then running it, it copies like more than one bit,
like the entire function and then bring the whole thing. And it's a little bit faster. And, and then
we're going to do something like that. It's going to be something like that for Python inside of the Python
C, interpreter and how to that's, it's just a good walkthrough to kind of understand what is going
on. What are these people doing and why? And the why is it's going to be a couple of things. It's
going to be faster. and in his, there's some benchmarks that show it's from like two to 9% faster,
which is great. I mean, actually, anytime you can make things a little faster, it's good. but,
but is it worth it for this in it's, it's worth it for this partly because mostly it doesn't make
it slower, which is the good part because, because of this JIT compiler, there's other tricks that they
can do down the line to make things a lot faster. So this is, this is great news and a good explanation.
Yeah. It's super exciting. And you're on top of the news today, Brian, like this came out this morning.
So, well, well done. This is brand new from Anthony Shaw. Anthony, excellent work. writing this up and,
um, all the things. So one part that's interesting is two to 9% is great. Like that's still really good
to make things faster. Yeah. But he also points out that this is just the foundation. Like once you have
a JIT, there's all kinds of interesting things that JITs can do on a per hardware architecture,
per platform story, right? They can say, well, you wrote this code, but I know we have these specific
machine instructions, specialized machines, instructions on this CPU. So let's make it do
that. Or I see that you could actually inline this function instead of just make it run faster. We could
inline it over here and here and here, and then, you know, function calls in Python are expensive.
So maybe they just become not function calls, right? there's, there's a lot of possibility for
where things go. It would be interesting. I wonder if you could even do things like, you know,
compile stuff to see, and you see optimizations as part of the JIT compiler, right? Like maybe there's
a bunch of like layers that could happen. I don't know, but yeah, basically this is, you know, a foot
in the door for compiler optimizations that we've not had before in Python.
Yeah. Yeah. It's pretty exciting. So, yep.
Excellent. Excellent. So the future is bright. Also compounding is interesting, right? Right.
We're supposed to get Python much, much faster by making it like a little, a little bit faster over
five years continuously. Right. And this is just part of that, right? So you keep adding the things up and
the Python, I don't know, three, 14, 15 versus three 10 when they started could be super, super different.
Yeah. All right. Let's, I hope people like deploying, packaging, bundling, talking about managing
your projects because that's all I got this week, Brian. I got one after another. So let's start out
with this, Mastodon post by Bass Neiholt. And Bass says, we're launching Unidep, which is a
unified Conda and pip dependency management system. Okay. So we've got the Conda world, we've got the
PIP world. Sometimes they kind of work together, but they're pulling from different sources. So you can
like in a Conda virtual environment, you could pip install a thing, I believe, and it would still
install, but here's the deal. Like you can create a single requirements.yaml file and say,
I depend on these different projects. Those two come from Conda, Conda forge or something.
These three come from pip IPI. Interesting, huh?
I'm actually excited about this. This is very interesting.
Yeah. It's super interesting. It works with pyproject.toml and setup.py.
It also is good for monorepos. So why is this good for monorepos? Monorepos are,
I don't want to have to switch projects on GitHub. I just want one ginormous one for a whole company.
So let's just have one, right? Which is kind of an insane way of working, but it's also pretty
interesting, right? Like I've got two libraries. They depend on each other. It's just all on the
same project structure. So, you know, you just version them together, but that's literally every
project for your company. And there's different teams potentially working with different versions
different things. So maybe there's some data science folks and there's some web API folks and
the web API folks are maybe pip and the data science folks are Conda. So here you could express all of
the requirements for the different projects through these different sources, right? Because some might
be Conda, some might be pip, but here's one, one way to express it. Also, it'll create consistent
Conda lock files for multiple projects. It has a platform support and you can just,
you need up install if you want, which is pretty cool. So looking over at the GitHub here,
yeah, pretty much, honestly, pretty much says the same thing, but it shows you some examples of,
you know, how you might express, you know, what is, what is a Conda dependency? What is a pip dependency?
So like in your requirements.eml, you just have dependencies. Let's just say numpy, or you'd say
Conda colon Python graph is, or you'd say pip colon graph is, if you wanted that one and so on. Right.
And look at this, you can even include other, you have like nested requirements.eml, which maybe
talks to the monorepo type of thing or multiple projects just in one repository, right? Like this
thing actually requires these four other things. This, this is even interesting. You know, we were talking
about courses and I know you're going to mention something about your course later. This is actually
would be really nice for courses as well to do. And I suspect you probably could do with pip. I just,
it never crossed my mind. Right. I might have chapter one, let's do FastAPI stuff. Chapter two,
let's add Beanie and MongoDB. And like those have different requirements files. And you might want
to just be able to express like, well, just run this one, just run this thing. You have everything you
need for the course, but you also want to not like talk about everything before you get to it. Right.
You could have like one at the top of your course repository and then every chapter have its own
one of these and then just like pull them together with this, like this.
Oh, interesting.
That's cool. Right.
Yeah. I've never really thought to do that.
I haven't either, but it seems like I should, I've just been copying that stuff around. Seems
like I shouldn't do that really.
Awesome though. Yeah. So, uni depth, it's brand new. I don't know if this thing's gonna
take off and be super, super popular or if it's going to be kind of niche, but you know,
it seems like it's solving a unique problem. And it really is kind of a time of like a thousand
flowers blooming in the packaging and dependency managing space. Like previously we talked about
hatch. I have more to say about hatch later as well.
Do you remember, did you say that it were, you, you can use a pyproject.toml instead of,
yes, you can. Okay. Yes. It's a,
because there's already enough YAML in my life. Yeah. Yeah. You can use a pyproject.toml. Cool.
Alternatively, one can configure the dependencies in the pyproject.toml under the tool.uni depth
section. All right. Nice. There you go. Yeah. All right. Well, over to you. well, I would like a
lot of people I've been, doing some work over the holiday break since we also took a break from
podcasting a bit. I've been doing some open source work and I ran into, this is timely because I
ran into, some problems with, with pull requests and wanting changes, changes in pull requests
and having some of the problems with if somebody, does a pull request and their fork is on main
instead of on a branch. And so, and it causes problems. and so instead of having to write this
up as to why you should not do this, Hinnick beat me to the punch and wrote this great article saying,
don't start pull requests from your main branch. and it's, it's tempting, right? when I first
started using get at work, even at work, the, so personally, I, when I was started using get,
I just used main and, and just checked. I just had one branch and that's no big deal with my,
my own stuff with a, with a team. We had to decide, well, we're going to use, branches or forks.
Um, and, possibly not both, but you can use both. And in open source, it's common to use both.
And what we mean is you fork the repository and you create a branch. why do you do both? Because
it seems like if you're going to make a change, you just need one or the other, right? And you can't do
a branch because you don't have permission. So you, you do a fork, but you do both a fork and a branch
for reasons. And the reasons are spelled out, here first. if you, if you didn't do that,
he's, he's giving the reasons in the sense of if you did main instead, why that's bad is first,
um, you can only do one pull request at a time. If you were going to do your pull request off of
your main branch and it's not been accepted yet. Well, you can't, you can't go and do another pull
request for a different change. You can't do another fix because you've already used up your
main. whereas if you do a branch off of that, you can have as many fixes as you want.
So that's reason number one, but people might think, ah, I don't care about multiple stuff.
I'm just fixing the one thing I care about. Great. if it takes a while, so somebody on the other
end is going to have to pull, like review it, maybe ask you for changes to, maybe, merge it
even that's great. If they end up merging your pull request, that's awesome. But the, what happens
then is it'll, that branch will have changes of both the, both the main line and your branch
all in this branch, your main branch. And now that has conflicts and you're not able to pull it back
to your local repository. So polls won't work. And you just, you, I don't know what you do at that,
at that point, you blow away your fork and start over. You delete your repository to start over.
Yeah. lame. okay. The third reason is, is the pragmatic one of getting something done.
And this is the one that bit me, a couple of weeks ago is, eat, there's two reasons you're,
um, I may, I might be like messing this up, but, you can, if you have it on main it's,
and you have branch protection on, which a lot of repos do most of most, a lot of big open source
projects, the main is locked down. then, and you don't want, you want to allow it's allow
edits from maintainers, is meaningless at that point, because what I want, want to do is if there's,
if somebody does a pull request and I want to accept it, but there's a minor change to it that I,
I want to like tweak it. Like maybe the, I don't know, the naming convention's wrong and it's not a
big deal. I can just change it before I merge the pull request. You can't, if, if that's locked
down the, the original, the person pulling into their, their, repository can't do that edit.
And it, it's just not nice and it's not fun. So, just remember to do fork and branch don't do just
fork. so that's, that's the, public service announcement for today.
Yeah. I mean, fork is required because you, a lot of times you don't have right access to the main
repo contributor access, but doing it from your main, doing it from like some other, the main branch
instead of some other one is yeah. You only learn that that's a bad idea when you do it. And then
you're like, Oh no, now I've done that once or twice. I'm like, I'm going to make a change and do a
pull request and submit it. And what if they don't accept it? Then your main is out of sync forever.
You can never sync your fork up again. And like, there's just all sorts of.
And, and even if there's no ugliness there, let's say there's, and this has happened to me many
times, you, and somebody wants to, to merge your stuff in, but they're merging other things
too. And maybe they grabbed a few other things first. Now they, they really would like to have
the merge from yours be really clean and just see the changes. So the great thing to do is to merge
your, the new main to your new main, and then resolve it with your forked brand, your branch first,
before going all the way back. And if you don't have that, it just doesn't work.
Yeah. That's a good point too. Indeed. Indeed. All right. Let's get back to deployment.
Okay. This one's different. Okay. Installed. This is kind of like a,
like a little bit of a web 2.0 name installed, but zero vowels installed.
Oh, in S I N S T L D. So this is an interesting project. When I first saw it, I was like,
this seems like a bad idea. I don't know. This seems like just a bad idea. Let's not do this.
And then people kept recommending it and saying stuff like, you know what, actually,
that's kind of cool actually. So here's the deal. Previously, what we talked about is like
the right way, right? You're going to create your requirements, your dependencies,
you're going to have pin versions. You can have lock files. Someone is going to create a virtual
environment or a Docker container or something like that. Then you're going to install all of those
things, right? Right. What if you don't, what if you have, Brian, what if you have a single dot PY file
you want to give to somebody and you want to just let them run it, but you know, it needs like one or two
dependencies. Like maybe you really, really, really want to use rich because Will's project is awesome.
And you just don't want it to look plain white, unformatted. You want it to look good, right?
So you want to be able to handle one of your coworkers or somebody else, one of these things
and say, just run it. Well, just run it becomes all of a sudden a conversation about virtual environments
and all these things. Right. And like, ah, geez, just, just want to format it just a little.
Could we somehow, well installed is kind of aiming to solve that problem. Right. So it's not like a
high-end production sort of thing. It's a, let me be able to pass a file around without going through
the whole process of, you know, like PI installer because like, well, oh geez, I made it exe for you.
That's right. You're on windows. Let me recompile it. Like, okay, great. No. So here's the deal.
It lets you run Python code without installing the dependencies, without mentioning the dependencies,
without having any awareness said dependencies. So, so exist with one huge caveat. And that's,
you must have installed installed. Okay. Once this thing isn't there, it can then bootstrap
everything else. So maybe like, if this was a thing you were doing with your coworker story,
I said like, okay, well everyone pip install dash dash, user installed or, or pip X installed,
or I don't know, something like that. Right. But once that's there, then you can run and use arbitrary
things from PyPI without having them installed or requirements file or going through a step. You
just Python space, your thing off it goes. Also, if you were in a really weird situation, but you had
to do it, you could use two versions of the same library package within a single execution of a program.
Okay. Interesting. Which you might do that because you have incompatible libraries. Like I've talked
before about there are times where I literally cannot pip install dash R my requirements. Right. It's just
like, Nope. This old janky version of some library depends. It's pinned less than something else, some
other library. And then like another library is greater than that same library. Well, modern pip just
says, guess we can't run your program. Take a hike. Right. So this would let you sort of, say this part of the
code uses the old janky thing. Let's use it and then get rid of it and then go back and use another.
All right. And also doesn't leave behind junk on your hard drive. It basically deletes everything. So
how does this thing work? So basically in your code, you can say you have to import installed,
and then you use a context manager. You can say with installed some package, and then you can use,
like within that context manager, you have access to that. Pretty wild, huh? Okay.
So basically that, that context manager will make sure that it's installed on your system. It'll
download it, all those things. And then like when presumably when it closes, it'll delete it.
You can also do it as a REPL. So you can, you know, interact with just like the Python REPL. You can
interact with it that way. you can run a script. You can say installed some script, and then it'll,
um, be executed as if you were running it like regular Python, but it'll, you can also pass in,
um, dependencies that it might need to run it. Right. If you're like this out, if your program has
imports of any packages other than the built-in ones, they'll be installed automatically.
Right. So you just say installed some Python file and it goes, oh, you're saying import this stuff.
You're import, you know, HTTPX. Hopefully you got the names, right? Yeah, exactly.
So yeah, anyway, you can do a bunch of, a bunch of more advanced stuff you can talk about there.
You can pin the versions. You can specify, which IPI, which package repository it comes from.
If you have like a, the example here is a test one, but if you've got like a private whitelist
server and so on. So there's a lot going on here. I don't know. How does this, how does this hit you
seeing this?
You know, the W I was, I was thinking I don't need it up until just a second ago where I know when you had you with the eight, being able to do multiple versions in the same file, even to say, like with, like, as an example, normally I, I test against multiple versions of PI test, for instance, or multiple versions of something. Like in my own stuff, I'm testing against maybe a few different versions of a particular.
package. and I do that usually outside in talks to be able to, to, to install a different environment, set up a different environment to with those different, different things installed, but to be able to do it all in one run, that's pretty interesting.
actually. It is interesting. Yeah. Yeah. So it's pretty interesting. apparently when it runs, it spits out basically the pip output, you know what I mean? It are, it comes, but in the context manager, you can say catch output equals true. And then it's kind of invisible to your users. It just takes a little startup time as it does the dependency stuff, you know? So yeah, yeah, yeah. Pretty wild. So when I first saw this, I thought, this seems like it's encouraging people to do the wrong thing, but it's, it's also some interesting flexibility. So there you have it.
and sold. And sometimes people need to be encouraged to do the wrong thing. That's right. How else do you learn to do the right thing? No, just kidding. Yeah. All right. what, what do you got for our extras?
I got a couple extras. I am super excited. The other thing, one of the things I was doing is open source code this break, but I also was, I was completing the complete by test course. so, I named it the complete by test course before it was complete. Now it actually is complete all 16 chapters. However, it's not, it's never really going to be done because this isn't a printed book. It is, is, is a project. It's,
it's a course that's up on the web and I'm going to update it if I need to. So, I've, it's, I've got a good community going with it already. And, and we're going to, make sure that it's up to date with new versions of by test, like, by test eight is coming out. And if I, I don't think that I'll have to change anything, but if I do have to change stuff, I'll change it here first.
you can just do a fine replace for a seven to eight and you're going to be fine.
I don't actually put seven in there anywhere. I know, I know. but, but there might be some new toys that we want to play with and there already were. So one of the, one of the fun things was, was get in getting this is, is going through and being able to say, Oh, I do things a little differently now. Like one of the parts is building a, a, a pie test plugin.
And I package a little differently now than I did several years ago. So, I got to use the new, new way and we're keeping that up to date. So that's the first thing. The other thing is this course took a lot of my time actually to get this to, to the point where it is now. And, and so some things went on the back burner and a couple of things were the other podcasts. So Python people and Python test, Python people has new people. Will Vincent, and I've got a whole bunch more than I need to release, but Will Vincent was on in October.
And I finally got this released, and we talk about Django and writing technical books and Will's awesome. He also is the, the host of, Django chat podcast. and then I don't have any, the last, Python test episode was out December 15th, but I've got a whole 16 of them planned. They're not recorded yet, but 16 are planned. So these will come out in the next few months. So stay tuned.
Awesome. Awesome. How about you?
Well, I have a whole bunch of talk Python stuff coming. I think I have 12 scheduled or something.
And it's kind of out of control to be honest, but I've got some extras that are more relevant here.
Okay.
Not see the joke yet. That is the end. All right. So Ofec just sent us a follow-up and it's a little unfortunate that we talked about this big release of hatch 1.8.
And then went on a two week break because like the next day he said, great coverage on hatch 1.8. Thanks. However, one small correction. Remember I was so impressed and psyched that the binaries of your apps, if you made apps with hatch, which is a cool, cool feature of it would be signed. I'm like, how are they doing this? How do they get away with doing this? Well, they're not.
So he's a one small correction. Only the binaries for hatch themselves are signed by the certificate of the PSF, not the binaries created by hatch for you. Those are your certificates problems.
Okay.
We're back to signing our own apps again and dealing with Apple and Microsoft and all that stuff.
Okay.
But it makes more sense, right?
Okay.
Uh, next, this is just interesting.
Um, high PI had new user registration temporarily suspended there.
Um, the volume of malicious users and projects being created outpaced the ability to respond to it in timely fashion.
So like, we just need to slow down.
No action required.
This is from last week, just interesting.
And I guess, you know, thank you everyone for being on top of this, honestly, because what a hassle.
Um, I also would, I don't know what they're doing right now, but at least I would recommend, I don't know if it would really help, but like cloud flare, turnstile, at least stop, stop the bots, you know, which is a way, way, way, way, way, way better, way better thing than the Google recapture.
I think so.
Yeah.
Maybe if, if some kind of gate like that would be awesome, then put that up.
Anyway, that's news.
Also coming up next February, February 12th, which is in 33 days.
I'm doing a YouTube only thing on talk Python that I think will be really fun with Martina Puglisi about data doodling.
So she's got this whole cool series she's doing where she's doing, data science by just sketching it out and just drawing pictures and trying to understand data before jumping into like notebooks and stuff.
And so we're just going to talk through some really fun doodles and it's all visuals, which is why it's YouTube only not on talk Python.
Exactly.
But so if you're interested, please come and, click the get notified to register and quotes, to be part of that, that live event.
So hopefully people will, that'd be really cool.
I think she's got some beautiful, beautiful work and you'll appreciate when we'll get there.
Uh, and wrote an article called, which maybe should have R in the front.
Are AI features a waste of time?
So my premise is that, I'm just wondering like how many cumulative programmer hours have been utterly wasted on adding very mediocre AI features to every app imaginable that you rarely ever want to use.
You know?
So I just lay out like a couple of issues, like look at all these, these examples of apps that just like they're adding AI for the sake of adding AI, but it's not, you know, not bashing on like ChatGPT or something like it was just like, oh, you can click this to like,
correct the date by AI.
Like I just type the date.
Why do I need the stupid thing?
Right.
And, another, this example I use with spark email, which has this really cool, Brian, see how beautiful that is.
You can write beautiful emails in spark.
Love it.
Right.
But if you try to proofread it with AI, it deletes all the content, the images, and it just like jams it back as plain text, like response from ChatGPT or something.
You're like, dude, that's not what I want.
I want to ask for you to proofread it.
Like why?
Why there's this app is full of little tiny bugs and like, they're adding this, like who, who would ever use that?
If this is the outcome of what you get, you know?
Anyway, another example, would be the Dropbox fiasco where they just silently turned on.
Hey, we're sending all your documents to, open AI.
I hope you don't mind.
Do you have anything private?
Probably not.
It's fine.
Right.
Like, wait, why did you add?
Nobody wants this.
Why do you turn this on?
Or why are you sending my data on a Dropbox?
This is not right.
So anyway, hopefully people will enjoy this article.
I have another fun one.
Let's say another fun one coming.
I forgot to turn that off.
Oh, well, you can ask ChatGPT about that.
God, God, no.
Yeah.
No, honestly, it doesn't actually send it unless you interact with one of the, like a text box.
It says, do you want to ask this thing and the AI about your doc?
But if you ask it, then it's, then it's on.
Right.
So it's not clear by like entering that text box, that input, you're now sharing your data
with some other company, right?
Like, can we just have like more reliable integration with Finder and Explorer and better sync?
Like, I don't need this AI stuff.
I had, I actually on the topic though, I had like a really cool AI experience.
I went to the dentist and they took x-rays and, and she showed me the x-ray picture.
And then she showed me the picture right next to it where an AI highlighted areas that might
be problems that the dentist should check out and take a look at.
That's awesome.
And things like that, like helping, helping a professional make sure they don't miss things.
Great use of AI.
Yeah.
So yeah.
Proofreading less.
No, that's an awesome, awesome use of it.
Yeah.
Okay.
Ready for the joke?
I'm almost.
Okay.
I want to show one more thing.
I forgot to mention for a lot of people, New Year's resolutions time for a lot of people.
And if your new year's resolution is get better at testing, to celebrate the pie test or the
complete pie test course you're getting done.
The coupon code 2024 is open through January for 10% off.
So just wanted to mention that.
So now I'm ready for a joke.
All right.
This one has to do with managers and sprints and super agile stuff.
Okay.
It was from work chronicles or chronicles.com.
Put it in the backlog with dashes.
So there's a programmer, clearly a business.
Actually, it's a project manager, but whatever.
Like somebody on the tech team.
And here comes a person, very cheery.
Hey, I have a new feature idea.
And the person a little bit bugged, getting interrupted from work says, awesome.
Just put it in the backlog.
Person says, where's it?
Where's the backlog?
Holds up the trash can.
Oh, dear.
Put it in the backlog.
Just go back.
We're busy.
Yeah.
Anyway.
We actually, we've got a real backlog, but the things that are marked low priority, it's
never going to happen.
Just run a filter that just hides all the priority things.
Yeah.
We're done.
Backlogs all caught up.
No, I know there's that feature I put in there.
Oh, yeah.
It must be a little priority.
Got it.
Oh, it's prioritized.
We'll get to it.
Beautiful.
All right.
Well, fantastic to be back with you and everyone else, Brian.
Good to be back.
Yeah.
Bye, all.