Python Bytes - #500 Episode 500!

Episode Date: October 14, 2026

Topics covered in this episode: A quick chat with Brian looking back Extras Joke Watch on YouTube About the show Brian #1: A quick chat with Brian looking back Nick #2: Jev and the Case for Boring ML Vincent Warmerdam from marimo benchmarked Jev, a new "System 1" decision model from TypeSafe AI. In his video It handles classification without the latency or token cost of generative LLMs, which raises a practical question for data teams: where does this fit alongside traditional machine learning? He tested Jev against classical machine learning models to see if its speed and accuracy hold up on real-world datasets. General LLMs work well for reasoning, but generating full token streams just to assign a category adds unnecessary latency and cloud cost. Jev avoids generation entirely by evaluating the input and returning only the decision, which makes it much faster and cheaper than standard chat APIs. It consistently outperformed eight-shot sentence transformer setups like SetFit out of the box, especially on datasets with dozens of target categories. Traditional models like logistic regression still matter because they run in single-digit milliseconds on basic CPUs, cost nothing per inference, and keep private data within your own network. You cannot fine-tune Jev directly, so standard models remain the better choice when your data contains internal company acronyms, product names, or domain slang. The most practical approach is using Jev to bootstrap initial labels or audit bad training data, then training a small model you can own and run locally. Brett #3: Announcing the 2026 Python Packaging Council Election Results! The inaugural Python packaging council (PPC) has been elected and started meeting! Introduced via PEP 772 5 members elected Top 2 vote-getters get two-year terms Other 3 get one-year terms All members will get two-year terms going forward, staggering the elections There have been 4 meetings far as well as a meeting with the SC Initial meeting notes As the inaugural packaging council still working out basic logistics like how to take notes Also working out what the packaging council should do as PEP 772 explicitly says packaging.python.org falls under the PPC, but otherwise tries not to dictate what the PPC is in charge of Calvin #4: Parsing JSON at tens of gigabytes per second in Python Daniel Lemire (Oct 12) benchmarks fastsimdjson 0.6.0, a Python binding for simdjson on PyPI, repo at simdjson/fastpysimdjson. Its map_many function runs a callback per JSON line across N threads. Workload: Eight hours of GH Archive data, 7.6 GB and 2.2M events. The task counts event types and looks up the target repo's language for each opened PR, and it only touches a few fields per event. Lazy trick: With lazy=True, the whole event is parsed but Python objects are created only for the fields you access. The idea comes from Tyler Kennedy's pysimdjson. Single core: stdlib json gets 0.18 GB/s (about 42 s for the whole set), orjson 0.42, msgspec 1.29, fastsimdjson lazy 2.13 (3.6 s). 64 cores: stdlib json gets 3.17 GB/s, msgspec 24.6, fastsimdjson eager 29.8, and fastsimdjson lazy 65.7. That's the full 7.6 GB in about 0.12 s, roughly 31x its own single-core speed. Requires free-threading: It ran on Python 3.14.6 free-threaded (3.14t) on a 64-core dual-Xeon box. Grain of salt: It's one machine and one dataset. It's an embarrassingly parallel job with per-thread counters. The lazy win only shows up when you read a few fields from big objects. msgspec was handed a schema declaring only the needed fields. The post itself doesn't say whether this generalizes. Michael #5: Grinberg's annual benchmark says 3.15 is flat, but the JIT finally pays off Miguel Grinberg ran his annual release-eve benchmark, comparing Python 3.15.0rc3 against every interpreter back to 3.10, plus PyPy, Node.js, and Rust, using his usual two CPU-bound programs: recursive Fibonacci and bubble sort. The standard 3.15 interpreter lands within noise of 3.14 on his workloads, while the experimental JIT build is roughly 20 to 28 percent faster and finally beats the standard interpreter, which has not happened before. The free-threaded build holds up well in the 4-thread tests. He is candid that the workloads are just Fibonacci and bubble sort, and the official release lands days after his measurements. It is an independent, workload-based counterpoint to the official 7-8 percent JIT geometric-mean claim, from a series with real trend data back to 3.10. He did the same exercise for 3.12, 3.13, and 3.14, so there is a multi-year trend line to draw on. Methodology is two hand-picked CPU-bound programs, recursive Fibonacci plus bubble sort, not a pyperformance-style suite, which cuts both ways. PyPy 3.12 still runs circles around every CPython in the single-threaded tests, and Rust is about 77x faster on Fibonacci. The JIT gain is real in these numbers, but the JIT stays experimental, so he will not use it in production yet. Free-threaded fibo at 4 threads ran about 4.5x faster than the standard interpreter with the GIL. His verdict: not worth rushing an upgrade for speed alone, though lazy imports may tempt production projects. Carol #6: Transparent and trusted AI Our Way - Satyrn AI Paul Everitt, Georgi Ker and I were discussing Python, its community and AI back in March at the JetBrains PyTV event. Python is the foundational language for data science and AI tools. We wanted something that reflects the Python community's strengths: language and learning. Mission: https://satyrn.ai/mission/ Python 3.15 trained model is on Hugging Face After Paul's Europython keynote, he asked for folks to join the community (think of it as a collective of individuals putting their talents together We used some of the organizational tips from Jupyter and JupyterHub's early days on scaling community and emphasizing leveling up individuals Paul will be keynoting in Africa and sharing progress made by a team of dedicated volunteers Putting AI tools and knowledge in the hands of Pythonistas makes good sense and over time will benefit people (A theme that I have spoken about since PyCon 2023 and most recently PyCon JP 2026 Extras Michael: Adobe Creative Suite was mostly cloned in Rust ArtCraft released seven free, open-source desktop apps that mirror the Adobe lineup: PhotoCraft for Photoshop, VectorCraft, FilmCraft, LightCraft, PrintCraft, EffectCraft, and DesignCraft. Everything is written from scratch in Rust with WebAssembly builds for the browser, and developer Brandon Thomas says the apps are AI-built clean-room reimplementations, a claim Ars Technica covered alongside the predictable skepticism. The clean-room story matters: reimplementing Adobe from public specs and behavior with AI is legally defensible, and building the apps for agents to drive, not just humans, is a genuinely different design bet. PhotoCraft already shows real depth: layers, masks, adjustment layers, layer styles, and real PSD support, with over 1,700 tests and dual CPU and GPU compositors tested against each other. The agent story: an MCP server and JSON control protocol let an agent headless-edit documents or drive the live app, useful for bulk edits and first drafts. Tradeoffs are real: reviewers call most of the apps super early alpha, and trade dress claims from Adobe remain a live legal risk even for clean-room code. Sustainability matters: the founder says token sales from their ArtCraft AI model fund the work so it does not become an orphaned small-team project. What happens when open-source alternatives that once took years of community work can be built by a model in weeks? Reminds me of the chardet story we covered awhile ago. The reason I put this topic here is I think it encapsulates a lot of what's happening in the industry for devs now. Building software has changed, creating is easy - sustaining is hard, owning an idea is more fleeting than before, Rust obviously, MCP and CLIs. It's just an interesting bridge from the first 500 episodes and the next 500 likely. Calvin: https://www.llmfit.org/) see what models can run on your hardware! uv 0.13.0 makes Python 3.15 the default! Nick: Black Python Devs: https://blackpythondevs.org/student-ambassador-program/100-campus-tour-campaign/ Brett: Python 3.15.0 final is out! Joke: Exceptional by Derrick Chambers Interviewer: It says here on your résumé that you’re an “exceptional Python developer.” Can you prove it? Me: Sure. Run any of my code. It raises exceptions a lot of the time.

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 500 recorded October 13th, 2026. I'm Michael Kennedy. And I'm Calvin and Nick Parker. I'm Nick Moore. I'm Brooke Cannon. I'm Carol willing and I sometimes pretend I'm Brett Cannon. And I have no problem with being Carol either.

