Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 476, recorded April 6th, 2026.
So many sixes, Brian.
I'm Michael Kennedy.
And I'm Brian Okken.
And this episode is brought to you by us.
We have all sorts of awesome things to help you get better at Python, testing and so on.
Check the show notes.
Subscribe to the newsletter.
We've got a bunch of cool things we're sending out there.
And every week, one of them, every week is a nice, extra rich summary of what we talked about, what we're covering, but also additional places to find more materials.
So you can get a little bit of the background information.
Like we might talk about, oh, here's how you do this thing in CI.
But maybe the newsletter also includes details of getting started with CI and other things like that.
And that's all thanks to Brian.
So thank you for that.
With that, you know, let's migrate it over to Brian's topic.
What's up?
I am talking about Ty migration.
So Ty, T-Y, the Astral Project for type checking.
Have you used it?
I am using it actively.
Yes.
I love it.
Okay.
So it's the speed thing.
So Ty's all Rust.
So it's way faster than a lot of other stuff.
Firefly is Rust also, but Ty's still faster.
I think Firefly is Rust.
It is, I believe.
Yes.
Okay.
But it's not, Firefly is not noticeably laggy.
But mypy is.
And mypy is definitely something I use in CI.
But anyway, well, I'm bringing this up because there was a post by Sebastian Ramirez, and I just went away from it, that all of his Python projects like FastAPI, Typer, SQL Model, Async, or all of that stuff.
It's all just using, it's all using Ty now for the primary type checker.
And so I'm thinking, and I had tried on for a couple of projects, and it was a little bit pickier than I expected.
So I tried it again.
So I went ahead and migrated pytestCheck to use Ty, and I'm kind of doing a similar model, and it's going well.
So anyway, he migrated that stuff, and then Tim Hopper wrote a blog post called Migrating from mypy to Ty, Lessons from FastAPI.
And it's a pretty fun walkthrough of some of the things because it's really pretty easy to migrate.
So the idea around it, I'm going to skip down to the end because he's like, well, if you want to do this yourself, what should you do?
Add Ty alongside of mypy.
And that's what I'm doing with pytestCheck, doing both mypy and Ty.
Actually, I've got them as two different talks, runs, sections to run them separately.
But locally, I'm just running Ty because it's so fast.
It's like it runs and it's done, whereas mypy, I have to wait a few seconds.
A few seconds, not a big deal, but it makes it so that I don't run it as much.
Anyway, add Ty alongside mypy.
There's one setting that I turned on because of this article of errors on warning.
So there's some Ty warnings that show up and they don't stop a Sierra run, but I want it to.
I want to have it completely clean with no warnings.
So you can set error on warning is true.
If there's parts where you have to comment out, like you have to ignore certain lines for some reason, the annoying part right now is that you have, and I'll go back up to this discussion up here,
is that you have to do two.
So the ignore line for mypy is different than Ty in some of these.
So that is a bit annoying if you're supporting both.
But apparently it got better in Ty 0.0.25.
Oh, come on, guys.
You got to like, anyway.
Those zero-vers are just killing me.
That's a very, very, very zero-ver.
0.0 is the version.
But support's a better way to say ignore these sets of things.
Apparently that works.
So anyway, check out the model if you want to have ignores.
I don't actually have, I think I have a few ignores, but not too many.
And a lot of them are because I intentionally try to do something bad to simulate an error.
Okay.
So how it fits in the workflow also, it's really easy to run, all that stuff.
It's great.
Okay.
Let's get him back.
So you accept the double comments and then pick a smaller project.
And whereas like on the FastAPI world, SQL model is now completely Ty only and doesn't use mypy apparently.
So drop mypy when the noise exceeds the signal.
So, right.
So the SQL model had too many, like it wasn't worth having supporting both because of all the different ignores and all that stuff.
I'm currently, I've had so many people request mypy support for pytest check.
So I'm not planning on dropping it anytime soon.
And for a lot of packages, I believe that's probably going to be the case of people just supporting both for a long time.
And one of the really unfortunate things about how Python typing works, there's a lot of good things about it.
So don't call me a hater.
But one of the really unfortunate things is even amongst ty and Pyrefly, there are different conventions and warnings and things that count as errors and things that don't count as errors.
Things that are checked and things that are not checked.
And so if you have a project that needs to support two, both or more, you've got to put all of them in there.
You've got to deal with cases where your type checker says everything's fine, but someone else type checker doesn't think it's fine.
You're like, are you serious?
Like the most ridiculous version of this is for one of my templating packages.
I can't remember which one, like chameleon partials or flask chameleon.
One of those where it like lets you do something with the, or maybe Jinja partials.
I can't remember.
But somebody was doing something with flask.
And when you put the decorator onto a view that the web framework calls, it changed the signature in a very subtle way.
And the signature is extremely complicated at the definition level.
I mean, it's like multiple lines of what the warrant of the signature problem was, you know, not just like expected in, but it was really a lot of like stuff going on there.
And it said that that was wrong.
I'm like, who cares?
No one's ever calling it.
Like no one calls a view function.
It didn't, nobody gave it a definition that it's this big complicated thing, but somehow the framework, you know, like it was just, I think the something about the app.get decorator expressed a type and then it changed that type.
But who cares?
Cause it's still ran just fine.
So it was like, I had to go and spend hours reworking the signature of that thing to get it just right.
So, so Pyrite would stop giving me a warning where I never even use Pyrite.
I'm like, why am I spending my Saturday morning doing this?
That's dumb.
But people were using it.
They would just get like loads of error.
Like every viewpoint in their Flask function would have an error in Pyrite.
Right now I have stuff in my code where it's got ignore statements for Pyrefly.
But if I load it up in ty, ty gives me a warning that the ignore statement is unneeded.
I'm like, it's not unneeded for you, but it's unneeded for that.
Like, are you, anyway, this is why I say that.
Like, it's just, it's a, it's a struggle.
And if you create a library to your point, then you've got to put yourself in the situation where like, you don't have to work for a type checker that you choose.
You work for everyone's type, all the type checkers.
Cause whatever anyone may choose will become applied to your usage.
Right.
In their project, which is anyway.
Rant over.
Yeah.
Luckily I haven't had too many issues with, after, after supporting my Pi, that was the big one.
I think more people are using my Pi than anything else, but I think we'll see a shift.
One of the things that I did want to call out also related to this is ty, ty, whatever you call it.
Charlie says it's pronounced ty.
TY.
TY did catch one problem in pytest-check that I was like, oh, this, this, well, it's a hidden possible problem.
And I just, this is quick, but I have support for pytest versions and, but I have runtime behavior that changes based on version because of, because of when pytest added features.
so I was expecting, this version tuple to be integers and just comparing like, you know, is seven Oh three seven Oh, less than or equal seven Oh, sort of a thing.
But the version tuple can be a string and ty caught that.
And so I have, some code that I've converted to using, a thing called packaging.
It's a packaging project.
Packaging.version has a parse function and, and parse just creates an object that's comparable so that you can do, this whole version one equals less than or equal version two.
So, and you, yes, you can probably write this function yourself, but why bother?
It's right here.
It's supported.
use it.
So anyway, very nice.
Okay.
Next topic.
I want to talk about a ORM built in rust.
Very interesting.
So this is basically an instead of Django ORM, which I think is really interesting.
There's a lot of ORMs out there that are like, this is a great ORM.
You can use it for anything except for you can't use it for Django.
Sorry.
Bye now.
Why can't you use it for Django?
Because Django so deeply cares about the models using the models to drive other things.
The models generate forms.
The models generate the admin.
The, like the models and the way that ORM works in Django is kind of like what makes Django, Django.
Like if you don't care about any of that stuff.
Why are you using Django?
Pick a micro framework, you know, whatever.
Right.
The reason you choose Django is because it has all these Lego blocks that you can use.
Right.
Okay.
So this one called Oxide ORM, believe it is a, it's got to be written in Rust given that name.
But what it is, it is a type safe, identic centric async ORM with a high performance Rust core.
And it's inspired by Django.
It's not necessarily, it doesn't necessarily sell itself explicitly replacing Django, but I will tell you why I made this call back in a second.
So, Hey, this is a young project.
Just heads up.
So, you know, heads up.
This is a young project.
I bet it has a higher version than ty, but nonetheless, it's got basically the same syntax as Django, model.objects.filter, et cetera.
It has full Pydantic V2 validation.
So in this world, you create your models using Pydantic, right?
Which has all the Pydantic goodness.
We're going to come back to talking about this kind of stuff as well.
Okay.
But very cool to be using Pydantic for the data access classes.
It's also async first built on modern Python, asyncio, Rust performance, SQL generation and execution is native in Rust.
So like one of the things you got to do is, okay, you gave me a model called customers, which is a Pydantic class.
What does that mean in terms of a SQL query when you say dot city equal equal, whatever, right?
That kind of stuff.
Multi-database support, of course, transactions, migrations, Django style migrations and a migrate CLI.
So you can see it's like trying to be the ORM for Django without explicitly saying not quite.
If you look at performance, there's a couple of things.
Higher is better here.
Let's just take the Postgres.
With Oxide, it's 1,475 requests per ops per second versus Tortoise, which is 888.
Piccolo, 930.
Django, 730.
So just almost exactly 2x of Django and 4x of SQLAlchemy, 4x of SQL Model.
I mentioned, you know, tie back there.
And holy moly, PeeWee is at 80 versus 1,400.
So that's pretty wild.
And then obviously all the type checking, you know, they've got this query of like, hey, here's how you would do a really long, complicated query in both in Django and Oxide.
The only difference, literally the only difference in these, you know, probably a 90 line, 90 character 90 column rather, same thing, 90 column query on the ORM.
The only difference is the await keyword because it's async, which is pretty sweet.
So yeah, good stuff.
Now back to Django a little bit more.
It has Oxide Admin.
So Oxide Admin is auto-generated admin panel for Oxide ORM with zero boilerplate.
So it's got all the Django type of things here.
And what's interesting is it's for FastAPI, Litestar, SanicCore, and Falcon adapters.
Does it not have Django support?
It's just Django-like.
I think it might not actually even integrate with Django, but it gives you the Django style, right?
It gives you the admin, gives you the migrations.
It gives you the query syntax that's identical.
I bet you could use it with Django somehow.
Anyway, here it is.
That's pretty cool.
Yeah.
Yeah, yeah.
Pretty cool.
It's always on the lookout for these interesting data access libraries that are creative, bring something new without, you know, being too weird, I guess.
Yeah.
So anyway, Django oxide, or oxide ORM, not Django oxide.
Oxide ORM.
Check it out.
All righty.
I actually, I've been thinking about types.
So I'm going to go back to types.
We have this theme, but we're just going to talk about the same thing for whatever our theme is.
Yours is types.
Go.
Types today.
So this suggestion comes to us from Emma Typing.
So I think Emma cares about typing also.
Very cool.
She says a very cool project, which realizes something I've wanted for a long time, documentation for Python with type shed types.
So what are we talking about?
I did a comparison of side by side.
So if we take a look at like the function, the docs.python.org at the built-in functions, you get like ABS, like absolute for absolute.
And it takes a number.
But what type is number?
Well, this new project has, has the same, it's basically the Python docs, but with types.
So how, how that function signature would look with types.
And this is all from type shed.
So, the project, that we're shouting out to is, well, it's a, it's a GitHub.io thing, but, it's an open source called type shedding CPython docs, a tool for, to find
missing type shed stubs and generate type annotated CPython docs.
So it takes the CPython docs and annotates them with types.
It's pretty cool.
if you, if you're looking at some of the, some of the internal stuff, and it, it's all doing, it looks like it's using Pyrefly, to generate some of these things.
Maybe, I don't know, but.
Interesting.
Okay.
That's pretty, that's pretty much it.
just as, if you want to look at anything in the docs, but with types, there you go.
like what is a slice take?
Oh, slice takes, you know, well, it's going to be like.
It's an any, any, not too much.
Any, any.
that.
But there's somewhere probably, interval of or something.
Who knows?
Yeah.
So.
Pretty cool.
I like this idea.
That's great.
I think these, these kinds of things are powerful too, because especially if you're doing any sort of AI thing, you would say, you know, you ask, is it do something that's like, what are you doing?
You have no idea thing.
Read the docs or check this out or I'm going to, you know, and if it has type information that really gives it a lot more to work with.
Yeah.
And also because like, that, that the docs, the Python docs are really for us, but type shed is really not for us.
So the kind of the idea to combine the information in type shed and present it as the docs, it's pretty kind of, it's kind of a clever thing.
So.
Yeah.
It's very clever.
And also if you're doing something kind of like something built in, you can look at, you know, look at what the types are with that and try to match it.
Yeah.
Definitely.
All right.
Shall we keep with our theme or yeah, of, of theme swapping.
So yeah, like to just keeping the theme going.
So I want to talk about databases some more.
Okay.
And, and ORMs, but from a different perspective this time a little bit in the sense that I wrote an article, the article I want to talk about is raw plus DC database pattern, a retrospective.
This is, this is pretty interesting, but in order to talk about, let me just talk about the design pattern that I published real quick.
So people maybe didn't read that article or they didn't listen a couple episodes ago or something.
Right.
So my thesis is there's a couple of reasons why depending on maybe smaller ORM libraries, it's not that great of an idea necessarily.
One is if that thing goes unsupported, you've got a good chunk of your application and a foundational portion of it that is tied to this potentially unsupported thing.
So make that concrete Talk Python Training.
When I created it, it was based on Mongo engine and that was a up and coming super nice query syntax.
Also models exactly the Django ORM by the way, by oxide, like oxide ORM.
So a lot of the queries in there looked very much like they were Django, but they were object-based going to MongoDB.
Right.
So that's great.
But fast forward 10 years and that thing's had a couple of releases that like changed the read me in five years.
Like, and for reasons, maybe I'll get to later, like another episode is I wanted to switch this to async.
I wanted to switch Talk Python Training to async, but this older ORM library was not ever, ever going to move to adopt an async model.
Right.
Even if it doesn't throw away its synchronous model, like have an async option.
Like, no, I mean, if it's all that's happening is like a couple of read me's are getting updated.
There's no, there's no way they're rewriting the whole thing to be async.
You know what I mean?
Yeah.
And it's a, it's also probably a scratch your own itch sort of thing.
If they, if the current project does what they needed to do, why, why update it?
Yeah.
And they're not obligated to, but I'm also not obligated to keep using it.
Right.
Yeah.
So that was, that's number one is like, is there a more stable base and the stable basis, whatever the core database driver package is.
In this case, it's PyMongo, but you know, could be just the core one from the Postgres team talking to Postgres with Python.
Right.
Like that's what all these ORMs are based on often anyway.
I mean, oxide ORM is not quite, probably based on the Rust version that the Postgres team provides or whatever.
Right.
So something like that.
So that's one.
The other one, the raw part has to do with this theory that I have that talking to, when you're working with agentic AI, they know frameworks, but what they really know super well is the foundational stuff.
Like they probably know SQL model, but they really know SQL, you know?
Yeah.
They probably know Mongo engine a little bit, but they really know just queer, like raw MongoDB queries.
And so that's the idea is like, like, what if we just had a data access layer that was just raw queries and it returned some kind of rich classes like data classes.
Now, before people email me, cause I've talked about this on Reddit and like three fourths of the comments were, why aren't you using Pydantic?
You could use Pydantic here.
Do you know that you're using data classes when you could use Pydantic?
You have no type.
Like, yes, sure.
You want to call it raw plus Pydantic and use Pydantic instead is literally the same thing.
You're totally welcome to do that.
Right.
I just wanted something simple.
I found like I, my dream of Pydantic, like in Beanie and other, these ORMs or SQL model is you've got this ORM and it returns Pydantic models.
And maybe you've got FastAPI and you could just like take the thing straight from the database and send it out over the API.
And how amazing would that be?
I'd not almost never was able to take the database model and return it directly as an API response.
And so you're always like transforming them anyway.
And so I ended up showing like, I just don't need, I don't need a Pydantic all the way down.
Like Pydantic at the boundaries was good for me.
Okay.
So all that's so I can tell you about my retrospective.
So I wrote up this thing where I rewrote Talk Python training.
Now Python Bytes is already using this, so it already gets this benefit.
But I did this for Talk Python training, the courses.
I said, well, let me just put it into practice and see how it goes and if it's any better.
So I came with pictures, Brian, look at these pictures.
Mongo Engine, the raw plus DC pattern.
It's almost 2x more requests per second for the same hardware, the same everything else.
Just switching this out.
And the bonus is you get a much more stable library to program against.
And AI is really good.
If you say, hey, AI, hey, Claude, create me an update function to do this thing.
And it can do that better, right?
It has a more, much, much, much, much more training information to do that with.
And you get 2x performance.
And even when you're doing 2x the number of requests, you still get quite a bit faster response time.
That's pretty cool.
Yeah.
Pretty neat, right?
Yeah.
And you scroll down.
Another bonus is actually about 10% less memory usage as well.
That's good.
Because apparently the ORM and the classes that it uses and the tracking and whatever just hangs on to junk more.
I don't know.
I mean, I'm still using classes, right?
But for whatever reason, it's just quite a bit less memory usage.
So I think that's turning out to be a pretty promising way to go.
And yeah, expect more about this stuff later.
So I can't resist.
If you've already considered data classes, have you considered attrs instead?
Thank you.
I want something built in.
I want something with fewer dependencies.
Data classes are built in.
Pydantic and attrs are both separate packages, right?
Yeah.
The benefit for choosing attrs has to be big enough that it justifies taking on another dependency.
So I talked about data class of wizards.
So for this kind of stuff, I'm like, if I need to read and parse and validate data, I'm doing data class of wizards along with data classes.
But people are certainly welcome to choose attrs.
They're welcome to choose Pydantic.
They all work good in this model.
Well, and especially to give other people their due for projects that already have Pydantic for other reasons, that makes sense also.
Yeah, yeah.
Absolutely.
All right.
How extra are you feeling?
I've got one extra.
All right.
Tell us.
Just this weekend, I released a 0.5 release of the, I know I haven't talked about this much lately, the Lean TDD book that I was working over the fall and over, I guess, over Christmas.
But it's, I went through, I'm preparing to read it.
So I want to release it as an audio book.
And so in preparing for that, I have almost completely rewritten it.
It's restructured, and I think it's a lot nicer.
Now, that said, I'm still working on it.
So I think it's really solid now.
I think it's a good resource to go ahead and run with.
But I'm doing a third pass through right now with some comments from some trusted readers.
And, yeah, anyway, there'll be some expansion, but not, I don't think, a huge direction shift in the future.
Because I really want to get this done and wrapped up.
But anyway, I'm pretty happy with this state right now, Lean TDD.
And, yeah, if you're interested, let me know.
So that's it.
Awesome.
Congrats.
Getting there, huh?
Yeah.
I want to get this done.
Yeah, indeed.
All right.
Let's see if I can not be jumped on by the un-auto-hiding of Vivaldi.
So I want to talk about HiTest Just from Michael Booth.
This is a really quick extra thing I want to give a shout-out to.
Cool.
And Just, you covered this a while ago.
It's just a command runner, one of those sort of circular references type of thing.
It's kind of like Make, kind of how I see it.
You know, you've got some files.
It tells you how to build things or test things or whatever, right?
Like, was syntax inspired by Make?
There you go.
So Make is kind of long and gnarly and Just is more YAML-ish and cleaner, I think.
I don't know.
Anyway, it's a cool way to sort of structure automation for your projects, right?
So a shout-out is...
It's just lovely to work with if you haven't tried it yet.
Yeah, I like it.
So Michael Booth created a pytest-Just plugin.
And it's a plugin that adds session-scoped Just fixtures to pytest so that you can test a Just file contracts directly in your test suite.
So it lets you test, like, really nice things like just assert there exists a CI, a CI section.
And that CI has a test.
And it depends on test following the transitive dependencies of it and so on.
So anyway, I thought that was kind of cool.
So if you do stuff with Just and pytest, check out pytest-Just.
Cool.
All right, this next one needs a disclaimer before I go into it.
I was not going to put...
I was not going to talk about this, Brian, because I don't want to...
You know, it's just not like TMZ bytes.
Python bytes.
There's a lot of drama here.
But I think it's pervasive enough that I think we should put it on people's radar.
So I'm not here...
What I'm about to describe, I'm not here to take sides in.
I'm not here to, like, bad light on anybody.
But there's a mad level of turmoil around the encode projects.
HTTPX, Django REST Framework, UVicorn, Starlette, which is the foundation of FastAPI, MKDoc.
I mean, that is a mega set of dependencies that people depend upon.
So I'm just going to link to four articles, five articles.
And you all can read them and think about those however you want.
But if you're using some of those libraries, you should probably have a look at this.
So 320 upvotes on Reddit says, anyone know what's going on with HTTPX?
Maintainer of HTTPX closed off access to issues and discussions last week.
Hasn't had a release in a year.
I wonder what's going on.
Michelle says, I forked HTTPX to HTTPXXY.
Talks about why.
Transfer of UVicorn and Starlette causes a great bunch of stirs.
There's an article called The Slow Collapse of MKDocs.
Yeah.
And that ties into Zensical, right?
Yeah, exactly.
And so basically this documents over time all the stuff that is going on that has led to Martin and his co-founder creating Zensical, which was material for MKDocs.
But they found like, yeah, basically that this was becoming something they couldn't continue to work with.
So they had to do something else.
And Django REST framework is there's an inspiration to somebody's proposed that it gets taken into Django Commons.
And Django Commons is this project to basically find and maintain packages that are important to Django that are kind of going unmaintained in a sense.
And so in this conversation I'm linking to, there's a bunch of people like, this is kind of a good idea.
But the people who are actually maintaining like, but I'm not really sure I'm going to come over and become the main maintainer.
So it's sort of stalled out.
Anyway, again, not trying to throw shade or call anyone out, but there's enough going on there with enough important projects that it's worth being at least awareness.
Yeah.
Sad.
Okay.
Not sad.
Something awesome.
This is very awesome.
This one I like quite a bit is announcing course completion certificates over at Talk Python.
So I don't work in a big company, so that's not super relevant to me.
So I have not really maybe given it as much love and attention as people want me to.
So now I have.
So what I've done is I have a nice dashboard that I released maybe a month ago and talked about that, I think, that shows you what courses you're working on, how far you are through them, which ones you recently have most recently taken at Talk Python and so on.
But also, and if you have a bundle of like 50 courses, which a lot of people do, then it's like, well, here's a huge long list.
Which one was I doing again?
You know, it really helps like solve that problem.
But now for the completed courses, it has a certificate section and you click that, it gives you a standard old PDF certificate that you can use if you have like continuing education
requirements or something like that, where you need to submit an official certificate to your company or whatever.
So that's kind of fun.
But more importantly, more fun, I think, is there's an option to say, publish this as an official certificate on LinkedIn to my profile.
So like one button click from Talk Python in your account, boom, takes you over, populates and fills an official certificate, even with a show your credential, which takes you back to an official.
Yes, this credential is valid, verified for you page on LinkedIn.
So that's pretty cool.
Yeah.
So if you take a bunch of courses, you know, and you want to have those there.
So people go, oh yeah, they did actually take that flask class.
That's right.
They know a little bit more than, you know, maybe just flask is like a skill or something.
So.
Can I print it out and like pin it to my cubicle wall?
You know what?
You could print it out and get that on like a matte finish.
Yes.
Yeah.
You can't even get the PDF.
You could print it out.
It's actually, it's actually like letter, US letter size.
That's awesome.
If it prints, like I had to get the DPIs of the image exactly right to fit for that.
So anyway, that's fun.
I thought not everyone's going to care about that, but people do.
I think it's kind of neat to do.
That's, that's pretty cool.
Yeah.
I've had a couple of those requests and I can't remember if I turned them on or not.
I think Podia, the platform I use, I had them.
So it just.
Nice.
I had a joke also, but I think let's save mine for next week and let's just use yours.
Okay.
Here's the funny things.
I don't even remember what the joke is, but I'm going to look and then we're going to find out together.
Oh yeah.
Here we go.
It's about AI.
So this, I entitled this Noya Rich, the new rich in the eighties.
Think Don Johnson.
Think standing by a big mansion in Florida and Miami, Ferrari Testarossa in the back.
Like this is rich in the eighties.
Rich in 2026 in modal change the button color to green.
Opus six, four, six.
Yeah.
It's which model are you using there?
Yeah.
And just like do like the completely most simple, a find and replaced or just a find and a type, the letter, the word green would take care of it.
But no Opus four point six extra effort mode.
Change the button color to green.
That's funny.
Yeah.
It doesn't have a whole bunch of great comments, but it's pretty funny.
So that's my joke.
That is pretty funny.
We, so April, we had like a changeover of our licensing stuff, March to April.
And on March 31st, a lot of people were running, like got their tokens removed or something.
And it's one day.
But there was so many people complaining of like, I'm reported as out of tokens.
How do I work?
Hopefully you can still work without tokens.
I know.
It's so bad.
It is so bad.
It's so bad.
It's like pre-smartphone, post-smartphone, you know?
Well, I was just thinking that the other day.
I was driving somewhere and I'm like, how?
I'm in Portland and I've had GPS ever since I've lived in Portland.
There's a lot of places I don't think I could find without a GPS.
But you've been there before.
Well, yeah.
I've lived here for 15 years now and I, but still, I can't, I don't carry a plastic map or anything like that with me.
So.
Yeah.
I don't know if I even have an Atlas in the car anymore.
Like if for some reason my device broke and I was on a trip, I might just be there.
I'm going to live here now.
I guess we live here now.
Yeah.
This is funny.
This is great.
So.
Yeah.
Thank you, Brian, as always.
Thanks everyone for listening and catch you all next week, everyone.