We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode #437 Python Language Summit 2025 Highlights

#437 Python Language Summit 2025 Highlights

2025/6/23
logo of podcast Python Bytes

Python Bytes

AI Deep Dive AI Chapters Transcript
People
B
Brian Akin
M
Michael Kennedy
Topics
Michael Kennedy: 我介绍了Python语言峰会2025的亮点,包括如何减少破坏性更改带来的痛苦,异步IO、线程和并发的讨论,指导委员会面临的挑战,Python在移动设备上的应用,以及核心开发者对Rust的需求。峰会涵盖了多个重要议题,为Python的未来发展方向提供了有价值的见解。 Seth Michael Larson: (通过Michael Kennedy转述) 我撰写了Python语言峰会2025的报告,详细介绍了整个活动和大约10场演讲,旨在帮助社区成员了解核心开发者们关注的重点以及他们对未来的设想。

Deep Dive

Chapters
The Python Language Summit 2025, documented by Seth Michael Larson, covered various topics, including making breaking changes less painful, concurrency challenges, updates from the Python documentation editorial board, and the state of Python on mobile. Discussions also touched upon packaging governance, the steering council's challenges, and the integration of Rust within Python.
  • Seth Michael Larson documented the Python Language Summit 2025.
  • Discussions focused on mitigating the impact of breaking changes.
  • Significant attention was given to async IO, threading, and concurrency.
  • Python on mobile is now a tier three supported platform.
  • A considerable amount of native code on PyPI is Rust-based.

Shownotes Transcript

Translations:
中文

- 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 Akin. - And I am 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, since they're all up later, you can head over to pythonbytes.fm slash live and find out where all the videos are.

or schedule to watch us or hang out with us. 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 pythonbyst.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 so it's just more than just the show notes. So check it out. And they won't know until they subscribe, right? Yeah, you just I mean, you can always delete it like we don't sell that sell your name or anything or spam you. So may 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, and it's Pittsburgh, Pennsylvania. However, why are we talking about this now? Because

Seth Michael Larson, who is the, I don't know his title exactly. 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, he just published a,

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? Yeah.

So I actually interviewed Seth over at TalkPython. This will be out in a couple of weeks. The live stream like ours is also available here at the links on TalkPython. So people can't wait for the edited version. They can check that out. 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 Python

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's, 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 that is no longer there? You can go back in history to the different versions of Python docs, but the default is latest, which no longer-- which are basically 404s, which is weird. So like that kind of stuff, right? That's a decent idea, just to leave it in for a version and say, hey, this is going on. Just make the background 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 like, what can we do to make it like obvious at runtime that you're running into threading problems because

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 it

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 Friedhoff. Anything else on threading? Sort of, not really.

But you know, out of 10 talks, that's quite a bit. Yeah. 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 committee of volunteers goes slower than one person just goes. Sounds good. Surprise. Um, some packaging stuff by Barry Warsaw and premium. 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 and 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 and 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 a iPhone app. I would probably practice my backflip. See if I could do a backflip if that happened. Like that would be so awesome. So good. Yeah, it would be so good.

That and JavaScript frontend, like Python, PyScript frontends. Let's go. I'm 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 frontend stuff, you can actually interact with JavaScript directly rather than Pyodide.

indirectly a little bit more clearly and most importantly there's slight variations and how you do this in micropython and pyodide which means you can't use interoperable code between the two and pyodide, py script 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. 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 McCougan 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 it 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 a getter and setter. So if those types don't match, your type checker is not going to like it.

it and so he walks through a and i'm like well why why would you want different types for your and he walks through a um a padding dimension example which is i think i mean he's doing textual so a decent um decent example of he wanted to be able to just have uh 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 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 basically one value, two values, or just an integer, a tuple events of just two values, or you can provide four. And all of this should just work. And it does with Python. 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 he said, I could make it like type check better, but just like kind of destroy the user experience. But instead, he provides, instead of doing properties, so he just like rips out the idea of the property. In the first example, he's using the property, the decorator.

But he uses what he calls a descriptor, which is, I don't know if this is a real thing. 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, yeah.

That's the your descriptor class. And he uses that instead of instead of a property. And that is all it takes to to be able to make it work without without pipe AI 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-- 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 you've got these different tooling, and they all have a slight variation of like, mm, that's fine, or actually, no, that's not fine.

And we've got tie and you've mentioned pirate pyre fly coming as well, which is 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, and I have like, you know, like PyTouch check is now type has type hints around it and that's helpful, but it's a little bit of a quirky thing. And, and it doesn't,

it works fine on my pie, but it doesn't work on some, some of the others. And I've had, I write or something. Yeah. Yeah. About that. And I'm like, well, use my pie. I don't know, but you can't really, if, if it's a dependent library, you really want to use that for everything. So yeah, exactly. It's, it is, it is a mess. I've had some stuff like that. It's like, this thing doesn't work right on pirate. 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...

I wonder if that's something now that I probably, for libraries, we should be testing against multiple type checkers and not just one. Probably. It's super annoying, but yeah, probably. And then here's the most annoying part of it was the, 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 doesn't, 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, but... Mm-hmm.

- Mm-hmm, until you get an issue about it. Now, I appreciate that people found the issues, 'cause 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 Pyrite, but 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, the at setter dot variable name of a thing I've defined before. It's just so chunky, weird and like.

The typing is messed. Like if you look at the way C sharp does this, I'd probably other languages as well. It is so nice. You just public in property name. You have a getter and you have a setter right in there. I,

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 Sharp does, but something where they go together, they're obvious, you're not defining it twice, et cetera, et cetera, et cetera. It would 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 RStudio 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've 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, a dashboard, Plotly, interactive plots, fast API, Quarto, just connect it to there and