So there you go. Everyone, thank you so much for being here for this special episode. Sign up to the newsletter, social links. All that kind of stuff is at the top of the show notes. So let's just go ahead and kick this off. We've got a really awesome, almost 10 years. I don't know if this is exactly 10 years or not, but almost 10 years. Certainly episode 500 is quite a thing.

So Python Bites has been around a long time. All of y'all have been here before in various ways. The one big missing component here, the person we're missing is Brian Ockin. But don't worry. Brian was supposed to be here. Something came up, couldn't make it. So Calvin and I had a quick chat with him before, and we'll splice that in. So are you going to be hearing that in just a little bit?

welcome everyone thank you for taking the time to celebrate this milestone calvin thanks for being here to keep it going love it i'm glad to be the new co-host and i'm excited for this crew for the 500 episode and congratulations to all of you for getting us all the way to here thanks for calling us old brett appreciate it no i really do pressure i'm just kidding man a person who's been doing python that probably the i think fish officially the longest baby on this call i don't know carol i can duke it out but uh 2 000 when i started using python oh all right calvin 11 wins. Go Calvin.

That's an accomplishment. When in 2000? I started in 2000 as well. So it would have been early 2000? It's probably like a February or March. You beat me. I started in fall. Okay.

Wow. All right. Wow. That's crazy. Now we've established the pecking order. I'm sure. I sit above rent for most things. I'm not in the Python world.

Amazing. Calvin, I was just thinking as we, I was getting ready for this show, we're on almost month four. if not pass it of you and I hosting the show together. It feels like we just started, but thanks for being here as well. It's been great. I really enjoyed jumping in, and this has been kind of a passion for me, a future dream that I thought would never come true, and here I am.

I love it. Thank you, Michael. Yeah, it's awesome to be here with you as well. And now, like I said before, Brian wasn't able to join us in real time, but Calvin and I got the chance to speak with him beforehand to make sure he was part of the show. Let's have that conversation with Brian. Oh, my goodness, it is Brian Ockinck,

and thank you for joining us for the 500 episode. Blast from the past. Brian Oggin. Yeah, man. It's definitely a blast from the past. It's good to have you back in the show. 500. That's a big number, man.

And a lot's happened since the, you know, you left. You published a book. I did. It's right there. Yes, it is. Lean TDD. We have the number one Lean TDD author of... For the Python Bites list.

And it may be the biggest new release of test-driven development book in August, of this year. I don't know. Yes, very, very renowned. No, honestly, it's a very good book. And you and I, we just got back from hanging out in San Francisco together of all the things. We ironically just randomly stayed at the same hotel for. Yeah, it was actually kind of surreal. We spent, so Michael and I live in Portland or near Portland, and we usually see each other at conferences somewhere else. You know what it is? It's so weird. I have so many friends like that. And it's because you don't have family, you don't have the kids, you don't have all this, you know, could just kind of hang out

and do whatever. The conferences are awesome. I think conferences are awesome. I mean, that's how I met most of you all is because of going to great Python conferences. Yeah, and Calvin, yeah, that icon party, man, it was the most epic party I've ever been to. So it was good. Which one? You're talking, you're talking about select city. That was a really good one. Yeah. The one that took over the, the top of the bit, the top of the top of the binawana. Yeah. No, it was a It was good. Plus, I met Lincoln his name, the Brown Bag guy. Oh, Chris Williams. Yeah. Chris Williams was there. I mean, we had Charlie Marsh there. We had Brett, actually, who's on the show, was there. It was really good. Yeah. Yeah. And all those, a lot of, a lot of people had just started their, like, startups that are going fantastic. Yeah. Yeah. That was the Rust Wave. We haven't really seen the AI Wave party yet, haven't. Yeah. It's the, no, the AI wave is waving people goodbye when they get laid on. off because of it. No.

Well, you know what? Seriously, though, we were just both in San Francisco. Were you blown away at how many billboards were about AI? That was weird. It was like going into like a sci-fi futuristic movie or something. It was crazy. Because there wasn't anything else. It took over the like, I'm not sure.

I mean, I'm glad there weren't like cigarette billboards and alcohol billboards and or like, you know, the dispensary billboards. Divorce lawyers. but having it all be like targeted towards stuff that just as I still think it's a small percentage um AI is changing a lot but it's um it is sort of it's a kind of a middle upper middle class and higher sort of a phenomenon I don't I don't know if it's affecting everybody really other than it's taken over your search window anyway um yeah I I had a airport I had a ride to the airport I don't know maybe 25 minutes or something like that I mean in San Francisco it could be three hours or it could be 10 minutes depending on the traffic. But it was, I think, I think,

I mean, it was full of billboards. I think literally every single billboard I saw, at least that I noticed, was some kind of, if not AI, AI adjacent. Or there's all these companies that are like, yeah, were the AI marked down editor. Like, you were just a markdown editor last year. Come on now. You know what mean? Like that kind of thing as well. I don't get why. Who are they trying to convince. Investors. I think they're trying to convince investors. Anyone who's involved in this hype right now is raising money. Yeah. I don't know. How does your framework desktop in the basement feel about this colony? He's fine.

He's right over here. He's on the standing desk over here. The local models are running just fine. Little hiccups. So I use it with Home Assistant in the house, which is another fine Python project that everyone should go check out. And you got a little confused this morning and thought that it couldn't control the home. Like I was using Quinn 38, 27B, the one that's kind of all over the news today.

and I just kind of forgot that it could actually control stuff. Maybe that's a good direction to go versus like take over all the things. But it does work. It works really well. Yeah, awesome. Yeah, we've got to get used to a non-deterministic world where like stuff just, it used to work yesterday. Now it doesn't necessarily work.

Well, what's nice is you can have a discussion. Like I've got the home assistant voice set up. And so you can actually talk back and forth with the little box on the desk. As opposed to kind of the, I don't know, I won't utter the Amazon version of that box because it'll start going off. But you can't really have a discussion with those boxes, but you can have a discussion with Quinn 3-8. Oh, really?

Yeah. You can go back and forth. I can interrupt it. It's all sitting on my desk with just the satellite one dev board, which is getting a 1.1 release, and their pre-orders are open now. So you're talking to it? I'm talking to it.

Talking to my home assistant. Okay. Do you have arguments? All local. All local. So it precedes like a prompt into the model. and it precedes all of the devices that are in your home that home assistant knows with a preference for a specific room you're in. So if I'm in the study and I've the home assistant voice boxes in the study, I've told it it's in the study, I can just say turn off the lights and it knows it's in the study.

There's lights in the study and it turns off the lights. Interesting. Yeah. That is clever. Here I'm back in the dark ages. I like go over to the wall and push a button. A wall. You could hurt your finger doing that.

Don't do that. Touch time. They're conveniently located though. I mean, it's designed well. So the place where I enter the room is where the switch is. It's kind of incredible. That's very thoughtful. It's kind of nice.

Yeah, I just utter it into the air. What happens when like the Wi-Fi goes down? Well, so it's on, that's on battery backup. And internet's not required. All the access points are PEOE. There's a big battery in the basement, you know, hooked up to the home assistant. It's all central. There's a battery up here on the framework.

So I can last. a couple hours without any Wi-Fi, internet, or power and still talk to my house. Okay. Nice. I talked to my house, too, but it just doesn't talk back. Mine can talk back. Hey, I wanted to say, just thank you for stepping in. So, I sort of just jumped out of Python Bites without letting people know.

