Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 474, recorded March 23rd, 2026. I'm Michael Kennedy.
And I'm Brian Okken.
This episode is brought to you by us, all the wide array of things that we're doing, courses, books, and so on.
Check them out. We have a lot of stuff on testing, a lot of stuff on Python.
Can you imagine, Brian? That's what we're working on.
I'm actually working on a brand new course. I'm super excited about it.
It's going to be a little bit different than the ones I've done before.
So it's going to be fun. Look for that in like two weeks.
Now, also look for, if you're wise, if you've done the right thing, look for a very cool email in your inbox after the show that talks about what we covered.
Extra info to make it more useful.
Background info if you don't know something about a topic we talked about and so on.
So that is subscribe to the newsletter, pythonbytes.fm.
Click newsletter. Put in your info and then you will be subscribed to the newsletter.
And we're gentle with it. We don't give it away to third parties or anything terrible like that.
We just send you stuff about the show and other things going on with us.
Wait, if it's them and me and you, is that three parties?
No, we're both in the same party.
Yeah, we're in the same party.
It's a star party. I would say it's a star party. Don't you think?
Yeah. So I want to kick this off with a little talk about Starlet.
Starlette is like 12,000 stars.
But also it is, if you're not, if you don't remember, you've heard this before, but you can't remember.
It's because this is what FastAPI is built on top of.
But the exciting news is that Starlette is 1.0.
It's no longer zero ver.
So congratulations, Starlet.
I was looking at the release notes.
The main thing is not necessarily, actually, there's a lot in the, there's not a lot in the actual 1.0.0, but the release candidate has a lot of information.
And as a summary, there is a, there's a blog post, a blog post that talks about really everything that's in here.
And mostly don't really, if you've been keeping up with Starlette releases, there's probably okay, but you should test anyway.
However, it's mostly a stability and versioning milestone.
We are told the changes were limited to removing old deprecated code that had been on the way out for years, along with a few bug fixes.
But, so it's not, not intent, not necessary.
The intent isn't a interface break.
However, if you were relying on deprecated features, you, you, you might break you.
So definitely test.
The, one of the things I, a couple of things I wanted to bring up with this though, is, is, is, it's pretty cool.
So if we, you know, Starlet's awesome.
And if you're unfamiliar with what it is, you can do, it is, it's a, like a whiskey.
It's the little ASCII framework.
So it's like whiskey, but asynchronous.
And it's awesome.
But there's a, there's been some cool changes.
One of the things I like at the, before we get off the release notes is at the end, what's next.
It says, oh, and Sebastian, Starlette is now 1.0.
So now FastAPI 1.0.
So FastAPI is still 0ver as well.
And, which also we've razzed him before also.
I think it's high time that we get a 1.0 release of FastAPI maybe.
I did want to bring up, I actually learned about this by looking at Simon Wilson's blog.
And he is, he noted that also that Starlette 1.0 is out.
And one of the, and his, his article is really about experimenting with Claude's skills because this is a new release.
And that's one of the ideas is the model that Claude was built on probably doesn't have it, right?
Because it's a new release.
So how, how to deal with that.
So I'm not going to get into that article too much.
What I wanted to look at was this example, which I thought was cool because one of the, one of the, it's not really a chain recent, super recent change, but one of the newer
ways to do async context, there's an async context manager.
So if you want to handle startup code and teardown code, there used to be on startup and on shutdown parameters.
But now one of the, one of the better ways to do it is to use this lifespan model, which is an, is, it's kind of a generator and you can say you've got startup code and then tear down code after a yield.
And I just thought that was, was cool because it's, it very reminiscent of, high test fixtures that do the setup and tear down after a yield.
So interesting, interesting that that model gets around.
So, but yeah, the yield is, is quite interesting.
It's a bit mind bending, but it works well.
This is awesome.
You know, Starlet's one of the fastest web frameworks out there for Python and it definitely is battle tested being a foundation of FastAPI.
So good, good deal.
Sebastian, has it already shipped?
Where is 1.0?
What's going on?
Yeah.
That's cool.
very nice one.
I want to switch things over and talk about the news du jour astral to join open AI.
I don't know if you all have heard this, but big news.
It's certainly something that has set the internet, the Python internet on fire.
First of all, I would like to take a moment.
And, and well, first of all, thank you, John Hagen for sending this in.
It was news to me when he sent it in about 10 minutes later, everything exploded.
And, obviously it's, it's come to us from many directions, but thanks, John.
And I want to take a minute and say, congratulations, Charlie.
Congratulations, astral team.
They, they really stepped up and built something incredible for Python tooling.
And they were working for different ways to make this a business.
This is certainly one of the ways to make a successful business is just get lots of that sweet, sweet AI money.
Now with that out of the way, like, what does this mean for the people left without sweet, sweet AI money pools of AI money to swimming?
So there's, there's, we don't know.
There's a couple of interesting, a couple of interesting things.
I'm going to link to the blog posts from Charlie.
I think there's basically, it says the team is moving to open AI.
The projects are moving to open AI.
So why let's start with why, why does open AI want them?
I don't know exactly.
I think nobody has said so obviously rough and uv are super relevant for making agentic coding go faster.
And to be clear, they're joining the codex team.
So the agentic coding tools team of open AI, right?
So rough and uv are there as really awesome tools for codex to install things, to validate.
I think actually maybe the most important could be ty.
So ty, we've talked about ty before, which is their language server plus type checker.
And being a language server, you could point it at an entire project and say, I want to understand this.
Like one of the things that drives me crazy, I love cloud code, but one of the things that drives me crazy is it runs in sort of this non IDE, non editor way.
And it does not understand the code base really as a whole.
It doesn't have a mechanism for saying like, tell me, just, just tell me about where is this function used?
It's just like grepping and searching constantly.
Like, why do you have to grep?
Can't you just use an abstract to text tree and just know the answer instantly?
So if codex deeply took ty in, it could know the answer instantly.
Right.
You know what I mean?
In like, I truly understand the project.
It's not a file of loose text files that I'm surprisingly good at just navigating them in that way.
This is an interesting take.
Cause I was thinking recently using cursor that one of the issues with cursor, I love cursor also, but one of the issues is they can't use Microsoft's language server.
And, and you feel that because the Microsoft's language server is, is, is tighter than the one that cursor uses.
Yeah, exactly.
It got kicked back a few years and work away back.
And tie it.
And ty has the potential to, to be as good or better than the Microsoft one.
So interesting.
I think it's better.
Yeah.
I think it's better.
I would say Powerfly and ty are, are sort of cutting edge right now.
And certainly I'm, I'm using ty and, and my VS Code like things.
Okay.
So those are all good reasons why Astral might join open A, why the codex team might want Astral except Brian, I don't know if you've gone and looked at those projects, but the source code has been leaked on the internet all over the place.
Like they're just open source.
They're on GitHub.
So there's nothing preventing codex from just going, we're going all in on ty.
We're going to contribute some stuff back to ty.
We're going to create a fork and just keep that hanging around just in case and really make that our foundation.
And they could have done that with no work, with no people, right?
For no money, no acquisitions, no legal work.
So the question is what else is going on here, right?
Well, you got a handful of awesome engineers you just collected.
Exactly.
So is this an acquiring for technology or is this acquiring for AccuHire?
And is it like, I would like to have the Astral team actually doing that work to implement ty into codex or whatever.
This is my speculation, right?
Or whatever it is that they're doing there, right?
So I don't exactly know where it's going to go.
I do think that this probably means the death of pyx.
So pyx, I had Charlie on the show and...
I kind of forgot about it, actually.
Yeah.
PYX, it's the safe enterprise packaging solution that front ends PyPI.
It's not a separate package warehouse or place, right?
It's a front end to PyPI, right?
So if you upload to PyPI, it shows up here in this thing, but with lots more management and you can put your private packages, right?
That kind of thing.
That was going to be the way that Astral was looking to make money until pools of AI money showed up.
So people have thoughts here, very relevant.
Simon Wilson has been writing so much about all of this AI stuff in the world.
So he obviously, as a Python expert, has deep thoughts on this.
And by the way, that comment I made, Simon points out, if you both look at the Astral announcement and the OpenAI announcement, they talk about Ruff, uv, ty.
Nobody mentions pyx at all.
In other words, those letters do not appear in the announcements, whereas the other tools do.
So that's notable, right?
So you can check out Simon Wilson's thoughts on this as well.
He's got a pretty balanced view of it.
It's not completely like, oh, this is going to be amazing.
But he has a lot of different thoughts on it.
If you look at discuss.python.org, the thoughts are, well, the thoughts are strong.
They're not necessarily, I don't know, it's positive.
Bright Cannon has a lot of comments here, a lot of work on how he's doing stuff to sort of take some of these ideas from Astral and make them more part of the just core Python, which I think is great.
For example, what happens?
One of the biggest questions I had when I saw that was, oh, what happens to Python build standalone?
So there's the, oh, we can always fork it.
Take, right?
Which is true.
But when there's infrastructure and build tools and stuff happening on the backend.
I didn't think about that.
Yeah.
Then I forked it and it works fine up to Python 3.14 and it never works again.
You know what I mean?
And it didn't take the security patches because the Python build standalone is like not quite regular Python.
They have to do some tweaks to make it work weirdly.
So there's like in this whole discuss thread, there's like, could we just have Python build standalone kind of be there's like regular Python?
Like why, why do we have to have this like more portable version that works kind of better be maintained and patched by other people?
Right.
So Brett's actually talks a lot about that and there's some interesting things here.
There are not as many incredibly positive bits of feedback here.
There's a few, right?
Like Astral have earned a lot of trust.
As long as OpenAI doesn't insist on integrating their equivalent co-pilot into it, we'll probably be fine.
It's probably even good news.
So there's that.
Simon points out that like technically codecs could take uv away from the other coding agents in a way and make them like work with less good tools.
So that could be like a bad lever.
Mark says, hey, let's not jump to conclusions.
Yeah.
I'll tell you what the Twitter, the X thread is more serious.
But there's a pretty deep conversation here on discuss.python.org.
It also was covered on Ars Technica.
You go into the comments here.
I don't know how many comments there are.
Do I need to refresh it?
It's only 48, but this is probably the most concerned one.
Like, oh joy, I'm boarding the Titanic, dot, dot, dot.
Yeah.
Talk Python did get a shout out for the pyx angle, which is fun.
But yeah, I don't know.
I'm going to go ahead, Brian.
I want to be positive, but I got to say my first reaction was nuts.
This is not good.
But so I don't know.
I hope it can be good, but I'm still holding my breath as to whether Microsoft buying GitHub was a good idea.
You know what?
I hear you on the GitHub thing, but they were like on the verge of going out of business, which I don't think people realized at that time.
But it was the finances were bad.
And it was like they need saving.
So it wasn't like, well, either they just keep on their merry way doing their own good thing or Microsoft gets them.
It was like, or they kind of, you know what I mean?
Like it was, that was the, so in a sense, it's GitHub is still going pretty strong.
So it's better than it not being there, but I don't know.
But I agree with you.
Okay.
Back to the topic.
So with this, I trust Charlie and the Astral team.
I think their heart is in the right place.
And to be clear, it says they're still working on the three tools that were not pyx.
That said, once you're inside a large organization that has its own motivations and its own goals, who knows what happens?
It could be totally open.
One good outcome could be that it's a shock to the system and say the core development team goes, you know what?
We just need to like take Python build standalone inside of Python.
Like, why is this an external thing?
Why was a random dude maintaining it before Astral took it over?
You know, that was a lot of work.
We should, this is what we do.
So it could be, there's a lot of things that made.
That would totally make sense to be under the PSF umbrella.
Yeah.
Like, why do we have to keep patching every release of Python to make Python build standalone work?
Can we just upstream those fixes and just make that Python?
Yes.
That would be a good outcome.
Me as a bystander saying it makes sense, but I'm, you know, I don't know what's involved with that.
Yeah.
100%.
But Brett was sort of saying some things along those lines.
if you know, pip could easily adopt a lot of the things that uv did that make uv special.
I don't know why they didn't.
I mean, you look at, you look at the comments, it's like, well, we're too busy.
Like, this is like a volunteer thing for Pip.
And the reason, Paul, the guy who maintains pip is actually like, they've in a congratulatory way sort of said, look what Astral has shown as possible.
If you actually fund work on an open source problem.
Right.
But they didn't, it wasn't funded on Pip.
And so pip hasn't had those changes, but you could retrofit a lot of the things that make uv fast.
Cause it's not all just fast because of rust, although it is rust.
It's a lot of it's fast because of new algorithms and trade-offs and things like that.
Right.
So those could easily be written back.
Like there's also deprecating old features that like there's stuff that pip does that uv doesn't.
Yeah.
I just say, Hey, look, you pin pip to what it is now.
And we're going to get a new, better Pip.
Yeah.
If you need old Pip, use old Pip, like pip dash old.
I don't know, whatever.
So that, I mean, all those are positive influences and on the most possible positive thing, it's just rough uv and ty just keep on trucking.
Yeah.
Right.
So like, for example, the other thing I said is like, Hey, that ty.
And what did I say?
A project from meta, right?
It wasn't a other open source project that was a competitor to ty.
It was a sort of a similar type of company somewhat.
Henry brings up a great point comparing pip and uv.
UV has paid developers, pip does not.
Yes, absolutely.
A hundred percent Henry.
And Henry had a bunch of great comments and thoughts in that discuss thread as well.
Yeah.
I think we're all on the same boat of like, I get that they all want some payday, but also I hope it doesn't go down in flames.
Look, and I just want to put this out here.
I do.
I hope nobody has a bunch of negative hate that they're throwing out there for Charlie and team.
They've given us something and they haven't taken hardly anything from any of us.
And what they've shown is really awesome.
And we've all enjoyed the tools.
And even if they were to go away, there's a lot to carry forward from what they've done.
So I have no idea how much money they got, but it's probably life-changing amounts of money to some degree.
And if you've got just an open source project that you thought you could make install Python packages better, and then you've got life-changing amount of money, you should take it.
Unless you're already rich.
Really rich.
Well, there's also a couple of other aspects.
There's investors already in Astral.
And they have a non-zero say in what happens.
And then there's also the...
There have been comments of, well, it's open source, so you can just fork it.
That's not trivial to fork a large project.
Yeah.
I think if there were not infrastructure behind it, you actually could fork it pretty well and be okay.
There's something like 47 non-Astral employee contributors who have done five or more contributions to uv.
Yeah.
I mean, it's definitely doable.
It's just to fork it and get it to work once is one thing.
And then maintaining it for a long time is a completely different story.
Yeah.
And I mean, no new features.
It just keeps doing what it does now, which would still be awesome.
But when you're talking like Python built standalone and every new release of Python results and being patched and that is a whole different level of stuff there.
All right.
Enough talking about Astral.
You want to talk about Astral and stuff?
Yeah.
Let's stop talking about Astral and talk about uv.
Actually.
It's funny, but I am not kidding.
So uv has a new release.
And there's a new feature that I think is interesting.
That's kind of a secret preview feature.
And that's uv audit.
So that's what I want to talk about.
And in the release on the 19th, we got a 0.10.12.
We got uv audit is now as part of the CLI help.
And this was submitted by Owen Lamont.
So thanks for noticing this, Owen.
And I'm pretty curious about.
So I tried it out.
And so you can do uv self-update and you can get it.
And now you can use uv audit.
But it's interesting.
And there's also a link to the roadmap.
So it looks like almost everything's done.
There's some integrated tests that need to be done and whatever.
So it looks like they're heading forward to try to have this in place.
And it's pretty cool.
So uv audit is a dependency checker really on your project.
And I was a little bit, when I tried to run it, I didn't quite understand what happened.
It found some security vulnerabilities in one of my projects.
But it wasn't something I recognized.
And so I looked at it.
It was a dependency of a dependency of my test environment.
And what was even more confusing to me was that project, I looked at like a pip dep tree.
And I didn't have that version.
So what am I seeing?
Why is there vulnerability there?
One of the cool things of how this works is that in some part of the process, it creates a uv lock file.
So it can have in a uv lock file, which I kind of forgot about, it's not just all of the versions for your project pinned.
It's also on all operating systems that you support and all Python versions.
So that's a broad range of dependencies and versions.
And what happened was my project supports 3.9 still, or it did.
Wait, yeah, 3.10 is the lowest that I was supporting.
And even though I was running 3.14, in 3.10, one of the virtual env on 3.10, so it was talks, virtual env, and then file lock, I think, or something.
In version 3.10, there's a file lock vulnerability that got fixed later.
And they just went up new versions.
So it's kind of a neat idea.
I really like this idea, but it's a little bit hard to interpret, to go, oh, you have to look at all of the Python versions and all the operating systems you support.
Which, if you're doing a Python project that's usable, that's how it would work.
Anyway, I'm excited to have this get in place.
And I think it's kind of a neat thing to easily, if we're using uv tools already, to say uv audit for a PyProject Toml-based project.
And make sure you have not any vulnerabilities on any of the Python versions that you're supporting.
So that's cool.
Yeah.
When Owen said this, I thought, oh, this is awesome.
Because I've been using pip audit for both my local dev, but also for our Docker deploys.
So one of the Docker build steps is to do a pip audit against everything that had been installed.
And I set it up so that my pip audit, I can use uv to pip compile the requirements file.
And then use Docker to run pip audit so that if it has to install stuff and there is a vulnerability, it doesn't get installed.
I don't know, like crypto miners or whatever on my computer.
It installs it into this ephemeral Docker container, right?
Which is sweet, but it's kind of slowish.
It adds like 10 seconds to the build time of what otherwise was seconds.
A couple of seconds.
Doubled the Docker build time, at least, I would say.
So does pip audit must do something on the installed container?
Packages or?
Yeah, exactly.
So what you do is you install it, then it looks at the virtual environment.
So I have a Docker container I built, which is like the command I run.
And so what it does is it has pip audit already installed.
It maps in the requirements file.
It pip, uv pip installs them quickly.
And then it pip audits against them.
You know what I mean?
Yeah.
And so I'm hoping that this would be great.
And if you go to the bottom at the coming soon roadmap deal.
Oh, yeah.
Yeah.
You'll see at the, one of the unfinished things is support locked hashed requirements.txt files.
Yeah.
Which is the way I've been doing it.
I still, I'm just not a huge fan of the project management, like uv in it, add, so on.
Yeah.
For non-packages.
I like it for packages where it manages the piproject.tml.
And there's like all that.
But if I just have an app, I'd rather just have a requirements file.
So I pip, uv pip compile that thing.
But I can't uv audit it.
I have to pip audit.
So anyway.
I'm actually thinking about, because of, because of this and because of other, because uv sync is awesome, I'm thinking about projects that just are normal, like for my own, for work,
for requirements.txt-based projects, switching to PyProjectHمل so that I can get this.
But if they, if it supported this also, that'd be cool.
Yeah, I, it's, how much work can it be to translate the format of a requirements.txt file to a workable format of a uv lock file?
It's probably an hour of cloud code, I bet you.
Anyway.
Oh, wait a minute.
Use converter to a PyProjectHمل and then write it.
Yeah.
So.
Yeah, exactly.
Exactly.
Okay.
So that looks really cool.
I would actually like to switch over and talk about something that I thought was pretty interesting.
And this is an article I wrote.
It's not so much about the article itself.
It's about what the article is covering thing.
Go away.
Here we go.
So this is the articles entitled fire and forget or never with Python's asyncio.
And so here's the deal.
This is, there's a couple of tasks on our web apps that have long running things.
So let me just give you one example.
The one example is, and there's different ways to do this.
One example is like, maybe I want to just send an email.
Now send an email usually is quick, but sometimes it's really slow.
And maybe somebody signs up for a course and I want to send them an email, but I want to be able to quickly just get right back to them.
Right.
Say, Hey, you're in.
So you could just say, start the send email async function and let it go.
What are you going to do if it can't be sent?
Like, I don't know.
Like, you know, you're not usually told it goes out and eventually it comes back five minutes later.
This email address was not found at this server or whatever.
Right.
It's not like you can wait for the call to say, it's like the wait is for the call, the email to start sending, not for the success of the email delivery.
Right.
So why wait?
So you just fire it off.
Like, okay, that task goes.
And then we tell them, Hey, welcome to your account or whatever.
Right.
Something along those lines.
Another one is I have all the data, all the transcripts for the various podcasts stored in the database.
In certain formats, really nice to get the, get them in and out.
And, and the transcript generation stuff is always, it's always fraught, like with acronyms and stuff, right?
Like PI PI without some work, it's getting better and better, but without some work, it'll come back as like PI, the food, the letter P or something, or maybe it's the number PI or like it's whatever it is.
It's not capital P, lowercase Y, capital P, capital I.
Right.
And so there's like this automation that I run that fixes it really bad as guest names.
It can wreck guest names.
And sometimes it's no big deal, but sometimes it's bad enough.
You're like, Oh, that's kind of offensive to the guests.
Let's see if we can not do that to them, you know?
And so I have this like post-processing that goes on with literally hundreds of changes and not just one word, but if you see these three words together, that actually means something
separate than if you heard them individually, like talk Python slash whatever, like that's supposed to actually be a URL.
So fix it or Python byte slash whatever.
And so there's this process that runs and fixes them.
But as I discover new problems, I go back and retroactively fix the last 10 years.
And that process takes forever in terms of web request time.
Right.
So I'll say there's an admin button.
I can go push and it'll go pull every transcript from the database, search through it for hundreds of phrases, each transcript for hours of transcripts, change them, put them back in the database.
So that's like 20, 30 seconds if it fans out of a cross-processes.
So that kind of stuff, like when I push the button, I don't really necessarily want to just wait.
I want to just have it go awesome.
We're working.
And we have a little JavaScript that'll tell you it's progress, but we're not going to await it.
Right.
So that's a long, long way to set up this.
And the reason I went into sort of that extra background is people, a couple, when I posted this, a couple people said, well, you should never do this.
It's an anti-pattern.
I'm like, you shouldn't do it most of the time.
But the alternative is what?
Set up an entire separate Redis server with a messaging queue.
Like that's a lot of overhead for just like, I just like the little process in the background to run and correct the transcripts, you know?
Anyway.
So here's the news.
Here's the story.
Is that a lot of times you would write simple code like this.
You would say, I'm going to do a little bit of work and it's maybe async or whatever.
And then you can't just call async functions.
You have to start them.
Right.
So you have to say asyncio create task, or you have to await it.
Because if you don't create a task or await it, it just doesn't run.
It's an unrun async coroutine.
Right.
So you got to await it.
And up to Python 3.11, this code was fine.
You would just say, okay, now it's on the background queue and it's going to do its async await run just as if you had awaited it, but you get to carry on and like, welcome the user or whatever you're doing.
Well, then this has been this way since 3.6, maybe 3.5.
Right.
So that's a lot.
It's like seven years, but now Python 3.12 onward, you can't do this anymore.
If you do this, that task that was just started, you say asyncio create task is eligible for garbage collection in the next line of code.
And it might not even start.
I wanted to put, I wanted to put that out there for people.
Like, you know, if you have this type of code, you, you had better look at it.
You would better make a change because for whatever reason, the async event loop now holds weak references to the tasks that it runs.
And that doesn't just apply to this pattern.
Anything that somehow put something into that task, that, that work queue, the loop needs to keep track of it explicitly or else it's potentially gets deleted out of memory.
Right.
So if you look at the documentation or what is it?
Create, create task in the docs, it says it's going to wrap a coroutine into a task and schedule its execution and return the task object.
However, in Python 3.12 onward, it's important that you save a reference to the result to avoid the task disappearing mid execution.
That's new.
So anyway, so what is the fix?
You create this weird set that holds all running tasks that you're not tracking.
You add it to that task, that, that set, then you kick it off as a, or you kick it off as background work and you add the task there.
And then you set up a callback that when the task is done, it takes it out of the set.
So I don't know.
Anyway, that could certainly be catching some people out in like super hard to debug race conditions.
So I wanted to, I wanted to bring that up and then I wrote up a way to do it.
So that's that fire and forget.
Maybe you might just forget what else we got.
Extras.
Yeah.
I mean, what's interesting is about that is it actually requires you understand memory management a lot better than we normally do in Python land.
Normally we just kind of ignore it.
Okay.
So your solution, does it, does it still, does the task still stick around then?
Or does this?
Yes.
Okay.
So it's, I basically, I just took my example and just stole the, what, what they suggested straight out of the docs.
You create a global set, you run the task, you put it in the set, and then you wire up the tasks when I'm done, call the discard myself button.
Oh, so the garbage collector doesn't grab it.
Okay.
Yeah.
You just need to upgrade your weak reference to a stronger.
Okay.
That works.
Cool.
Yeah, it works.
It's, but it's not obvious.
It's definitely not like, oh yeah, I know I had to do that.
All right.
Extras.
What do we got?
Extras.
I just got a couple.
Let's see.
go over here.
just a fun article.
I didn't want to talk about it too much, but, I found it interesting.
called, nobody gets permit.
Nobody gets promoted for simplicity.
and this is a blog by terrible.
It's a terrible software blog.
That's an awesome name for a blog.
so, it, there's a quote from Ed, from Dykstra.
Simplicity is a great virtue, but it requires hard work to achieve and education to appreciate.
and to make what matters worse, complexity sales better.
And, it's, it's just an interesting observation and I've observed it too.
People, people, and it's unfortunate that people with the complicated, it's like the guy that, that stayed, late nights and weekends to fix bugs, might get a, you know, free
pizza or something like that or a promotion, but it was their bugs that they were fixing.
And the person that just didn't write the bugs in the first place won't get those.
Anyway, just that person is not even that much of a hard worker.
Look, they went home on time.
I suck.
I bring this up also because, people using your, your, a lot of people are now in a management role.
If, even if they don't realize it, if they're letting AI generate a bunch of code for them, simplicity still matters.
don't, don't reward your, agent just because it gave you volumes of code.
It might be a simple solution.
It might be easier.
Anyway, set that aside.
It's just interesting read.
I've been working on over the weekend, catching up on, pytest check.
I brought this up, a while ago, a couple weeks ago as well, that I'm catching up on all the things because now we're at, let's see, zero issues, zero pull requests.
That's awesome.
I mean, it's a small project.
So the last one I just, cleaned up though has been, was, was a feature request from three years ago.
So I'm, I'm glad that I'm, I finally get it in place.
And so the thing is I've got a bunch of these helper functions like, like equal and not equal and stuff like that.
and, the addition is that even if a test is not marked as X fail, you can, mark an individual check as X failed now.
so, so that individual checks, some checks might be X fail, some checks might be not, and you can also still use an assert can still cause the test to fail.
So yeah, I like it.
That's cool.
very nice.
Yeah.
That's my extra.
All right.
I got a few.
I'll go quick though.
So I ran across this project called turbo API as a riff on FastAPI.
We started with starlet and FastAPI and here we are in extras with a bit more.
So there's a couple of interesting things from this.
This person said, what if all of the parts of code that actually were not the Python that you write, what if that was all rust or actually not rust zig, but it doesn't really matter.
Like you dress C++ zig, whatever this person likes it.
I don't even know what zig codes look like, but it, you know, natively compiled code, right?
Would it be faster?
Would it be cool?
Would it be like you could use the same decorator and the same model?
technically doesn't use Pydantic.
It uses some other thing, that is zig based instead of Pydantic as the foundation, but it understands the models the same and seven times faster.
So on.
So anyway, I thought this was cool.
It's like this kind of Twitter thread.
It got a lot of, it's got 325,000 views.
So, Hey, it caught some attention.
How about that?
And I don't know.
It, it was kind of interesting.
I looked at it a lot and like, ah, you know, I don't really care too much about that, but I just, the idea of it got me thinking about something.
So I wanted to throw that out there.
It's, it's kind of popular now.
It's got a lot of GitHub stars and so on.
I'm not suggesting people use this over FastAPI.
It's that's tried and true and all, and so on, but this is kind of an interesting idea.
Anytime you publish benchmarks, you, you will receive an inordinate, an abnormal amount of attention in not a good way.
So I'd follow a post.
I learned a lot from the turbo PG benchmark mess.
Interesting.
Also, there's a, there's a, some pushback that, oh, you used agentic coding tools to help do this transition or write this code.
I think this is, this is very interesting because a lot of the pushback to astral being acquired by open AI.
Wasn't that we think open AI is going to be bad.
It was, I hate AI.
I hate open AI.
And therefore I hate this.
You know what I mean?
And it wasn't an assessment of do I think this is better or worse for this project.
It was just like, I hate them because they're AI.
Cause I hate AI.
And so there's this really interesting tension.
And so if you want to like, kind of live in that moment, you can read, read this whole thing.
I think that's pretty interesting.
So anyway.
Yeah.
There's also like, we get sent projects all the time and I'm, I'm of, of like, oh, there's this new project.
Check, check this out.
And there's nothing behind it other than like two days worth of AI generated stuff that I don't think the person that wrote it even like read it or tried it or anything.
And, and I totally concur on that.
I agree with you on that.
If, if the thing solves a legitimate problem that wasn't there before, that wasn't solved before and it was generated with AI and it seems generated well, like, okay, it's still interesting.
but yeah, we definitely get stuff that's just like clearly just AI generated and like people are looking for promotion for it and that we're not looking necessarily to shine that, that sort of light.
But for example, in the, I think it was in the Ars Technica thing, literally one of the comments was, I hate open AI.
This should have never happened.
Or, you know, something like it was like, it was that explain, it was, you know, it was verbatim when I said, basically.
So I know you got some other extras, but I want to interrupt a little bit more.
I have a couple ideas then is next time I want to try to like hype up something, I think I'm going to put fake, fake timing, data in there then.
Yeah, exactly.
performance metrics just to, or even just bad performance.
They're not fake, but they're bad.
so that, you know, to get people.
And the other thing is, what do you think about like, you know, selling Python bytes to open AI?
You know what?
Hey, I love our listeners.
I love what we do, but I would not be against this if, if they come, if they come with the money.
All right.
So, chances very, very low, really quick pyramid pyramid, the web framework.
Yes.
Pyramid, which by the own bytes was originally based on from way, way back in the day has a release.
Now you might think, Michael, why are you so psyched about this?
Cause we're running it on court, async class, whatever, right?
These days, this is the first actual release of pyramid.
In five years.
So I'm like, wait, there's a new version of it.
What is that?
What's going on here?
Technically there was a release three years ago, but it was like a very minor thing.
Okay.
And so there's not a lot going on here.
Basically setup tools had some issue with the way that it was managing packages.
Like pyramid web apps are packages and setup tools was saying the way that you start your web app or install it is about to be no longer supported.
So the thing actually pins the setup tools to a version that will work.
But if you have something else that depends on setup tools, you can't use it.
So it's always a bit of an issue.
The other one is they literally, as part of this release added pyramid.acp exceptions.acp !imatpod exception.
I love it.
So anyway, that's, that's that, Vivaldi.
We're both fans of Vivaldi.
I know a lot of Python people are fans of Vivaldi and the privacy angle and the not, not Chrome angle.
Just released this really cool, new sort of auto hiding style where you've got this like really minimal UI that feels very Arc-like.
People like that, like Arc browser a lot.
And so you, most people are listening to it or know, but you, you can't see my address bar.
You can't see all the Chrome around.
It's like just sort of very minimal.
You can like turn it into just like this, just the essence of the web.
You can even auto hide your tabs, but it's, it's a bit too much for me.
I like when I know like I've got 20 tabs open, how do I get back to the one I want more easily and sort of navigate that?
you can add a bunch of hotkeys that make this work better.
For example, like I used to go to the address bar and copy the URL cause I needed to use it in some sort of writing.
But if it's hidden now, then how do you do that?
So I had it a hotkey to like just copy whatever thing I am on.
So it's kind of encourages you to be a little more hotkey driven.
So that's fun.
People should check that out.
I saw you just turn that on Brian.
This is the show.
Yeah.
We'll see how it, how you take to it, but it took some getting used to, but I definitely like it.
You just got to be the more mellow around the edges.
If you get too quick, stuff pops over and covers the nav and that's kind of annoying.
Yeah.
When those stuff would pop down, it would like move the window, the actually, as if that thing existed in the UI.
So it didn't cover your elements, but whatever.
One of the places where I'm seeing, I'm, I'm using it the most is places like here, but, or at work during presentations where I don't, it's, I don't, I just want to show the thing that I'm showing.
so yeah.
Yeah.
And certainly on like small laptop screens and stuff.
It's super cool.
Okay.
A couple of things, that the reason I even brought up turbo API is it got me thinking about, well, what if our code ran on pure rust, like all the way up until like where the code
that we write starts running, you know, not the framework stuff, but just that close.
Right.
So I looked around and found Robin, R O B Y N web framework, which is basically exactly that in an order to test it.
I wanted to do a spike and see if I could convert one of our apps like Python bytes to Robin.
Would it be a lot faster?
I don't know.
Well, there's a whole bunch of chameleon templates and only supports Jinja.
So I'm like, well, in order to do that, I'm going to have to create a chameleon Robin package.
So I did.
So I added chameleon support to the Robin language so I could see if it was any better.
turns out, no, not really.
Was it really worth it actually?
But now the world has this cool, chameleon Robin project.
So, chameleon is a little bit more out there.
And I was also playing around this week.
I was trying out ideas this weekend.
This raw plus DC, the, data classes pattern that I talked about that makes, you know, removes the dependency of your ORM library in terms of like, if it doesn't get updated, that makes it easier for AIs to understand.
Cause it knows raw, the raw query language of your database and so on.
I actually switched, talk Python and Python bytes over that this weekend, just playing around and it's like 10% faster, lower memory usage.
Why not?
Oh, wow.
Yeah.
Pretty sweet.
Have you considered raw plus Marvel?
No, I know.
It's a, it's, there's better stories over there, but no, I think that's it for our extras.
We got a joke though.
And this one, this one comes to you, comes from you.
This is a pretty, pretty good stuff.
I love this.
You want me to just see how my screen up here?
I'm going to put, we're going to start.
So, so set the stage for us.
What is going on here?
so do you, can you get the LinkedIn?
Oh yeah.
So I just like, there's the normal, like Google translate.
You just type in stuff or whatever.
All your translate tools are type.
It converts it.
somebody on Kagi wrote a, LinkedIn speak converter.
so you can convert English to, to LinkedIn or back.
So if you, if you're looking at somebody's bio and LinkedIn, you can, or any, it works for resume speak as well.
You can just finished it.
Like finished my last contract.
What are you writing?
I just finished my last contract.
I'm looking to move to AI programming.
okay.
Anyone interested?
So what do we get?
what are we going to get?
So I just finished my last contract.
This is what, this is the input.
I'm looking to move on to AI programming.
Anyone interested in someone who lives every day is day one.
Remember that like LinkedIn?
Oh yeah.
Yeah.
So here's, here's what we get.
Hashtag new beginnings, rocket ship pipe.
I'm thrilled to share that I'm officially wrapping up my last contract.
It's been an incredible journey, but I'm even more excited that for the next chapter, diving deeper into the world of AI programming, robot star emoji.
I'm looking for the next challenge with a team that values growth and innovation.
I'm someone who brings that day one mentality to everything I do every single day, hockey stick growth emoji.
If you're looking for a passionate developer, ready to push the boundaries of AI.
Let's connect.
Handshake.
Hashtag AI.
Hashtag machine learning.
So on.
That's funny.
That's pretty good, right?
You know, it's even better.
What?
You can type other stuff in here.
That's not in the list.
AI bro.
Custom.
Just sunset in my last gig rocket ship.
Ready to pivot into AI and scale some world changing models.
Who wants a builder who stays hungry and treats every day?
Like day one, let's disrupt robot emoji, fire emoji.
Hashtag built in public.
Okay.
So go back to the LinkedIn one though.
Hold on.
You got more?
Cobalt.
Cobalt programmer.
Oh my God.
It wrote a program that stated this.
It's like basically like printed.
Hello world.
To say the display day as mindset.
Question mark.
Stop running.
Oh, would you look at?
That was a little cat.
I has finished my last job.
Now I wants to do AI codes.
Who wants a kitten who lives every day?
Like day one.
You want me to go back to LinkedIn one?
I'm getting distracted.
I'm sorry.
I apologize.
Oh, and in the English, just type.
I'm a programmer.
This is pretty good.
I'm a passionate software engineer dedicated to building scalable solutions and solving complex problems through code.
Okay.
But what if you saw that?
So do that, like flip back and forth, like the little button in the middle.
Oh, I see.
So that translates.
I do.
I write code for a living.
I spend my days trying to fix things that shouldn't be broken in the first place and make sure the whole thing doesn't crash when more than 10 people use it.
That round tripping is incredible.
That is incredible.
Yeah, we did that.
My daughter and I did that with a few job descriptions and round tripped a few times.
And it's, it's, you get some crazy things.
Kind of want to put my LinkedIn page in here and see what happens.
Just see.
But yeah.
Anyway, I actually think it might be a useful tool for like, you know, depending on how brain dead you think your hiring manager is.
Yeah.
Or you could just de-buzzword it, put in what you see and then see, translate that to English.
Yeah.
Anyway, well done, Kaggy team.
That's awesome.
Cobalt is nice.
Yeah.
All right.
I know folks, we went a little bit long in this one, but the whole astral thing, I think, deserves some, some conversation around it.
Yeah.
We'll see.
Thanks for being here, everyone.
See you later.
Bye, Brian.