And they'll, 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. You just set it up, pause it, connect, got it going. So you can focus on your data science work and leverage your skillset 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 finally,

Just let Connect handle it, 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 PositConnect. Just visit pythonbytes.fm slash connect and get a three month free trial and see if it's a good fit. That's pythonbytes.fm slash connect. The link is in your podcast player show notes right at the top. Thank you for Posit for supporting Python Bytes. Yes, thank you. And a rewrite. Yeah.

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 Complexipy?

It's an extremely fast Python. It's a, I'm quoting here, an extremely past fast Python library to calculate the cognitive complexity of Python files. And it's written in rust. Just like you said, a lot of pipey stuff going up. That's a written in rust lately or written parts of it in rust. Um, it looks like 45% rest 23 Python. Anyway, the, uh, um,

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 formula,

I don't know the McCabe test around it, but it would just sort of, I don't, I never used McCabe directly. I just used it with flake eight. And now actually I'm using it with, with rough. Cause you can, which is kind of cool. I just recently realized this, that you can pass in, pass in the rule C nine Oh one, and you can check, do a complexity check on with rough 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 Sonar Cube, if anybody's familiar with that. It's static analysis stuff.

And I read the white paper and I skimmed it really, but it's a things it's, it's similar. So 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 but really looking at everything. So there's, there's a,

you know, you know, more loops, more structs, more everything. It's really a different, a little bit different take looking at really the maintainability. So there's a discussion in the white paper talking about that, that cyclobatic complexity was intended to make it to measure how testable and maintainable and the testable part comes from that, 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, but the authors of the white paper don't really believe that that it does 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 Iran both the the rough version of the McCabe test, and, and then this against my code.

Some of my code. And it came up with the same hotspots. 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 a 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 you like you pointed at a directory, and it'll list out everything, you can just tell it to just let 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 need

might need refactor 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, glad you pointed out. Christian out in the audience says great radon, radon is really slow. So cognitive complexity is the last thing preventing me from dropping flex eight, super like eight. Very cool. And I used to, I mean, when I say used to, I'm talking like 25 years ago, use this tool called Code Rush, which was amazing. I've still not seen anything as great for an editor at

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, your things that you, and you could be like, or you can run an analysis to say, these are the seven that are like over some sort of threshold. You said 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 that 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 I'll have to check it out. Yeah, does that just output it in the terminal, or does it actually overlay it like CodeLens? Yeah, that'd 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. Yeah.

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 it for me? What is, 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 Jupyter lab 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. It's just like, what? Okay, so Juvio allows you to basically run a kernel

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, if,

ephemeral virtual environment using UV. All of that I'm loving. How cool is that? So you can 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.

That is awesome. Yeah, it's also get friendly. So notebooks are converted on the fly to script style format, which is where you have the hash and 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. That's how you basically set it up. That reminds me of 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 and 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, 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 and pythons managed by UV speaks to me. I like it. Yeah. Oh, and Pat Decker suggests, again, alias py equals uv run.

Perfect. So you can just pie your, this type of pie. Doesn't work on Windows because there's already a pie, but alias itself doesn't work. So you know what? You have to create a batch file or something. I don't know. I've been using bash on Windows for decades, but yeah. 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 these out. But I have some great interviews already in the like ready. They just need edited. So stay tuned. There will be great stuff out. I just interviewed Sebastian Ramirez recently, and there's some some great interviews coming up. So stick with it.

be patient with me, please. Anyway, we'll be back. Um, but I do, I never let Python bites drop. It's weekly, no matter what, because of Michael. Python bites is awesome. Yeah. Do you have any extras? Uh,

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 the North America, I believe. The TourTech 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 on.

Come say hi or go riding together or something like that. All right. It's in plain Washington. It's not fancy Washington. No, it's like, this is like basic camping. What can you put on your motorcycle and then camp from it for four days? Okay. It's going to be very plain. It's actually right by 11 North, which I think is kind of a cool place. Cool. Oh yeah. That's it for my extra. So yeah,

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. I think we talked about the vibe coding one one time. Yeah. Remember that? Senior engineer tries vibe coding. That was so good. So he's back with...

The interview with the 0.1X, you people have heard the 10X engineer, like the 0.1X engineer. Full, I found the full episode. The 10th X. What do you think of it? This was hilarious. 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. Yeah. 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 videos.

AI content, not just images, but it's images, voice, movie, it's insane. And so I've stumbled across this. Now, 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 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 the day of the, like in the day of the life of like Bigfoot and so on. And I'll link to a couple of these.

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, you know, and it's, if you haven't seen this, I think you'll be surprised if you there's the, 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 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 to watch these. Yeah, exactly. Yeah, please.

We'll have nothing. We'll have 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 not, it's just fairly time consuming to put these things together. But now it is in the realm of like somebody that just, 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, right? That's all I can say. Well, in eight second clips, I mean, pay attention to the last action movie you ever 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 vlogs.

I'm really warning you, don't do it on your regular account. Yeah. All right. Well, that's it for today. 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 have more. I just want to encourage people who are watching the YouTube channel here, either live or in person.

in the future at some point, please subscribe to the channel, like the video, help us spread the word. Yeah, I guess we don't like to call to action too much, but like the videos, that would be great. But I also, 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 more. You should check out this podcast. It's staying up on Python on Easy Mode.

Got a car ride or you're mowing the lawn or you're doing the dishes, hit play. It's all good. Get to later. Bye.