And there was no hard feelings or anything. Michael and I are definitely still friends. He didn't kick me out. But it was this book, and also my day job is pretty. pretty exciting. So I just sort of wanted to do other stuff. I really enjoyed Python Bites, and I'm glad it's not stopped just because I've stopped. I really enjoyed doing it. You had a great run. I mean, how many episodes, 10 years nearly of Brian's voice in my earbuds, and now my turn on Python Bites, I'm like, oh, that's my voice. It was funny when I was watching at

Pai Bay, I was in the audience waiting for, so Michael Kennedy, I sat down right in. It, kind of entered late. Sorry about that, Michael. But sat down and he's up there and I said, oh, that guy's kind of famous. And the person sitting next to me turned around and said, yeah, you're kind of famous too, man. So I'm like, no, not like Michael famous. Thanks for coming to talk. And your talk on Lean TD was really, really good.

I think people really appreciated it as well. I'm waiting for that. So one of the fun things about it is I got to talk about my career. So I, well, I didn't get to. decided to. So the first few, like maybe five minutes of the talk are discussing my career in in tested measurement, the RF world. That was fun. Yeah, if you want Brian's full, um, full story leading up to Lean TDD, eventually the videos for those talks should be out. And I'll share and I do look forward to coming back for Python Bytes, uh, 1,000th episode as well. Nice.

Oh yeah. Yeah. We're going to have to start doing more than one episode, uh, uh, on the decade. No, I'm sure, honestly, it'll, it's very possible, which is very, very, insane, honestly. Let's wrap this part out, this section out with, just we can maybe each look back. Think back to an innocent time. AI was a thing we made fun of because it was bad. There was no COVID. None of this stuff. Back to 2016, 2017 when we started this. Like, what's something notable that you've, you all have seen change? I'll give you the final word. So Calvin, something from, from 2016, 17, that era that really stands out for you. Yeah. So anything from 2016, 2017?

team are in that time when you all started the podcast. I think the biggest thing that's changed for me has been packaging, way more sane. So I'm super excited about that. And the community is still here. Pycons still go strong, even though we had a few years in their weirdness around the world. And so I'm glad we're all still here. Yeah. Packaging has absolutely changed. It still has a little ways to go. Way better. Is it better? I'm still waiting for Python dash, build, dash, arm, my file someday. Right. A couple,

there's a lot of stuff, but of course, we don't really talk about Python 27 anymore, which is nice. It's just gone or, you know, hopefully. And we'll get comments that people are saying,

like, I still have to deal with it, man. I'm sorry if you still have to deal with it. The other thing, packaging is a huge thing. I was just, I did, I've been updating a Python plugin or Pytest plugin,

I test check recently. And the, the release, process is push a tag. And then this, it's because it's this, the server builds it and talks with IPI and does that. And I don't have to use twine anymore by myself or anything like that. And the package, like, package, I'll have to just, I guess I'm marrying in Calvin. The packaging system is something, it's so easy now that I don't think about it. Once I get it set up for a project, I just don't think about it. So. Yeah. And Knox and Talks and. Oh, I still. Hey, yeah, talks is great. I like

talks. We're just not left unsupervised. Unsupervised. Well, I was going to say, the thing that I was going to add is the two, two versus three wars and how many of us survived. But honestly, if you weren't around in that time or you weren't working in Python at the time, it was a long, drawn out period where it was not entirely clear that Python I was ever going to make it to Python 3, and then it would be permanently stuck in an older way. And it just, it was a, it was more shaky than I think people give it credit for me. And also, we just, we just, we just, just made a change that would have made the two to three transition easier. The making UTFA default, that should have been from the start.

Just say it would have been a lot easier. Yeah. So many cannot decode exceptions. Yeah, I was going to pick the two to three wars as well, but as a joke, of course. But honestly, that was a serious, serious thing. But I think I'll go for performance. Python has got a lot faster. The Python 310 Foundation and 311 especially made it course.

quite a bit faster and you know there's still continues today there was a lot of well python's too slow we can't choose this for our project because obviously we got to use go because that was the hot thing at the time before rust really kicked into gear because we need better async we need faster x y and z and i think it's it's come a long way one final thing uh the or at least for me the um is that uh pie test isn't considered niche anymore um it's uh pretty it's pretty obvious that people go with Pytest. You don't have to defend it anymore, which is cool. And there was a book that probably helped. Maybe. Yeah. Who knows? A couple of books. Well, I just want to take, before we wrap it up, Brian, just want to say, you know, thank you for 10 years of hard work. People from the outside,

like, oh, we just jump on for like 20 minutes or, no, sometimes an hour, then you get complaints. And it goes back to 20 minutes. No, you just jump on for a while and you have a quick chat. And there's a so much behind the scenes that takes a lot of work to put this show together and keep it flowing. Yeah. Yeah. Thanks for all the hard work. Oh, you bet. Thank you. And yeah, thank you for keeping it going. So I'll just throw out also that Python people is going to come back. So I am going to do the podcasting thing more again. Well, you know, let us know in the episodes. We'll shout it out in the extras as you know how it goes. So thanks a lot. See later.

Awesome. Thank you so much, Brian, for being here and being in the show. Now let's get back to our group celebration. All right. Let's jump straight into the items. And Nick, You have the probably most popular topic if you look at the derivative or second derivative of how fast it's got attention lately. Yeah. Tell us about this. This is crazy. Yeah.

If you have not heard about Jev, you have been living under a rock because it's the new kid in the block and it has made quite the presence, his presence known. It's been raving all over Twitter, X, Reddit. And what it is is a new type of AI model that is not like your usual LLM. The folks from TypeSafe AI, these are the creators of Jeff, call it a System 1 decision model. And so System 1, if you've read the book, Thinking Fast, Thinking Slow, they're like two different system types as System 1 and System 2. So Jev is like very focused on the System 1 type of inference.

And what this means is that you have, instead of generating text, like a Quinn model or a chat GPT model, instead, it makes decisions on either yes or no, offers, like, gives you score probabilities for a rank of choices, or it gives you, like, a score for, like, how much something is, like a range of, like a range score about how some, how much something is. So it's very interesting, and even though it sounds limited, the use cases have been quite insane. Vincent from Marimo did a video about it, and he was benchmarking it against traditional LLMs. Because I'm a data scientist working, and I work with a lot of ML models, and classification is one of the things that's given, depending on the situation, can be really hard, can be really simple. And here comes this Jev model that is like a general classifier. And so he benchmarked it against a couple of real-world datasets and beat all of them. In most cases, he beat all of them. He even brought like an interesting trick he learned called SetFit.

You should watch the video. He does a great explanation of it that allows you to train like very basic LLM models like Burtz or Quinn embedding models and uses it for classification, Jeff still does it better in terms of accuracy and so much cheaper. Now, the reason why I brought it up was because the use of Jeff, even though is really cheap, really fast, is really interesting. But there is another interesting point that Vincent made whereby in most companies, there's a lot of data that is unlabeled. And it is going to be more cost effective to train your own local model on your own proprietary data, then it is to use a general model, even if something as cheap and

like fast as Jev. So what you could do is to take the Jev model and help you create like more accurate data, like the more accurate data sets, get you more cleaner labels or... Is that kind of like the supervised learning, but use Jeb as the supervisor? Yeah, exactly. So you like, you take some of the general class and then you create a better data set so you can train supervised models. And this is how you, like, eke out a lot more performance and get better efficiency

on very specific tasks to your, like, business. So I don't know the topics I'm going to bring up. It's a really interesting video. Jev is a really interesting model. You guys should go check it out. I've seen all this excitement about Jev, and I'm like, I really want to have a use case for Jev. So I haven't had to use it, but I'm glad to hear that you have, and that's really cool.

