Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 437, I can't believe that, recorded June 23rd, 2025.
And I am Brian Okken.
And
I'm Michael Kennedy.
And this episode is sponsored by Posit, so check out that section later in the episode.
We really appreciate it.
If you'd like to send us items or comment on the show, you can reach all of us.
the links to our socials on blue sky and mastodon are in the show notes so check those out and if you'd like to sometime join us live or at least watch the show even later we since they're all they're all up later you can head over to pythonbytes.fm/live and find out where all the videos are or schedule to watch us we or hang out with us we um we do watch the chat and sometimes take questions from there or extra comments.
And that is Mondays at 10 a.m. usually, 10 a.m. Pacific time.
Also, finally, please go over to pythonbytes.fm and sign up for the newsletter.
We're putting a lot of work into this to try to make this a useful resource for you, not just the links to the topics, but some of the background information.
And it's just more than just the show notes.
So check it out.
They won't know until they subscribe, Ryan.
Yeah, you just, I mean, you can always delete it.
Like, we don't sell your name or anything or spam you, so might as well sign up and try it.
Speaking of, I guess, Python stuff, Michael, do you want to kick us off with the first topic?
I have a meta topic, a topic of topics, if you will.
The Python Language Summit was held at PyCon this year, back in May, I guess May 14th, in Pittsburgh, Pennsylvania.
However, why are we talking about this now?
Because Seth Michael Larson, who is the, I don't know his title exam, I messed it up, sorry Seth, security developer in residence at the PSF for Python, was the official note taker, blogger, eyes of the community sort of thing.
And they just, they just published on June 12th, the Python Language Summit 2025 write-up, which is a write-up of the whole event and the 10 or so talks that were given there.
So you get some really interesting looks into where the core developers are focusing, what they're considering for the future.
Most of this stuff is forward-looking, or at least if it's not 100% forward-looking, it's like, hey, we should be doing this.
It's talking about problems that need to be solved in the future, you know?
So I actually interviewed Seth over at Talk Python.
This will be out in a couple of weeks.
The live stream, like ours, is also available here at the links on Talk Python.
So people can't wait for the edited version.
they can check that out.
But just to give you a sense of what was out there, some of the topics included how do we make breaking changes less painful?
That was Itamar Oren from Meta talked about like when you move from say Python 3.11 to 3.13 or something like that, like what broke?
You know, when you have millions of lines of Python like Meta does and that's executing at scale, you know, maybe minor, things that might seem minor inconsequential to the rest of us, like all of a sudden, that 5% performance change here made a big difference one way or the other, like that kind of stuff, right?
And it talks about non-obvious problems.
Like, for example, if you want to learn about something that was taken out, like if you think there's a problem because a part of a standard library was removed, well, the documentation was also removed.
So it's like, how do you find the thing that was documented, but it's no longer there?
You can go back in history to the different versions of Python docs, but the default is latest, which no longer, you know, which are basically 404s, which is weird.
So like that kind of stuff, right?
That's a decent idea just to like leave it in for versions.
Just make the
background like red or yellow or something.
Go, this thing is dead.
If you're viewing it, stop viewing it.
It's going to hurt your eyes.
The next, there was a whole series.
I would say a third of this entire conversation was on async, IO, threading, concurrency, crazy ideas about like how do we deal with, What can we do to make it obvious at runtime that you're running into threading problems?
Because just last week, Brian, you talked about this, the experimental tag came off of the free-threaded Python.
So now it's really free-threaded.
It's truly free.
But there's a lot of like, well, what are the consequences of that?
And how do we build for that?
And what can we do to make this easier?
And I'll put that in quotes.
So there was an uncontentious talk about contention by Mark Shannon, which is like concurrency.
What can we do to make things more immutable so that we can share them more easily and so on?
There's the state of free-threaded Python by Matt Page.
Fearless concurrency by three folks, Matthew, Tobias, and FreeJoff.
Anything else on threading?
Sort of.
Not really.
But, you know, out of 10 talks, that's quite a bit.
There.
There was some docs updates by Marietta.
The challenges of the steering council.
Like, basically, how has it been going the last couple of years now that we have a steering council and not a BDFL?
And that was by Eric Snow.
it's pretty interesting like hey good news things are still working not great news stuff led by a committee of volunteers goes slower than one person just goes sounds good surprise um some packaging stuff by barry warsaw and pradium get them python on mobile by russell keith mcgee so this is interesting in that peps 730 and 738 have been completed and russell went in front of all the core devs said after many years this year i can say that python on mobile is there how about that Now, that doesn't mean all the tooling, front-end frameworks, UI frameworks, all that kind of stuff are there for building Python apps.
But CPython is now a tier three supported platform, which means the core developers as part of the continuous integration, everything of Python itself, make sure that it also builds on iOS and Android.
That's what that means.
Still good news.
Yeah, I'm
looking
forward to the time where, I mean, I know that everybody is, but it'd be cool if I could just open up VS Code or PyCharm and write an iPhone app.
I would probably practice my backflip,
see if I could do a backflip if that happened.
Like, that would be so awesome.
It would be so
good.
Yeah, it would be so good.
That and
JavaScript frontend, like Python, PyScript frontends.
Let's go here for both of them.
Speaking of which, there was an update on Pyodide and the JavaScript FFI, the language bindings that allow PyScript or Pyodide, actually specifically Pyodide, to talk to the JavaScript stuff.
So from Python front-end stuff, you can actually interact with JavaScript directly rather than indirectly, a little bit more clearly.
And most importantly, there's slight variations in how you do this in MicroPython and Pyodide, which means you can't use interoperable code between the two in Pyodide, PyScript world, which is weird.
And this is about trying to solve that amongst other things.
And then finally, what do core developers want from Rust?
Do people want Rust? Do they not want Rust?
And if you're looking for native, probably the biggest piece of news here is that our best estimate is somewhere between a quarter and a third of all native code being uploaded to PyPI for new projects is based on Rust.
That's pretty big.
It is pretty big.
Yeah.
All right. So I think either check out the blog post or listen to the episode I did with Seth.
This is good stuff to track.
Okay. Nice.
All right. Well, I'm going to change gears completely and just talk about, zoom in on one thing about Python, and that is Python properties. So Will McCoogan wrote an article called Fixing Python Properties. And I just thought it was an interesting take on how to get around some type checking quirks. So he starts off with talking about basically the properties are awesome and the type checkers are fine with properties. However, the type of a property is taken from the getter method. And I guess that makes sense, but there really are two, there's getter and setter. So if those types don't match, your type checker is not going to like it.
And so he walks through a, and I'm like, well, why, why would you want different types for your getter and setter? And he walks through a padding dimension example, which is, I think, I mean, he's doing textual so a decent um he's an example of he wanted to be able to just have somebody be able to say hey um for my padding if there's there's really four values but kind of like with css if you provide one value it's applied i don't remember all the rules it's applied everywhere if you if you apply to set two paddings it'll apply to like the distributes them appropriately just like css and so you can do uh basically one value two values or just an integer a tuple events of just two values or you can provide four um and all of this should just work and it does with python but you can make it work with like some you know with your code checking for all of those things but with type checkers it'll say you're doing something wrong and um he he said we i could make it like type check better but just like kind of destroy the user experience but instead he um he provides instead of doing properties so he just like rips out that the idea of the property um he's in the first example he's using the property the decorator um but he uses uh what he calls a descriptor which is i don't know if this is a real thing like he talks about it as if it's like a programming construct, but I'm not familiar with it.
Anyway.
Yeah, I think it's part of Python, like an advanced get adder, set adder sort of thing.
It's a class that has, it's just a class that defines both a get and a set method.
So that's your descriptor class.
And he uses that instead of a
property.
And that is all it takes to be able to make it work without PyPI or without type checkers freaking out.
So that's just it.
Oh, an update.
Somebody, Peter, pointed out an issue.
Okay, well, I haven't read that part.
But you know one of the problems with typing
all over the place, and his thing says, look, it might be fine in my Pi, but then in VS Code, the Pi Lance validator understands this differently and gives you an error.
One of the things that drives me utterly crazy is, like, you've got these different tooling, And they all have a slight variation of like, that's fine.
Or like, actually, no, that's not fine.
And we've got Ty and you've mentioned Pyreply coming as well, which are going to be other ones probably have slightly different defaults.
And so when you say I fixed it, like what did you fix it for?
Exactly.
Did you fix it for
all of them?
Did you fix it for your editor?
Did you fix it for this CI?
Like there's a lot of variations and it drives me crazy.
And it's especially, so I just have like a couple of small packages that I maintain.
And I have like, you know, like PyTouchCheck is now type, has type hints around it.
And that's helpful.
But it's a little bit of a quirky thing.
And it doesn't, it works fine on mypy, but it doesn't work on some of the others.
And I've had to write or
something.
Yeah, about that.
I'm like, well, use mypy.
I don't know.
You can't really, if it's a dependent library, you really want to use that for everything.
Yeah, exactly.
It
is a mess.
I've had some stuff like that.
It's like, this thing doesn't work right on PyRite.
Like, okay, help me understand why I care about that.
But they're like, you know, if I use it in this setup, I'm going to just get like errors.
And it wasn't something super mild.
It was for one of my web things.
And basically the library was used as a decorator.
So anything they decorate now gets like invalidated in terms of its type.
I
wonder if that's something now that I probably, for libraries, we should be testing against multiple type checkers, and that's just one.
Probably.
It's super annoying, but yeah, probably.
And then here's the most annoying part of it was, though I think it was Pyrite, is like Pyrite was giving errors that now the Flask view method doesn't match the type or something, but Flask was fine with it.
And nobody ever, ever, ever directly calls those functions.
Only Flask calls it.
And so like, here's some functions.
Nobody calls them.
It's affecting nobody.
because they don't, no one even sees the type information.
Flask sees it. Flask is fine.
But I still have to like do really complicated typing information to get the type checkers to stop giving them more.
Like, are you serious?
It's not getting easier because we're getting more type checkers.
Well, I thought all this was supposed to just be kind of invisible and we just get benefit and no cost.
Until you get an issue about it.
Now, I appreciate that people found the issue because I did fix it.
but it was like a couple of hours of really complex type juggling.
Oh, you're a nicer person than me.
For something nobody called.
Yeah, well.
I did the classic, yeah, I don't use Pyrate, but, you know, I'd accept a pull request.
Yeah,
exactly.
One other thing, like, so rolling back just a tiny bit, like properties, if I had to say, like, somebody said, Michael, what is the clumsiest, most non-intuitive, less than ideal, less readable or just bad part of Python, the language?
Properties.
It's so bad.
There, I could have like in separate files, maybe it made me as separate parts of files.
I could say over here is a getter and then somewhere else there's some weird setter.
And like, why does the setter dot something like just the at setter dot variable name of a thing I've defined before?
It's just so chunky and weird and the typing is a mess.
If you look at the way C# does this, probably other languages as well, it is so nice.
You just public property name, you have a getter and you have a setter right in there.
I know that you could create separate classes for descriptors like Will was talking about.
I think there might be maybe different performance profiles for those property versus a descriptor.
But I would really like to see Python clean up.
It doesn't have to be what C# does.
but something where like they go together, they're obvious, you're not defining it twice, et cetera, et cetera, et cetera. It'd be nice. Wouldn't it be nice, Brian?
Wouldn't it be nice?
You know what is nice though? Our sponsor this week, Posit, super excited. Let me tell you about what they're offering everyone. So this episode is brought to you by the nice folks at Posit.
So Posit, originally they came out of the R space, right? They made R studio and they made some other things, but they really have been putting a lot of effort into Python these days, right?
They've created Posit Connect, awesome way to run and host your data science stuff.
They made Shiny for Python, which is like a reactive notebook, like Marimo or a little bit like cheaper notebooks and stuff.
So they're doing awesome stuff.
So I'm really, really happy to have them sponsoring the show.
Today, I want to focus on data science workloads and how to host them.
So you have dashboards, reports, plots, interactive web apps, all the way to custom Flask or Django apps.
They have a service called Posit Connect.
And Posit Connect makes it easy for data scientists to share work they built with Python.
So if you've got a Streamlit app, dashboard, Plotly, interactive plots, FastAPI, Quarto, just connect it to there.
And their service will maintain it and connect automatically, hosts it, updates it for you, and so on.
So you can even have it update reports on a schedule.
So if you host a dashboard, you can have it rerun the data science stuff that computes the graphs and does the summaries like on a cron job sort of thing on a schedule.
So no reason to explain to stakeholders why the dashboard or plot stopped updating last week.
Just set it up, pause it, connect, got it going.
So you can focus on your data science work and leverage your skill set while connect makes you look good, keeping your code running and private.
With Connect, you get a private URL on your Connect server, ensuring that your asset is continuously available to your shareholders.
You can control which users have access to that asset.
And just let Connect handle all your DevOps for you.
You can share your work.
Keep doing what you do best.
So if you work on a data science team, you owe it to you and your org to check out Posit Connect.
Just visit pythonbytes.fm/connect and get a three-month free trial and see if it's a good fit.
That's pythonbytes.fm/connect.
The link is in your podcast player show notes right at the top.
Thank you for Deposit for supporting Byte on Bytes.
Yes, thank you.
And a rewrite.
All right.
Well, next I want to talk about some complexity in your code.
And Complexipy.
Complexipy?
Complexipy.
It's C-O-M-P-L-E-X-I-P-Y.
This is a project that's new to me.
And actually looking at the repo, it looks kind of new.
it's modified in the last weeks.
So I'm really kind of enjoying it.
So what is Complexify?
So it's an extremely fast Python, I'm quoting here, an extremely fast Python library to calculate the cognitive complexity of Python files.
And it's written in Rust, just like you said, a lot of PyPI stuff going up that's written in Rust lately or written parts of it in Rust.
Looks like 45% Rust, 23 Python.
Anyway, so this reminded me that I should be paying attention to complexity.
So I'm glad this came out.
So what is cognitive complexity?
Well, it's kind of like cyclomatic complexity.
Do you remember cyclomatic complexity?
Kind of.
I'm going to include a link to the Wikipedia page, but you can look.
So I remember it from Flake 8.
So Flake 8 had cyclomatic complexities and using the McCabe, I don't know, the McCabe test around it.
But it would just sort of, I never used McCabe directly.
I just used it with Flake 8.
And now actually I'm using it with Ruff, which is kind of cool.
I just recently realized this, that you can pass in the rule C901, and you can do a complexity check on with your rough tests.
So that's super awesome.
And so this is kind of fun.
But what are we looking at for cognitive complexity?
Well, there's a link within here of the white paper.
There's a white paper, and you kind of have to – the white paper comes from Sonar Source.
They do SonarCube, if anybody's familiar with that.
It's a static analysis stuff.
And I read the white paper and I skimmed it, really.
But it's actually a really easy read, talking about how the idea around it is not just like giving you a number for your entire source code of how complex stuff is and where the problems are, but really looking at everything.
So there's, you know, more loops, more structs, more everything.
It's really a little bit different take looking at really the maintainability.
So there's a discussion in the white paper talking about that cyclomatic complexity was intended to make it to measure how testable and maintainable.
And the testable part comes from that the testability.
Like if you have multiple branches, you have to test all the branches.
So more branches means more tests.
That it does well, but the authors of the white paper don't really believe that that it measures maintainability as well.
So this is another attempt.
And I think it does pretty good.
And plus, it's super fast and the output is great.
So I ran it on a couple of the, I ran both the rough version of the McCabe test and then this against my code, some of my code.
And it came up with the same hot spots.
And so I'm going to look at what the output looks like.
I wish this was in color because it's in color when you're doing it on the command line.
And the colors really help because it does like zero means like there's no problem here.
It's not complex code.
And then the numbers go up and there's, I think there's levels that you can set, but it's, there's the defaults are fine of, you know, yellow and red for things that you really want to care about.
And then by default, it lists, like you pointed at a directory and it'll list out everything.
You can just tell it to just, you can have it just list the problem parts too.
But it is kind of nice to just see the whole thing.
If you've got not too, too large of a project, if you have a huge project, definitely just look at the problem parts.
The reason why I'm really excited about this again, oh, it talks about the analysis here in the readme even.
That's nice.
And you can output it to a CSV file or whatever.
But I just did it on the command line because why would I use this?
Not just as a pass fail within CI, which is a good idea to do a pass fail in CI.
What I want to know is the areas of my code that probably might need refactored to be less complex.
But if they're already as clean as they can be or they're that bit of code that you have that the person that wrote it is gone and you're not sure how to touch it.
Those are the areas to really throw some unit tests around or some subsystem tests around those areas are a good thing.
Anyway, think about, remember complexity.
And I like the idea of not just of thinking of cognitive or maintainability complexity.
This is a really cool idea.
I like it.
I am an absolute junkie for this stuff.
I love
it
so much.
So I'm glad you pointed out.
Christian out in the audience says, great, Radon is really slow.
So cognitive complexity is the last thing preventing me from dropping Flex 8.
Superflake 8, pretty cool.
And I used to, I mean, when I say used to, I'm talking like 25 years ago, used this tool called Code Rush, which was amazing.
I've still not seen anything as great for an editor add-on as it did, even to this day.
So good.
One of the things it did, though, is it had maintenance complexity, cyclomatic complexity, and I don't know if it had this
cognitive,
but it had like line count was an option.
And next to every, in your editor, next to every function or type in like a class or something, it would have the, you could choose, like, do you want the maintenance complexity or the cyclomatic complexity?
Just sort of ambiently by your
things.
And you could be like, or you can run an analysis and say these are the seven that are like over some sort of threshold.
Like I don't want it over 75 for my maintenance complexity, whatever that means.
Yes.
If people know about that, extensions like that for PyCharm and other editors, you know, shoot us a, put a comment on the YouTube channel, on the YouTube video
or mention us somewhere, something like that.
I'll have to try it out because Complexify does have a VS Code extension.
I don't know how it looks though.
So we'll have to check it out.
Yeah.
Does that just output it in the terminal?
Yeah.
Or does it actually
overlay it like CodeLens?
Yeah, it would be cool if it was an overlay.
Pat is spreading fake news.
Pat Decker, the audience who's been on the show, says, Michael volunteers to create a VS Code extension, is what I just heard.
We're going to edit that section out.
We'll just move right along here.
All right.
No, it's fun.
Okay.
I want to talk more data science stuff.
Let's talk Juvio, J-U-V-I-O.
I don't know. How would you say it, Brian? Every one of these needs like a little, how do I pronounce this button? Juvio. Is it Spanish? I don't know. So Juvio is a reproducible dependency aware, get friendly Jupyter notebook. All that sounds interesting. And there's a lot of things that say that, but what is, for me, what is, how's it, how do I think of this? And it is in the name.
It's a Jupyter notebook sort of environment that is based on uv. So one of the things I find super clunky about Jupyter Notebooks and JupyterLab and Jupyter is you can create a virtual environment, you can install Jupyter in it, you run it, and then you have to somehow go and independently outside of Jupyter register your kernel to find that virtual environment so then you can use that thing. It's just like, what? Okay, so Juvio allows you to basically run commands in your notebook to install things, right? You can actually use the script thing from uv where you say script, requires this version of Python, these versions of the dependencies.
And then when you open it up, Juvio installs the dependencies automatically in an ephemeral virtual environment using uv.
All of that I'm loving.
How cool is that?
So you just put in, you know, this is what this notebook depends upon, even the version of Python.
And if that version of Python is not on your machine, uv will download it and then create a virtual environment for you.
That is awesome.
Yeah.
It's also Git-friendly.
So notebooks are converted on the fly to script style format, which is where you have the hash, then percent, percent.
So if you open it up in like PyCharm or VS Code, it has like cell type behavior.
This one is for the Brave.
It is an early beta.
It's better than early alpha, I suppose, but an early beta.
So check it out.
Yeah, pretty nice.
You can enable it as a extension is how you basically set it up.
That reminds me like a little bit of a tangent, But you know that with uv, you can put those little script things at the top of your file to do your dependencies just in the file?
Yeah, that's the same thing here, by the way.
Yeah, I've just realized I've been going through using some of the stuff that I've built over the last many years at work.
And some of the stuff, they had been little tiny little packages.
And I realized that they don't need to be packages with this.
They just have a couple dependencies in a single file script.
And now they're back to just single file scripts again.
That's cool.
It's awesome.
You just say uv run the script and it looks at that and says, all right, what do we need?
Do we need Python?
What version of Python?
What dependencies?
And once it's cached that stuff once, right, once uv has cached that once, it's basically instant.
Yeah,
it's cool.
Yeah.
Super cool.
So yeah, that's pretty much it.
If that sounds interesting to you, check it out.
Let us know what you think.
but somehow making Jupyter Notebooks work automatically with ephemeral environments in Pythons managed by uv speaks to me. I like it.
Oh, and Pat Decker suggests again alias py equals uv run. Perfect.
So you can just pi.
Doesn't work on Windows because there's already a pi, but alias itself doesn't work. So you know what?
You have to create a batch file or something. I don't know.
I guess. I've been using batch on Windows for decades, but
you are such a
rebel.
so one quick extra for me is that testing code is not dead but it looks like it so testing code the last episode of it came out may 7th and checks calendar it's june 23rd what's up there what's up is kind of some life there's a lot going on outside of my day job and python bytes that is pushing this out.
But I have some great interviews already ready.
They just need edited.
So stay tuned.
There will be great stuff out.
I just interviewed Sebastian Ramirez recently, and there's some great interviews coming up.
So stick with it.
Be patient with me, please.
Anyway, we'll be back.
But I never let Python Bytes drop.
It's weekly, no matter what, because of Michael.
Python Bytes is awesome.
Yeah.
Do you have any extras?
I thought no, but I just realized I'll throw something out there.
Okay.
So later this week up in Washington, almost in Canada, there's the largest off-road motorcycle rally in North America, I believe.
The Tour Tech Rally, which is like 1,500 people going to this campground and doing like joint rides and stuff.
I'm going to be there from Thursday to Sunday.
If people are there, shoot me a text.
Come say hi or go riding together or something like that.
All right.
It's in Plain, Washington?
It's not
fancy in Washington?
No,
this is like basic camping.
Well, can you put it on your motorcycle and then camp from there for four days?
Okay.
It's going to be very plain.
It's actually right by Leavenworth, which I think is kind of a cool place.
Cool.
Oh, yeah.
That's it for my extra.
So shall we do a trio of jokes?
Sure.
All right.
So someone sent this in, and I'm so sorry I forgot who sent it in, but I found it in multiple places, and it was really great that they did.
Programmers are human.
I think we've covered stuff from him before.
This amazing German guy who does really good jokes.
Like I think we talked about the vibe coding one one time.
Yeah.
Remember
that?
Senior engineer tried vibe coding.
That was so good.
So he's back with the interview with the 0.1x.
People heard the 10x engineer.
Like the 0.1x engineer.
Full.
I found the full episode.
The 10th.
What do you think of it?
This was hilarious.
I immediately, as soon as I watched this, I texted you also and said, have you seen this?
Like, yeah, I watched it half an hour ago.
It's so good.
Yeah.
We're not going to play it because I don't know.
Like, it's someone else's YouTube work.
We'll let them have it.
But it is so good.
It is certainly five minutes of time well spent.
So we'll link to the YouTube video.
It's got awesome comments like, yeah, the last stable release.
Yeah, yeah.
That was before I joined the company, wasn't it?
And stuff like that.
Or my job at the company is to optimize the file size of the readme.
Yeah. Yeah. Or there's some, I've forgotten a lot of them, but there's some really good, good, good one
-liners to.
You want some sweet
one-liners? Yeah, here we go.
This is
it. And totally unrelated. I have two more, not, not related to this, but I think Python relevant is Google came out with VO3, which is a, a way to make full film AI content, not just images, but it's images, voice, movie.
it's insane. And so I've stumbled across this. Now, before you, before you click on this and before you visit it, I must warn you, this is like kryptonite to your YouTube feed. So if you watch this, it will take days to get anything normal on your YouTube feed again. I don't know why do it in incognito. Just trust me. Don't make the mistake me and my daughter made. She's like, dad, I got it. Literally got a text. Dad, you've destroyed my YouTube feed.
So there's a couple of video, a couple of channels, and there's like multiple ones of these, But I'll link to a couple that are really good.
There's a Bigfoot and a Yeti channel.
And all these are like vlogs, like in the day of the life of Bigfoot and so on.
And oh my goodness, is this so funny.
And it is incredibly good.
So you can only make eight second clips, right, with this video thing?
So what
they do is they just make clip after clip after clip as like little segments in like the vlog of the life.
If you haven't seen this, I think you'll be surprised.
If you, there's the Yeti Bigfoot one, which is real good.
And then there's also the day in the life of a storm trooper, adventures of Dave and Greg.
These, these are so funny and you know, they're made with Python somewhere along the way because of all the AI stuff and the VO and whatnot.
But just remember incognito or you don't blame me.
Yeah.
I'll probably just use the Python bytes account.
Yeah, exactly.
Yeah.
Please.
We'll have nothing.
I love nothing but these things in there.
Now,
it's really
funny, and it's just one more AI thing in this world that we live in that is just a weird time.
But it's super creative, too.
Like, people really are being creative with it.
Okay.
And I
got to just say that, like, you know, wherever you stand on AI, stuff like being able to make movies around with, like, Stormtrooper costumes and stuff, that is out of the realm of most people's
budget.
But the ability, I'm sure it's fairly time-consuming to put these things together.
But now it is in the realm of somebody that just has some good writing, some good sense of humor to be able to put
these
things together.
So
that's good.
Yeah, there's definitely good writing here.
You've got to do the script and stuff.
But comments are like, this is better content than Disney has done in the last few years.
It's really funny.
So, I mean, it's surprisingly well done.
And the AI is, you know, we live in weird times, Ryan.
That's all I can say.
Well, in eight-second clips, I mean, pay attention to the last action movie you've watched that doesn't stick with the same camera angle for more than a few seconds anyway.
Yeah, yeah.
It doesn't
seem that out
of place.
All right.
There's your jokes.
Seriously, relevant joke.
Check out the 0.1x engineer.
That's amazing.
Yeah,
definitely.
Over lunch, maybe grab the logs.
I'm really warning you, don't do it on your regular account.
yeah all right well that's it for today a wonderful episode with you again michael thank you yes thank you as well and
before we sign out this is not something we've been doing lately brian but maybe we should more it's like i just want to encourage people who are watching the youtube channel here either live or in in the future at some point you know please subscribe to channel like the video and help us spread the word yeah
i guess we don't we don't like do call to action too much but uh like the videos that would be great but i also um uh we can grow the podcast more share it with a friend if you've got some new interns starting say hey you should keep up on python much more you should check out this podcast it's staying up on python in easy mode you got a car rider you're mowing the lawn you're doing the dishes hit play it's all
good get to later bye