What do the rest of you all think? Well, it's interesting that the number of classifier models that other labs are coming out with now. A lot of them are taking Quinn and fine-tuning it to be a classifier. I think Microsoft just announced that's the one they're deploying, which I kind of like because I don't know these type secret folks or type secure folks very well, but you're sending them all their data because there's no option to use it locally. Yeah. Yeah, I think it was kind of interesting because when I first heard about Jeff is like, what's the big deal? And I understand that I learned that all it did was, the very key thing was it does classification, right?

It's not an open-ended write-me-this code is like, answer this yes-no question or put these things in a bucket, right? And I think next point about like using that as a quick and dirty way to label some data so that you can do your own training model with like Psychet Learn, which I will always give a shout out to because it's still my wife's favorite Python library in the world. It is a great thing, right? because I think it's one of these things we're also starting to learn is using LLMs to help you build the automation for things is a better use of your time and money slash tokens than it is

to like ask the models to do the same thing over and over rather than like, yeah, let's use it to help get that like use second learn to actually do like full like I'm going to use the long term here. So I'm going to try to use the right term. But use I can learn to build a local model that you need to do the classification. Yeah. That'll be the fastest, cheapest, best reproducible way to do it. I think it's great that this is kind of helping push that narrative down more and more to more people. Yeah. It's so much more efficient to have like a model like Jeb or a local model than to have like

opus running your like home assistant, right? That's like very cost not inefficient. Cost efficient. Yeah. I mean, I think it seems like it would be something that could be used with like spacey when you're annotating parts of natural language. and I think there's some creative ways that, you know, you can get decision maybe on a first pass or something. And I'm looking forward to looking at some of the research.

Because I have heard there's a few others at the top of my head. I can't name them. But some former folks from DeepMind are doing something in the UK, I believe, as well. Yeah. The real feature here is speed. The fact that you can feed it just hundreds of thousands of rows and get answers in microseconds and mill, the seconds. Yeah. Yeah. That's not a normal AI sort of experience. Right. That's a big deal, though. It's a huge deal. All right. Awesome. I definitely think that's a good pick. Brett, tell us about this

new council. Yeah, I know. What the heck am I talking about? So for those you didn't hear, first two weeks of September, we had an election. I think this was covered on Python Bites for Python Packaging Council. It is the inaugural one. And it was all set up via PEP 772 and the elections happened. It was open to all PSF members who basically said they wanted to vote in it. And it happened. It ended on the 15th or 16th, probably depending on where you were on the planet. I ended up on it.

Prudun Getham ended up on it to all the stuff as well. Henry Schreiner and Ralph Gomer's. So we are all in this inaugural council. Purdue and I are on it for two years as the top vote-getters, and then Donald Henry and Ralph are going to be out for a year, and then going forward after that, all people are going to serve for two years. So interesting thing with this is it's the first one.

I will say we've already met four times, and actually already had to meet with the steering council, and a lot of it's been around logistics and how to organize ourselves. As any of you have had to start anything like this from scratch, it's about where are we going to keep our notes? Where are we going to let people reach us? and that kind of stuff. So we're still figuring things out.

The one thing I will say about this council is it is explicitly meant to be in charge of the Sanchezon specifications and the whole website in general for packaging up Python.org where you can go and read about all the specs, really into the kind of the Pi-Pi-Pi-Pa side of the world. But otherwise, PEP 772, which established this council, did not try to dictate what this council is going to do. So we are actually also currently talking about what do we want to see our function be, right?

Because we're under the opus of the PSF, hence why they ran the election. But we're trying to figure out how do we represent people, basically, right? Like, we represent specs, but we also want to somehow act as like the public point, I think, for, and I'm speaking for myself as generalizing for my fellow council members, basically it's kind of the public face of packaging in Python, right? Who can you go talk to to maybe get funding to make something better? or if we need to go talk to like integrators, like the links distros or Kond or anyone else

who integrates Python and a bunch of other stuff. Who can you go talk to to get some answers, get some questions answered or kind of talk to them to figure out what they need and all that stuff. Kind of similar to what the SC does around the language, but obviously specifically about packaging. And probably honestly, I'm going to guess a little bit of our workflow as well, because that doesn't fall,

basically stuff that doesn't fall under the language that way. But yeah, it was just basically I noticed admin and also, I figured I'd bring that up. And yeah, as I said, we've just getting going. We have an issue director on GitHub. We haven't made public yet because we're just getting our initial notes and stuff set up. But we're going to try to be as transparent as possible. So like we're planning to keep our meeting notes up there and keep talking of what we're going to talk about, what's on deck and all that.

And be accessible. Discuss the Python. org is where a lot of the packaging discussions happen. So you can find us there. And yeah, we're going going. But we have high hopes that we can hopefully up. throughput a bit on stuff because poor Paul Moore used to be the vanilla dictator for packaging now gives a bit of a break and hopefully spreading across the five of us will sort of some things a bit

and we can keep doing stuff such as talking about the wheel variants and I know there's Will Next been proposed and a whole bunch of kind of big projects that hopefully we can help go forward and make action for Python just better for everybody. Well because packaging has always been such a simple and easy story in the Python world. So simple and so easy. I know. C and Fortune and all these other languages made it so easy for us to integrate that I don't know why anyone's ever complained. I'm glad you all are here.

I will say like the journey of Python packaging from like cheese to eggs to wheels, it's actually been pretty amazing to see the evolution of Python packaging. So thanks, Brett, for like championing that. I feel like you care so much about that. And that's why it's still you and others are making it such a pleasant, at least more pleasant experience. Well, thank you. I appreciate the kind of words.

Yeah, it has been a bit of a journey for packaging and Python in general, right? Like the creation of the Chi Shop slash Python Packaging Index because people were too worried we'd upset managers if we called it the Chi Shop. FYI if you go to a 4-04, it still links to the Chi-shop sketch on YouTube for Monty Python for a reason. I'm glad that's still there because I will be, of an age, I will still call it the cheese shop. Yeah, you got to do it on Pi Pi, though.

Oh, a Pi Pi Pi, okay. Yeah, sorry if I said Python. That was my mistake. No, no. Yes, there it is. There you go. And now, it's something completely different. But yeah, it's been a journey, right?

And it's been very driven by the community. And to be frank, very much driven by volunteers. So it's moved at the space, the speed of people having time to help. But it's been progressing forward. And it's something I think everyone cares about. And as I kind of joked, doing the best we can in the face of Python being the glue language of the internet means we have to integrate with some languages who do not really have their up together in terms of packaging themselves. And so how do we work around that? Right.

Like we can go to the C community or C++ or any of these other compiled languages and are like, well, hey, how do you package? Like, oh, shell script. Oh, okay, great. So how do we integrate with that, right? So it's been quite the journey. And I would like to think we've gotten into a point where the ergonomics. are good and it's not painful anymore. But I think there's some opportunities for it to be better and definitely faster.

And obviously the work's not done. Yeah. I mean, it's been, I mean, just the council itself, it's been a multi-year journey just to get the PEP approved and written. And, you know, it was great to see the number of folks that ran for the packaging council. and really pleased by the people that were elected or chosen. I think it's a really great cross-section of historical knowledge, scientific knowledge, you know, across a number of different tools. And, you know, having Brett, having been part of the steering council when we did the inaugural steering council,

bootstrapping something like this, there's some knowledge in there. So that's awesome. But one of the things I'm super happy about is having more emphasis on the standards. And there's going to be different tool implementations, and that's great. I would love to see us get more of a focus on the consumers of packages and people who are using our packages on a day-to-day and making that more pleasant, like when you're using a GPU and other things because the landscape has changed. So thank you, Brett. for continuing to serve us. Yeah.

Great welcome. You have this legacy of launching councils, so that's very cool. I feel like it seemed like packaging was kind of solved, and then UV came along. We're like, well, now it's really solved. But then we also have AI, which means Kuda and all the crazy stuff that Wheel Next is trying to solve. And we've got the brand new pep that got accepted for Inscriptin and WebAssembly, which is a whole other angle. And so I don't feel like it's solved for sure. Well, and Pixie has done a great job, too, in the scientific community.

So, I mean, I think tools are kind of reflecting their users, and I think the standards are what makes that possible. So it's great to see more domains being represented within packaging. A question, Brett, is the council going to be consulting or working with our security developer in residence? Because of, like, as you know, like, we have all these, we have more. TVs being issued, especially on talking packaging. Yeah, so yeah, there's Seth Michael Larson, who's the security developer in residence for Python itself. There's Michael Fiedler who works on PiPI directly.

And yeah, pretty much everyone on the council either knows either of them directly personally, or because we're working under the PSF in a way, we know we can always just ask, like, hey, can we talk to Mike about something or whatever? But like, I message Mike and Seth directly about stuff. So it's definitely there. And for instance, I will say, like, part of my platform for running was on secure supply

chain, right? So I will say I personally interested slash invested in trying to see that improve. So security and how packaging plays into that is definitely going to rethink. Now, I will say, IPI does not report to us or vice versa. So it's very much going to be a collaboration. But we are definitely aware that it is something that we want to work with Pi Pi, to make sure that anything we do will work well for them and everyone else in the ecosystem, right? Because as Carol pointed out, we have a pretty good, I think, breadth of coverage for the very broad community that we have in Python on this council to make sure that all corners,

whether it's scripting web, data science, or an LLM, you name it. I think someone on this council has a connection to somebody to make sure that we cover all the bases. And that includes security. And it's definitely something we have top of mind to make sure that we address. So, yeah. That's a good question, yes. The security side of any sort of packaging is definitely so front and center these days. But you know what else is?

Many, many, harzing many things. Speed, Michael. Speed is the feature. We've talked about this before. And it's interesting, Nick had brought up Jev. We brought up the fact, like, speed is the feature for, like, a lot of the astral tools, like Ralph and UV. But most folks don't think of Python as being fast at parsing JSON.

This article here is a blog post from Daniel Lemire. He benchmarks a new wrapper around SIMD JSON, which is a C++ library I've never used. But he wrote a fast SIMD JSON wrapper around it and actually demonstrates parsing tens of gigabytes of JSON per second in Python. Now, there's a trick, obviously. Doing things in async, you know, is always not necessarily straightforward.

doing things threading is obviously never straightforward. Free threading brings a new wrinkle to all this, and a lot of folks have probably not tried out the free threading capabilities of Python 314 and now 315. This is actually a really good example, or at least a toy use case where, boy, does it make a big difference. So he goes through, he's got a dual Xeon 64 core machine, so he's actually able to take that free threading

and spread this workload across 64 different cores simultaneously, This is a GitHub archive snapshot of, I think, what, eight hours of GitHub data, which turns out to be about 7.6 gigabytes of JSON decompressed. 2.2 million events runs it through. The very first one he did was basically a non-threaded, non, it's like single-threaded version of this. So if you are looking at the standard JSON library, it only basically takes about 42 seconds to parse the whole set, which are basically New Line Return, JSON messages.

for every poll request that has happened in GitHub. So you can see here 0.18 gigabytes per second of throughput. The wrapper, he did is the same thing for OR JSON Fast-SemD JSON Map Mini, which is another approach you took, and then the lazy views, which is basically don't actually construct the dictionaries until I asked for them version of this. That got the 2.13 gigabytes per second, so that's obviously not as fast as tens of gigabytes per second.

Then moving into free threading. you open up and start using all 64 cores, and still in one process, one Python process, 64 cores on free threading, 65.7 gigabytes per second of reading in that JSON file. So I think you could see some magic here if you combined a large JSON workload with tools like Jev,

where you wanted to do some real-time processing and pull back the results as fast as possible. This is a very valid use case for this, but it's only one of many. The other bit here, He uses that there's a lazy trick in here, which I mentioned, which he doesn't instantiate the dictionaries until they're asked for. But in many cases, that may be useful. You may only want to filter or pull back portions of the data and not the whole dataset.

Because, for example, in this use case, I think each message is about 3K inside that data set. So fairly large object each time. Let's see here. So, yeah, basically a 31 times speed up over single chord regular speed, which is pretty incredible. It's also a simple, you kind of got to take this with a little bit of grain of salt. It's a simple use case. But if you've got the work that looks kind of like this, you may want to check out, he's what the maintainer of this wrapper around the SimD JSON library itself.

The benchmarks, he links to them in the code. So in that blog post, you'll see the code used in the blog post. Here's all the, if you wanted to reproduce this yourself on your own hardware and see how that goes. And it's available on IPI as fast. SEMD JSON. Actually, there's a new release since I looked at this an hour ago. So very active work going into this. I think it's getting a little bit of attention out there in the internet's.

I'm impressed. That's pretty awesome. And kind of not explored free threading much because I don't have this kind of a workload. But boy, does that make a great argument for Python is not slow. Once we got unleashed upon all the cores. Yeah. I mean, there's an old saying in the community, right? Python's fast enough.

Yeah. obviously it is and prototype it. And if it's not fast enough, then you start to look at what you have to do to speed up. And I think free threading adds a new wrinkle to it. Because originally it was always the answer. Yeah. Make sure you're using the proper data structure and algorithms, right? That usually got people most of the way.

And then at the end, you'd throw in that extra wrapper. Pretty much it would have been in like C or C++. Nowadays, probably rust. Probably rest. I think free threading throws an annul, well, can you go multi-threaded and get a win that way? Right. And because, I mean, you want to make sure you go down the ladder of complexity, right? And the shortest one is right data structures, right out with them, then it's throwing free threading.

Then you start talking about whether or not you want to go all the way out to a whole other language. Yeah, because each step gets progressively more difficult to triage and debug. Exactly. But I think that's a good point. I mean, Galvin, it's like, I think this is what's going to start happening. People are going to start using free threading, especially in the libraries where you directly don't have the main team, or manage the complexity and it will take care of it for you, in which case, I think things start to open up a bit under these U-free threading builds.

And I.O. was always a big one, right? How could we massively split apart a file, the giant file, and do something fast with it with Python? So these benchmarks, I'll also note, this was post-reading it into memory and then doing the processing is when the timing started. So it was all in memory and then processed. So there was no I.O. from disk involved in those benchmarks. Is there a similar library in Rust that maybe got compared to this?

Because it seems pretty cool, but it seems like a natural mention would be to do something similar in Rust. Oh, our JSON might be Rust. That was in part of it. It was in the second part. It was in the second part. They'd benchmarked it. This one is C++. Right.

Yeah. It's only a matter of days, right? Then this will be Rust. Yeah. I just tell my agent to go port it right now. Yeah, like, I'm sure if someone's wrapped, maybe or Jason's a rap or around Surday or something, because I know Joey's the big one. Orman just wrote, Armand Ronecker just released a new, a new alternative to Surday for very specific reasons. Yeah.

We're talking tens of gigabytes per second. Yeah. If you have those kind of problems, I'd love to talk to you, actually, because that sounds pretty cool. Very cool. I am pretty sure that it ORJN is rest. I think it is. It's 55% Python, 44% rest. It could be written in shell.

I don't know. The core, it could be like the tight loop could be in shell. It's 1% shell, but unlikely. I mean, that's how we used to distribute installers, was executable compressed archives that would look like a shell script. You just, you know, S.H. Pass the script. That's funny.

All right. Well, let's skip on to something totally different and talk about speed. Okay. Speed sounds great. Let's do it, Michael. Let's do it. Speed. So I want to come back to a former fellow Portlander, Miguel Greenberg, who's now, I believe,

in Ireland, Scotland, one of those two places, unless he's moved again. But he has a yearly Python performance benchmark that he puts out. So I thought, hey, it's kind of 315 week, if you count a seven-day rolling window instead of a calendar week. So we just had Python 315 come out, and he said it's time again for this. So I thought, you know what, let's have a look and just talk real quick about it. This one will be pretty short. It's got some interesting things.

It's not a super complex benchmark, so keep that in mind. But it does involve all bunch of versions, all the, hold on, even one of the unsupported older 310s. I don't know, 310 sounds still pretty new to me, but it's not. And Pi Pi, the Jit compiled version or Jit running version for Jit. And Node and Rust. It also says, let's take the regular C Python, the one with the experimental Jit, and the one with free threading. and then do all those comparisons. So let's look through.

It says, hey, we're just going to do a single-threaded Fibonacci type of pretty big Fibonacci, depending on how you write it, I suppose, 40 numbers. Fibinacci gets big fast, but you can memoize it and stuff, then it's a lot quicker. But I imagine this is trying to make it hard, right? Well, yeah, because it takes 15 seconds to answer the question on Python 310. So there's a bunch of charts. You can go look at the article. But if you think about performance of even 310, which had some of that faster C-Python

work done to it, it's 44% as fast as today's Python. So we've gotten that 56% faster. That's a significant improvement, even just for this sort of straightforward stuff. And there's a lot of things that are not factored in here. But then 311 was 1.7 times faster. You'll see that 311 and I think 314 are the two that make really big jumps a lot of the times here. So we've got 311, which is 1.7 times faster. and then the jump from 13, sorry, from 14 to 15, is only 3% faster. So not dramatically faster, but that's for this particular benchmark. There's other areas where it would be dramatically faster. And Pipe I 312, 5.5 times as fast.

Node, not as fast, but almost five times faster. And Rust, you know, just a little 77 times faster. I don't know, is this, I'll pull up the graph for you all. Quick thoughts before I go on to the next one. Anyone have thoughts? It still amazes me how Pi Pi consistently is, at least with these kinds of workloads, that showcases how performance it is. I know.

I always think I should really check this out. But I think the challenge is, then you want to go and import some library and it's incompatible by pie. And you're like, well, it goes from pretty, you know, five times faster to impossible and doesn't run. Like, oh, I'm not doing that, you know? Yeah. I do remember announcements with the latest release of Pi Pi Pi, that they're trying to,

to interface better with the C-Python EBI so that external libraries can just work in Pi-Pi. So that's an exciting news, but still, it's so amazing. What surprises me is nodes still being faster than Python. And I really, I have respect for TypeScript and JavaScript, but still, it still amazes me. It just makes me realize how much engineering I went to the V8 engine for Node.

It's amazing. It's decades of fully funded full team support versus Python, which, as Michael alluded to, right, just started maybe five, six years ago getting external funded, let's make it faster kind of performance stuff, right? And having people like meta and stuff start to bring stuff out from cinder and all that, right? Yeah. It's timelines. The other thing, though, is Michael's not shown us what the Jit numbers are with the experimental Jit.

So we'll also let's keep going. Let's keep going. Let's see. So, yeah, so we've got the next graph is we've got the standard, which is just what you get when you write Python. Then you've got the experimental jet, which you can turn on and the free threading. And this is single-threaded. So the free threading will not get better. But if it doesn't get worse, that's actually a huge improvement. And I think that's actually the biggest takeaway from this one is for this Fibonacci thing. It really doesn't that much of a difference. But Python 313, free threading was, I don't know, 20% slower. And now, free threading is actually just on par with regular C Python.

That's great. That's actually really good. And legit, as Brett points out, is like 20% faster. Yeah. I think Nick brought it up with like the compatibility. Like Pi Pi Pi had problems with importing some package you want to use. Now even the folks over Eve online are like, we're fast enough. Finally, let's just use the box Python.

And now we've got all the benefits of a giant library of ecosystem stuff. Exactly. Guess what? if we upgrade, let's go a little farther. So the next one was a sketchy path. Like they run such an experimental version of Python with their whole production. That is impressive.

Yeah, they stuck it out with Stackless for a long time. Long time. Long time. Until this year. Yeah, I just had them on Talk Python. So, yeah. All right, the next one is the Fibonacci with four threads. I think this gets pretty interesting. And it shows some really interesting

improvements. So we've got maybe if you run four threads to answer the Fibonauts, question compared to the others like Jit and standard. It's, I don't know, 25% time it takes, so that's four times faster, which if you add four threads and you get four times faster, wow, that's good. That's pretty good. People who haven't done multi-threading before,

you rarely get as many times improvement as you have CPUs you've added to it, right? There's a lot of coordination and other things. It is usually not linear, so. Yeah. This is actually pretty impressive. Just shows, like, for the longest time, It's actually kind of amazing that the language like Python that is impaired to like C or Java is not as fast,

was able to like garner the attention and love of so many people. And it was good enough for so many things. And now it's just like getting better and better now. It's actually quite remarkable. Absolutely. And also the JIT from 314 to 315 has gotten quite a bit better as well. So that's pretty interesting. What else?

What else we got to take away from here? I don't know. I would say. What was it, Brett who said, like, Python's, like, the second best choice for everything? I think that's not true anymore. Yeah. I don't think it's, I don't know.

There's certainly, your AI will probably always choose Python for certain projects. So he's really the first choice for everything. It's the first choice, yeah. Yeah, it's head-to-head on JavaScript. Or if you ask it to do a web thing, it probably does JavaScript if you don't guide it. But if you ask it to do any sort of data thing,

it's definitely doing Python. Yeah. Playwright is Python. Yeah. And to be fair to Pi Pi, right, they also have to keep up with the language, right? Intenters to change, hence why they're not on 314 or 315, while the built-in Jit just gets to piggyback on all the other work. Yeah, 100%. Jake is not a direct one-to-one that way because of that.

I also want to give a quick shout-out to some of the new things we got that are utterly untested here. This is I wrote one function, and in that one function, I ran it a bunch, sometimes with threads, sometimes with Jit, sometimes without. and it did a thing, right? What we don't see is we don't see the effect of lazy imports for really large applications or things that need super quick startup time and then they're gone like a CLI tool. We don't see the specialized and adaptive interpreter or even the JIT really get to kick in very much

because it's one or two functions. If you had 10,000 functions and it was a big, interesting application, those could also really start to make a difference. So the PSA, guys, your PSA is just upgrade your Python and you get performance, you know, for lunch. Oh, yeah, you will save money. Yeah, this is like legitimate free lunch. Yeah, no, I've told, I've had this discussion with people like when their managers don't

want to punt and put off upgrading the way to sell it to management is you will save money. Python will be faster. We'll use less memory, very likely as well. And thus, we will do more with less. So either we can scale higher or we can do the same things with less machines. So why not let us upgrade, please? So it's less of a pain because we only get to upgrade every two or four. four or five years and it's a big hassle.

It's like, no, upgrade, continuously, you'll keep getting these ones. Well, and your libraries get far quicker too. Like Napari using lazy imports is far better than on a version that can't use lazy imports. Yeah. And to quickly touch on what Michael said about the difficulty of judging performance on these micro benchmarks, right? This is one reason pie performance that is used for benchmarking C-Python and Python in general, tries to do benchmarks that are pulled from real-world code

and tries to be somewhat representative of actual work clothes to an extent while not taking hours and hours and hours to run. But another point that actually came up during the development 315 was the garbage collector, right? There was the incremental garbage collector put in. And we found out after people started to test with it that it actually didn't work in large, certain key workloads

and actually led to larger garbage collector pauses because I don't know how many people know this, but I think kind of has two garbage collectors, right? There's reference county for most stuff, but then we have a garbage collector to look for cycles because reference county can't handle cycles. And we've had a generational one for a long time. And incremental will get to less pauses

and hopefully better performance. But we found out the one we did actually did make things better for most people, but for certain people, the degenerate cases, like the really bad edge case ones, it was really slow and bad. So we actually had to roll up back. And Mark Shannon, for instance, currently has a proposal on how to kind of fix that.

But there's another point that it's really hard to measure unless people actually do this, which is why we will always say is a PSA from the Python dev team, please test the alphas in the betas and please, please, please at least test the release candidates on actual workloads to let us know where things may have gone wrong. Because if someone hadn't tested that and told us ahead of time, we would have shipped, and we actually did in 314, a garbage collector that needed to get rolled back, so it just didn't hit people really badly. Absolutely.

All right. Let's have Carol close it out. And our favorite topic, artificial intelligence and tools around it. So, you know, after being in the scientific ecosystem and data science and Jupiter ecosystem, you know, I've watched the evolution of, you know, machine learning, deep learning. We call AI now. And one of the things Paul Everett and I have been sort of talking over the past year about, hey, you know, so much of it is built on top of the work that we've done with Python, that it would be great to have a community benefit from it, not just large corporations steering the future of these tools. And so back in March, Georgie and Paul and I sat down and we started talking about, hey, how could we use more local capacity? How could we improve privacy, security, not leaking your data out to other services?

And Paul did a keynote back at Europython this year and introduced what we're calling Saturn. and really Saturn is looking at doing AI your way, which doesn't exclude the use of foundational models, but really emphasizes that there's a spectrum of ways that you can use large language models and agents to suit your particular workflow, because one size does not fit all. And from that, EuroPython keynote, he had a call to action, mostly for the Europe community,

but it has expanded out from that to kind of create a collective of individuals that are passionate about making it Python first and trying to make transparent and trusted AI. So I have kind of helped with the effort to kind of get the scaffolding in place and I'm happy to say that when 315 got released, there was also a model that, up on Hugging Face, that the Saturn team has trained on 315

that can run Oakley as well as on other things. And I think one of the key things is while we look at local first, we're also looking at trust first. And, you know, I could go back to my icon keynote back in 2023 when ChatGPT was still in beta. And one of the things that bothered me was, do I trust this large language model?

Do I trust how it was trained? Do I trust it, you know, to be unbiased? And while I think there's a lot of value in it, you still have to verify that it's doing what you think it's doing. And so I think having more options

where, you know, you don't always need a sledgehammer. Sometimes a hammer is good enough. And in this case, sometimes you can get a lot of good stuff the last six months out of local models. And, you know, the other key component is one of the keys that has made Python so successful is the language, the ecosystem of libraries, but also the huge commitment the community has about sharing learning materials, educating each other, spreading.

the knowledge. And if all Saturn did was provide these education and learning opportunities, which is a big part of what we're taking from Jupiter, Jupiter really helped accelerate sharing learning materials with folks. And, you know, there's a team around sharing educational content, both created by the team, as well as highlighting things that are available within the community. So it's still in the early stages, but I think there's good energy behind it, and I would love to see it grow more and more. And the reason we kind of started in Europe was we felt like the continent as a whole was more focused on security, privacy, and the impact of AI. So. Well, and being a European, like, how much do you want to say?

say our entire AI future hangs on large American tech companies or Chinese company. Maybe we should have some say in this, you know, something like that, right? Yeah. Well, I think, I mean, everybody should have a say in it. And I think, you know, some of the large companies, let's face it, they're beholden to their shareholders or investors to, you know, maximize profits, which doesn't always align with maximizing, you know, responsibility to the community. and ethics and other things. So, you know, I think alternatives are always good. It helps push

ecosystems forward. There's a lot of great stuff happening in bioscience and medical applications, particularly with rare diseases that the foundational models have been hugely helpful for. And so, you know, it's not one or the other. It's there's a spectrum of use cases. There should be a spectrum of tools and approaches. And as we navigate the understanding of it, sharing that becomes more and more important, which Ithon bytes and Python to me for sharing this on a regular basis. I love the fact there's two models. You've got the smaller Ornith model and then the other one based on that Quinn-38-27B powerhouse of a local model. I can't wait to try both of them. Yeah. I mean, it's pretty interesting. And there's like teams that

if you join the Discord that are working on these, how do you test and train? And, you know, so we're trying to be open by default and the information and the workflows. So, you know, definitely reach out. And yeah, it's got some good energy behind it. So are there other languages who are interested in participating? I don't know. I mean, there might be. I mean, I could see maybe Rust having some interest, but for now, we've kind of scoped it to Python and, you know, trying to train something specifically on Python 315 and the use cases that, you know, are new with 315 was something that is really interesting. But that's a really good question.

I wonder where my R fellows, like the Ler language are, that would be a good language to add under the Saturn. You know? Yeah. Yeah. I mean, in fact, POSIT is having sort of a hackathon, I think, in November that I'm going to. So that might be a great thing to kind of kick around the tires on. Yeah.

I want you to say personally, I've always had trouble running local AI models, mainly because sometimes it was always hard to know, like, which models could actually fit into my, like, consumer-grade hardware. And so navigating that has always been, like, not the fun. part. So I'm really looking forward to participating in this because I believe you guys would probably do a better job of discussing. These are the kind of right hardware you can run. This is the kind of models that can run on that hardware. This is some use cases, something as simple as categorizing or, you know, categorizing like your files to like helping you run a small,

like automated business or something like that. I'll be cool to see what you guys do. Well, and looping back to Nick, the start where you were talking about Merimo, we've actually used some of the Merimo hub and the GPU access there to do some of this training. So, you know, so it doesn't have to be just your local laptop. It can be, you know, something that is a little beefier. Yeah, and looking at the size of the models, they're not ginormous. No. You know, they're 10 billion parameters, 28 billion parameters. These are plausible on decent local machines.

Yeah. I mean, they definitely work on my GPU Linux box. You can get it to work on a Mac as well. It's a little bit, you know, a little bit harder. Got to submit it to the App Store, see if they approve it. I think you just have to get the MLX version of the training done so you can accelerate it on the Macs. Luckily, I've got a Linux box here too, so let's throw it on there.

Cool. Let us know. What did you find out? I just realized we're running out a planets to rename with a Y. I was not the nameer. That would be Paul. No, I'm just glad you snack this. After Jupiter, yeah, I mean,

Uranus is like one of the last ones with a U in it. And, you know, yeah. Then we're out. Yep, yep, yep, yeah. Good point, Brett. It's, Brett, it's going to be okay. We're going out to the Ork Cloud. Yeah, hey.

Yeah, S2, S7, Y, five. I know you thought that was a U, but now that's the Y one. It'll be good. It'll be good. All right. Well, this is. super interesting. And the naming, I guess, probably came off of Jupiter. I think when Paul was looking at it, yeah. I mean, definitely some of the things that Jupiter

did in terms of accelerating the community, he wanted, you know, that ability to share knowledge as well as build things. And, you know, the Y just seemed to make sense. Plus, there are other Saturns out there, Saturn AIs and whatnot. So, right. Why not? at the line. Yeah. Why not? Why not? Cool. Well, we're just about out of time, but I've got a couple of extras. I'm going to trim mine back. I know, Brett, you want to, there's some little release or something you wanted to talk about. What is this? I think you already talked about it. Yeah. 315.0 finals gone out. So 310 also hit EOL about a week prior, I think, two weeks prior? I can't remember. But yeah, after the unfortunately new tradition of having a third RC happened, um, finals out.

It's good. It's done. Obviously, we're already working on 3.15.1, which should hopefully come out. Typically, historically, we do it in November. But then we'll be on the usual two-month cadence for buckfish releases, but 15's out. A lot of great stuff in it, as I know, has been covered here. And download how you download your latest Python. I'm going to give a huge shout out to Trey Hunter, who has some really good what's new in 315 that, you know, web device. developers and folks that are maybe not as focused on some of the scientific benefits for some of the performance stuff. It's really well done. And Barry Warsaw's what's newt? If you want to do a dungeon crawler version of it. That was so awesome. I really enjoyed that. That is fun. It was really fun. Agreed. Yeah. I was thinking, could I make a visual version to overlay on that? I don't know. We'll see. I will not be doing that. But I do want to give a quick shout out to this as an extra. Have you all seen this? This is a

insane. This craft apps thing, I think the guy's name's Ben. I thought it hit the news. Yeah. Yeah. This guy had a big following out with Adobe over the subscription stuff, surprise, and said, well, you know what I'm going to do? I'm going to recreate Photoshop and I don't even know the apps that well. Let me see. I'm going to create Photoshop and I'm going to create Illustrator and a bunch of others, Lightroom, I don't know, a bunch of these acrobat and recreated them. Whole creative suite. Almost. It's missing audition. I can't wait for him to do audition. Let's go. Because I pay a ton of money to edit this podcast and other stuff with audition.

But yesterday, what I was like, I'm going to throw this up here as a thing they're talking about. There were 12. Today is 13. And I got to check real quick and see what the 13th is, but it has Microsoft Word, PowerPoint, and Excel. I got the little deck craft thing. I know it's not the same. But I opened up my talk that I gave with all the animations and gradients and stuff. for Pi Bay and it presented it just fine.

I don't know. I don't know that it edits as well. But anyway, I just, I think I wanted to give this a bit of a shout out because it's just, it's a weird time. And I think this, you know, looking back 10 years and looking forward 10 years, like, this is kind of an interesting thing at the inflection point. Well, and especially because they talked about how they tried to do this as clean room, right?

Like, there's no source score to look at here. They literally, I think, threw a model at it and said, here's the thing I want you to re-implement. re-implement it and yeah here's the UI here's its feature list to make that yeah go read the publicity material right just there's a lot of documentation about how Photoshop is supposed to work and if you give it access on the browser version where you can click through it and all that and crank away at it now I'd be kind of curious to how much their token budget was to pull that off very much curious high very high very high I'm sure uh because like cloud re-implemented a c compiler for

the Linux kernel and it cost them like how many hundreds of thousands of all for something. Wow. But so, not cheap, but it's still kind of cool that this is what you theoretically can do with appropriate budget with LLMs. You know, we talked about way back when, I mean, way back to March, we talked about a clean room rewrite and this was for Chardette. Yes.

And this was like a big to-do. And this was just a library. And now we're like, oh, let's just redo giant suites of apps, you know. Yeah, it's a very interesting world. we are entering for software. I think a lot of the companies that their software was their moats because they put so much investment to it

and the time would take to re-implemented with the tier competitors. But with AI, it's very interesting. So many could create a DaVinci resolve specific to their own podcasting editing needs and they don't need DaVinci Resolve or all the other ones that exist. So it's very interesting the era of personal software we're entering into.

Absolutely. Even if I never use this, I hope this puts pressure on companies to be more on top of things, newer versions, less expensive. Yeah, and I think for desktop software specifically, right, where you can have, where the actual desktop app gives the model something to work against to verify that it's working appropriately. and the outcomes are what you expect versus like,

I'm going to re-implement Slack or something. It's like, well, there's all back in on that one. That's way more complicated to try to recreate just based on how Slack looks on the front end. But for Photoshop, it's a desktop, right? Once again, if you've got the token budget, I can just turn away for quite a while. And eventually you just get probably a good enough fact similar.

I mean, or you just go use Gimp. I mean, how many features do you use of any given app? Probably 10%, right? If you just say I'm building it for me, yeah, like to the next point, just make it for you. Yeah. All right. Well, that's enough of this, but I do think it's a really bizarre and interesting thing that happened this week. Anyone else got something I want to shout out before we get to the joke?

I got a real-time update for Nick. Nick asked about how he could know what models he could run on his hardware. So I've got the screen up here for LLMFIT.org. And that's actually a TUI app that you can just load up. It detects your hardware. So Michael, if you wanted to put that up on the. screen. All right.

Give me something to search for. What I'm looking for? No, I shared it already. Oh, your screen. I see. My screen. Yeah.

There we go. So it detects your hardware. It loads up a whole bunch of models from different providers like Olam, Lama CPP, MLX, Docker runner models, LM studios. And we'll let you just filter for what models would run best and give its scores. So you can actually see where it might be better fits. I mean, be careful. You're downloading potentially random models from potentially random places.

So you probably want to. and I'll be careful which providers you pull those models in from. But it's a cool little tool to see what actually would perform. And is there a better version of that model that I'm already using that I should be using based on like quantization and the MLX optimization, all those kinds of pieces. So I thought that would be pretty cool for folks who want to know what model should I run. And the other one I got on my extras is my standard UV report. UVO.13 makes Python 3.15 the default.

So we keep it right up. Awesome. I've already run UV Python install 3.15 dash dash default. I'm good to go. Ooh, I need to do that. That way if you just type Python, it falls to that one rather than some other system. That's what I want. Or if you're on Windows, use the Pied Manager and just type Pye Manager and install 315. T, get the free threaded version. Brett, one-upping. All right. How about a joke? I give Steve the call out. He does all that, but I just know Windows has his own built-in manager that comes from Python at

work and see you to put a long time on effort. And it's my North Star dream to get that on every major tier one or maybe even tier two platforms for something someday. That would be awesome. Before we go on, you should give Nick a moment for at least one of his items on there. I think it's really important. Oh, okay. I didn't know you have some, Nick.

Go ahead. Oh, yeah. I just wanted to quickly call out Black Python devs wearing the t-shirt here right here. One of the amazing things that one of our members, Emmanuel, he's doing, is taking our Python dev student ambassadors and going across campuses in Africa. So this is like a really important initiative because if you guys don't know, the continent of Africa, so many countries and so many youths there, we want to promote Python for the next generation of Python developers. I think one of the CEOs of Anaconda says that he wants to, like he wants a world where the next

billion users are Python users, right? Something like that. Some of them, some of those users will be in Africa. So this is like an amazing campaign. And if you go to Black Python devs and the links will be in the show notes, you can support that initiative. And I'm going to also shout out with Black Python devs at Pai, Ohio. They did a leadership summit again. And I mean, looking at the leaders that Ithon Devs has over the years grown,

they have something really good going on and seeing those leaders emerge has been super rewarding and, you know, doing the good stuff. Awesome. Yeah, thank you. Yeah, thanks, Nick. Anything else.

All right, I got a quick short joke here for us. This comes to us from Derek Chambers, sent us in, said, I felt this way at some point. So theoretically, a person's applying for a job, trying to look good. The interviewer says, says here on your resume

that you're an exceptional Python developer. Can you prove it? Oh, sure, says the interviewee. Run any of my code. It raises exceptions a lot of the time. I'm a sucker for a good dad joke. I love it. I also feel like I just reached dad level

because I figured out the punchline before you got there. It's like, oh, wow, I finally level up my dad joke level as being an actual dad. There you go. I feel like not a new point is parenthood. That's right. Absolutely.

Well, Nick, Brett, Harold, thank you so much for being here. It's really nice that you came to celebrate this. And Calvin, thanks for help. Happy 500. Yeah, happy 500. And happy thank you to Brian too. Absolutely.

Thank you to Brian. Bye all.