Every year, the core developers of Python convene in person to focus on high-priority topics for CPython and beyond.
This year, they met at PyCon US 2025.
Those meetings are a closed door to keep focused and productive.
But we're lucky that Seth Michael Larson was in attendance and wrote up each topic presented and the reactions and feedback for each.
We'll be exploring this year's Language Summit with Seth.
It's quite insightful to where Python is going and the pressing matters the core devs are
giving their attention to.
This is Talk Python To Me, episode 514, recorded June 17th, 2025.
to unite. We started in pyramid cruising. Welcome to Talk Python To Me, a weekly podcast on Python.
This is your host, Michael Kennedy. Follow me on Mastodon where I'm @mkennedy and follow the
podcast using @talkpython, both accounts over at fosstodon.org and keep up with the show and
listen to over nine years of episodes at talkpython.fm. If you want to be part of our live episodes,
you can find the live streams over on YouTube. Subscribe to our YouTube channel over at
talkpython.fm/youtube and get notified about upcoming shows. This episode is brought to you
entirely by Sentry. It's a bit of an episode takeover, if you will. Sentry has two excellent
and exciting services to tell you about. Sear, your agentic AI debugging assistant, which takes
all the data already gathered by Sentry to help discover the problems and even propose fixes as
GitHub PRs. And the other is AI agent monitoring, which adds deep observability to your AI agents
in your app. If you're adding AI and LLM features to your Python apps, you'll want to know about AI
agent monitoring. I'll tell you more about both of these later in the episode. And remember,
however you happen to sign up for Sentry, if you do use our code, TALKPYTHON, one word, all caps,
let's get to the interview. Seth, welcome back to Talk Python. I mean, awesome to have you here.
Thank you for having me, Michael.
Yeah, it's always fun to have you on the show.
And you know what?
I don't even think we're going to talk that much about security this episode, are we?
Not too much.
No.
I mean, as I say that, I'm sure we're going to come up with something, right?
But the last couple of times I've had you on, it's because you're doing something with security
and Python, and it's always been very interesting.
It's true.
Yeah, no, I do a lot of security these days, but I do other things too.
be the eyes and ears of everyone who could not attend the language summit yeah so i was the
blogger again this year i got invited back they didn't uh they liked what i did last year so like
ah well we'll have this guy again why not right like yeah it was great i mean i love attending
the language summit blogging for it it's a it's a really unique way to contribute back to the to
python community it's a such a specific role so yeah it really is i think maybe we start there
Maybe we start with what is the Language Summit and why are there not just a bunch of videos online and why weren't there sessions that necessarily open sessions at PyCon, right?
It's kind of a special event.
Yeah, so the Language Summit is, historically, it is this event that happens every year before, right before PyCon US.
It's been hosted in other PyCons as well.
But nowadays it happens at PyCon US and it occurs kind of at the same time that like tutorials are happening.
So that's a day or two before the actual conference starts for most attendees where there's talks and all of that.
And basically what ends up happening is a bunch of core developers and triagers and some special guests all convene into one room for a full day of short talks followed by tons of discussion.
And the reason that it's like a closed session is like one, it's a logistical thing.
Like the room is only so big.
And I'm pretty sure the organizers know that if it was just like open session, it would be like, oh, we need to have this huge conference room of people.
And it's not really conducive to discussion because it is very fast moving, asking questions, getting answers and having people be able to exchange this information really quickly.
And so to offset the lack of openness, right, because not everyone can possibly attend that
wants to attend, what ends up happening is a blogger, someone who covers the actual event,
every single talk, every single discussion, all the questions, what gets discussed,
and then like the vibes of the room and like how people are feeling about topics.
That gets covered by a blogger, which this year was me, last year was also me, but then
the years prior has been like Alex Waygood covered the year prior to me starting.
So Alex taught me everything I need to know and what to expect and all of that.
Nice.
Yeah.
And I had you on last year and I had Alex on the year before, I believe.
So it's a bit of a tradition.
There we go.
Cool.
And yeah, also people should know it's a working session with the goal of not just presenting
ideas, but making decisions, trying to come to an agreement with the core devs and steering
council and maybe other councils, as we'll see all the councils.
Yeah.
Right.
No, it's lots of decision makers in there.
I feel like it tends to be a really great arena to kind of just get really quick feedback on either ideas or questions.
Because like it's really funny.
One of the talks happened not to get into too much detail right away.
But like one of the talks happened.
They're like, oh, we have this problem.
We really need more arm builders for GitHub CI for this specific reason.
And E Durbin, director of infrastructure at PSF, was in the room and they were just like, oh, I just bought more.
And it's like, oh, great.
Oh, that's awesome.
Quick feedback.
That's the way to make it happen.
That's right.
You know, before we get into that, just maybe it's worth a quick conversation about.
You were actually in New York City.
We just heard a siren go by.
So we now officially know that you're in New York City, right?
Yes, exactly.
There's always something going on there in terms of noise or energy or whatever.
For the UN Open Source Conference, that's super interesting.
What is that?
Yeah, so United Nations Open Source Week.
I got invited to attend through the Software Tech Agency and also Alpha Omega.
They are collaborating to host a maintain-a-thon, which is essentially just get a whole bunch of open source project maintainers, project leaders, governance people, like people doing more than just security.
So I was there to represent the security perspective and also Python, Python Software Foundation.
And just getting us all together and trying to talk about really complicated issues for open source and how open source can be used to better the world, to be a part of, you know, a more open access world, more open data world.
Those are kind of like the themes.
And specifically the maintain-a-thon was more like hosting small sessions with lots of discussion, almost kind of like the Language Summit, where there's a really short presentation about a topic I presented on low energy security.
So security practices and processes for projects that don't have access to tons of security expertise.
And then like, what are the, how can we make the situation better for those types of projects?
Oh, very cool.
There's, you know, there's a lot of energy for open source in the United States corporately,
but internationally, there's a lot of energy for open source at a governmental level.
More so, way more so than the US.
I mean, there's little pockets of things like, hey, we'd like to have some open source initiatives for what we're building in the US.
But there's, I can't remember what country's doing it right now.
One of the countries is trying to replace basically Microsoft Office and Windows with something Linux and open source.
And there's a lot of stuff like that.
Yeah.
I mean, it's about having sovereignty about or like over your technology stack, right?
Making sure that you have complete control and that there's interoperability and that.
Yeah. Being able to work independently as like a government agency, just as important as a company, right? You want to make sure that you're able to control all the processes and data that are inside that are important to you.
Sure. And I think we're in a bit of a special situation being in the U.S.
I don't think we have as much of a feeling of, wouldn't it be nice if we weren't beholden to U.S. companies?
Because we're already beholden to the U.S. We live here, we pay taxes, we're subject to the rules.
But if you're outside of the U.S., most countries and organizations are still beholden to U.S. companies.
And I think that that's a part of the vein of the ideas there, right?
Yeah, it definitely is a part of it. Being able to do your own thing without worrying about other countries, what they're doing or what their relationship is with you and still being able to interoperate on a global scale. Right. Because like a lot of these formats are open and they interoperate like PDF, Doc X. They're all they're all open. They can be written by any software, not just Microsoft software.
So yeah, absolutely. And I guess that's true for the U.S. in terms of software, but not so much for hardware, right? We're more in the same boat as everyone else with hardware, but that is a bit too far down the weeds, maybe, so we don't need to debate that. But it's super interesting that you're at that conference and it sounds really fun.
Yeah, it's a great time. A lot of really smart people here. So I'm happy that they let me in.
How'd I get here?
Exactly.
What office did you run for to get elected to that?
Oh, none. None of them.
Cool. So let's talk Language Summit.
When we started sort of backstage, we were trying to plan out some of the themes and stuff.
You talked about there being a couple of major themes of the Language Summit this year.
And I certainly, reading your write-up, thought like, wow, multi-threading has got some attention.
Yeah, free-threading was a big part of the Language Summit.
I think it was like a third, somewhere between a third and a half of the talks touched free
threading or parallelism or the concurrency model of Python.
It was obviously a big thing.
Yeah.
What are some of the other themes?
Yeah.
So the other ones are things like, okay, we have all these other platforms for Python.
If you read, if you've read like the last year's language summit, there's kind of this
through line of like mobile and web both kind of got discussed.
And so if you contrast like the status of those projects, then what the write ups were to now, the projects are way further down the line. So like Russell came up and got to say like, oh, mobile for Python, both on Android and iOS are basically here. And a huge round of applause from all the core devs because they were super successful in achieving the mission that they set out to do back a year ago at the language summit where they laid out what their plans were.
So yeah, there it will be basically mobile support. I think it's for three working, I think is the hope that it's going to be actually like working and you should use it and you can build apps with it. And that's really exciting.
It is very exciting.
Yeah. And then the other platform is web, obviously. So Pyodide is, is one of the big
ones there. So if you've heard of like PyScript or, Jupyter light uses Pyodide, both of
those platforms, like for Python on the web, there was this talk about upstreaming, the
FFI, the JavaScript FFI and some JavaScript APIs, to see Python as opposed to keeping them
resident in Pyodide. And what that would essentially mean is that if you ran Python
compiled for, what was it, like the WebAssembly platform, you would be able to interact with
JavaScript from the standard library, like the OS module or something like that.
And that is pretty exciting to hear something like that.
And there was also some talk about, apparently recently, MicroPython got web support.
And so trying to unify a little bit the APIs that the two are using.
Yeah, that's super exciting.
We'll definitely dive into it.
The fact that MicroPython got web support means it's possibly a good use for broader web applications, right?
Because PyDot is awesome, but it's also something like 10 megs or somewhere in megs.
And it takes a bit to load up because it is basically CPython.
Whereas MicroPython is 100k.
And people are used to doing 100k JavaScript, but not multi-meg JavaScript for standard stuff.
So yeah, really exciting.
We'll dive into that.
So not surprising. I thought we could just maybe work our way through the different presentations.
How long is each presentation besides the lightning talks about?
Yeah. So it's each session is, I think it's like 30 minutes. The talk itself is usually
10 minutes. I could actually think of the schedule. I should know that's off the top of my head.
The recitations are super fast. They're like 10 minutes and then the rest is discussion. So it's
quite a quick format. And your write-up mirrors that, right? So people read your
post, I'll link to, what I'm going to do is I'm going to link to the meta post, I guess,
in the sense of like a meta package in that it says, here's all the articles for, that
I wrote up for the language summit.
So you can jump to the ones you want to see.
And it, your, your write-ups mirror that.
It's like, here's what happened in the presentation.
And then the discussion that happened below it from all the core devs.
Yeah.
It's short presentation.
And then it's just like immediately into questions, feedback, all of that.
So it mirrors it.
This portion of Talk Python To Me is brought to you by Sentry's Seer.
I'm excited to share a new tool from Sentry, Seer.
Seer is your AI-driven pair programmer that finds, diagnoses, and fixes code issues in
your Python app faster than ever.
If you're already using Sentry, you are already using Sentry, right?
Then using Seer is as simple as enabling a feature on your already existing project.
Seer taps into all the rich context Sentry has about an error.
stack traces, logs, commit history, performance data, essentially everything.
Then it employs its agentic AI code capabilities to figure out what is wrong.
It's like having a senior developer pair programming with you on bug fixes.
Seer then proposes a solution, generating a patch for your code and even opening a GitHub pull request.
This leaves the developers in charge because it's up to them to actually approve the PR.
But it can reduce the time from error detection to fix dramatically.
Developers who've tried it found it can fix errors in one shot that would have taken them hours to debug.
SEER boasts a 94.5% accuracy in identifying root causes.
SEER also prioritizes actionable issues with an actionability score, so you know what to fix first.
This transforms sentry errors into actionable fixes, turning a pile of error reports into an ordered to-do list.
If you could use an always-on-call AI agent to help track down errors and propose fixes
before you even have time to read the notification, check out Sentry's Seer.
Just visit talkpython.fm/Seer, S-E-E-R.
The link is in your podcast player's show notes.
Be sure to use our code, TALKPYTHON.
One word, all caps.
Thank you to Sentry for supporting Talk Pythonemy.
So the first one, let me, I didn't always write down the names here, is the first one
is how can we make breaking changes less painful by Itmar Oren?
And so this one, Itmar deploys a bunch of Python code for production at meta
and said, going from version 3.11 to 3.12 or 3.12 to 3.13
has breaking changes that can be challenging.
I don't encounter too many breaking changes in upgrading Python versions,
but I also don't have literally millions of lines of code doing intricate things either so
right this is a pretty pretty edge case but also an important one right yeah this so this talk I
think one of the big things about this talk too is it wasn't just about like oh jumping from one
version to one version a lot of companies employ like a skip version upgrading style where they'll
experience breaking changes in a slightly different way than a lot of other users where they're jumping
from like 3.11 to 3.13, as opposed to like 3.11 to 3.12 to 3.13, because upgrading is obviously
this like big task. And so they don't want to do it every year. Maybe they do want to do it every
two years and that's fine for them unless there's some feature that they really need or something
like that. But yeah, so like anytime that you're upgrading more than one tython version, like it
just, the breaking changes are obviously twice as, twice as many on average. Yeah. Sometimes they
even go from 2.7 to 3.11. Yes and on rare occasions they go from 2.7 to 3.11 yeah thankfully that
happens less and less yeah that's a story from uh the last decade thankfully yeah so this
was like talking about like okay how we we're not trying to say breaking changes shouldn't happen
because we know that they're important and they're a good way to unblock things and remove pieces of
software that we don't want users using, but trying to make it so that we can almost like quantify
how bad a breaking change will be for users. And then based on that quantization, figure out what
we need to do, maybe extra if it's like a particularly bad breaking change, or if it's
just like, Oh, well, this has been deprecated for five years, and then removing it, or like,
there's an easy drop in replacement, that's one to one, those sorts of breaking changes are really
easy versus things like, oh, this behavior changed and you won't know until runtime and
things like that are way more difficult.
You have to have like a test harness that's actually testing all of the possibilities in
the code to know whether you're safe or not versus like a syntactical control F find the
bad function and then replace it.
Yeah, it could be super subtle, right?
It could be the runtime things, but it could also be the memory structure of something we
to a redis cache via pickling has changed and that's the that the cache version no longer works
and we have to somehow figure out how to completely delete the cache and start over and some web apps
that's a problem right when they're under tons of traffic that sort of cold start experience can be
a problem yeah and there's there's even things that like aren't even part of this gets mentioned
in a future talk about parallelism where it's not even a function of the language but it just happens
to be a property of how a particular set of code executes in one version versus another.
So like with the, from the difference between 3.9 and 3.10, where something is thread safe,
that it doesn't look thread safe at all. Like if you look at the code, you're like, oh, that's not
thread safe. But the GIL based, like the implementation of the GIL in 3.9 keeps it thread
safe. But in 3.10 and beyond, it's no longer thread safe. But the thing is, is you were relying
on behavior that's not defined in Python. It wasn't guaranteed. Yeah, there's no guarantee that.
And so it's like, is that a breaking change?
No, but also like it'll probably break somebody.
And also how do you detect that at a syntax level?
You can't, the syntax is the same.
Should it be written down as a breaking change?
I don't know.
Maybe does it, does your code feel broken if it gives you different answers
and those answers start becoming wrong?
Maybe.
Yeah, it's tough.
It's a really tough thing.
I think core developers were like pretty happy with the idea of like
treating different breaking changes differently, trying to develop some
sort of taxonomy of breaking changes.
And there were some interesting ideas with like running these like code update scripts, providing code update scripts that if you have code and there's breaking changes that are on the syntax level, being able to upgrade them.
Apparently, Ruff had some ability to do this for two major versions of NumPy.
And so like that got brought up as an example of like, oh, this worked really well for NumPy.
So maybe Python?
Yeah, absolutely.
Well, I was.
Yeah, absolutely.
I think Ruff is certainly in a good position to do that.
Yeah.
You could say, this pattern isn't wrong, but maybe it should come up with a warning, just so you know.
We can run this check if you really want to see, right?
Yeah, so one of the things Edmar pointed out was,
it's difficult to find the documentation of deprecated and removed modules,
because after a module is removed, the documentation is also removed.
It's like, it's a bit of a catch-22.
Yeah, that one was really interesting, because, yeah, like, especially if you're skipping versions, too.
Like you go to the docs and the module is just gone and you're kind of left to figure
out what was the last version that had that module.
When did the deprecation warning start?
Where's the warning?
Like where is the actual documentation that says what to do?
And so, yeah, apparently the docs editorial team are working on that.
They're trying to figure out a solution for better documentation for removed modules specifically
or removed.
Yeah.
Carol Willing said they were working on that.
Very interesting.
You can go to the documentation, like docs.python.org, and pick through it.
But by default, it lands on the latest, right?
Yep.
By default, it lands on the latest.
And if there are any links to modules or to deprecation links that aren't pinning to a specific version,
it'll go to the latest and be like, oh, we don't have those docs anymore.
Yeah.
It's just 404.
You're like, huh, weird.
Yeah.
Weird, weird.
Okay.
Well, very, very interesting.
The next one, we have an uncontentious talk about contention.
And now we start into the heart of the topics, which is threading, async, IO, parallelism,
concurrency, all these things, right?
And this is the one you were referencing when you ask, is this code thread safe?
So just give people a sense.
There's an incredibly simple parallel example of create a counter class.
The counter has a value.
You can run some code that goes for 100,000 times, increment the value, start 10 threads
at all, jam on that.
And then this is by Mark Shannon.
He says, we would like this to print exactly 1 million.
I'm not sure that that's necessarily true.
You would, as a creator of this program,
you wanted to exactly print a million,
but there might be advantages
to allowing code to run more parallel
rather than less parallel.
And say it's on the author of that code
to make it thread safe.
Yeah.
If it's five times faster
because Python, the runtime doesn't make it thread safe.
maybe you choose the time and the way that you run that code.
That's all I'm getting at.
Like we would like it to print exactly a million times as a correctness,
but maybe it's not Python's job.
No, I think maybe that comment is like not necessarily like we core developers
should want this program to print exactly one million.
I think it's more of like, oh, if you were someone who's writing this code,
you would maybe expect it to print a million because they're like, oh,
in three nine and before it prints a million.
So like, that's fine.
But then...
Yeah, so you know what changed in the GIL?
I actually don't know specifically what changed in the GIL.
It was something to do with context switching in the GIL.
Made this no longer change.
My guess is that it's performance, like you said.
Yeah, exactly.
Exactly.
They probably said we can make the GIL more fine-grained
and get more perceived cooperative or primitive multithreading as it goes.
Something like that, right?
Exactly.
Yeah, and that's kind of what I was hinting at there.
Okay, so that's the story.
And basically, Mark said,
thread safety is a property of the program,
the Python code you write, or someone's written,
in the implementation of CPython
and how it behaves, in this case, the GIL, right?
Yeah, so Mark was, I think the big thing for Mark's talk
was this synchronization quadrant,
where he is basically trying to make some bets
about what's going to happen next
to try to solve some of the problems
that we're going to start seeing or parallel Python, right?
And that's either anytime that you have both mutability
and shared references, you have problems with synchronization.
And if you introduce more immutability or less sharing,
then you're starting to solve these problems.
But the unfortunate thing is that there's a lot of Python
that happens in the shared and mutable section.
And we don't want to have to like ask everyone to rewrite all their Python programs.
So it's definitely like a tough like quantization problem.
Like how how big of an issue would making changes like this be?
But then also like we don't even really today give people a ton of the tools that they would need to be able to work with like immutable data structures.
Because like we have frozen set and we have tuples frozen list, frozen dictionary, any of that.
And so, yeah, Mark just basically gave a whole bunch of things
where it's like, here's all of these ideas that I have
for making this more easy, having more immutability.
And we should probably start thinking about that now
because we're starting to get into free threading time.
Yeah, certainly a threading collections sort of deal would be great.
Yeah, I think the final thing there was like,
oh, we should definitely be doing this on PyPI.
And I think the free threading team is planning on creating
some immutable data structures and putting them on PyPI at first before migrating them.
Oh yeah, that's an interesting idea.
Like take them for a test run before people, before they get baked into a pattern, right?
Exactly.
You know, one of the things that I think is a danger of those types of data structures
and they, don't get me wrong, they're useful and they're good.
But one of the dangers is they can give people a false sense of security, right?
If you have four or five lines of code that is changing state, you know, check to see something that is in the list.
And then in the next line, remove something from the list.
Even if that list itself is thread safe, if it's immutable, that's one thing.
But if it's a mutable list that you're trying to make a thread safe version of, it's still possible that the check was thread safe and the remove was thread safe.
But something happened between those two where the thing's no longer in the list, right?
It gives people this sense of, well, I've got a thread safe collection, so I'm good to go.
It's like on a line by line basis, that's true.
But as a block of code, it's still not true.
And you still have to think more about these things.
That doesn't mean you shouldn't have them.
But it is like an awareness sort of thing.
Because I'm doing thread safe.
Look, from system.threading.collections, import, whatever.
We're good to go.
Like, better.
Yeah, yeah.
You actually have to use the data structures.
You can't.
You have to use the immutable ones.
Don't use the mutable ones and expect.
Yeah.
So it's, but it is certainly in the right way.
There was some, there's some pretty extreme in terms of how much they would change programming
paradigms and ideas, suggestions here.
And I don't remember if they, how these are starting to blend together these different
topics, but yeah, like one of, one of the challenges is that functions and types are
mutable, right?
And that makes it hard, even at a CPython implementation,
runtime level of dealing with some of these things.
But changing them breaks the style of Python somewhat.
That's a trade-off, right?
It's a huge trade-off, yeah.
And the fact that everything is mutable
and a lot of things are shared,
like the standard library,
the whole standard library is shared across everything.
It's really difficult to say that, oh yeah,
if you're in that top right quadrant of shared and mutable,
which way does like the standard library move like you can't uh uh you can't make everything
immutable and you can't make everything not shared so it's what do you do yeah for sure and it's also
a performance issue that you could because you know like right here mark points out that
where mutability is lots of day uh maybe it is there but not for a good reason like functions
and class method resolution order, all that stuff.
It's mutable, but should it be?
The thing is, if it's going to remain mutable,
you probably have to do locks and stuff down in CPython,
which will slow it down.
If it were immutable, you don't have to lock it.
You can read from multiple threads all day long
and it's not going to hurt anything.
So it's actually a performance consideration,
not just a flexibility, right?
If you say, we really value this multi-threading
and we wanted to operate as quick as regular Python,
but scale really well,
these are trade-offs you got to consider, but then we all have like scars from two to three.
And this could be a little like that. Yeah. Yeah. I think it's going to, it's going to
matter. And I think that like companies are going to have to maybe start even like profiling their
own code and trying to see where they're hitting those, like those like stop or stop the world
locks or any sort of like performance issue, like, and trying to like track down where in their code
we're hitting those like really expensive operations. And if they're trying to write
this like extremely high parallel code, having having a way to profile it would be sounds really
like a good idea, because I think that there's like going to be once this starts happening,
people are going to have to start thinking about like CPython the runtime. What are the expensive
operations that are happening in my own code that maybe could be done differently to take
advantage of free threading completely. Yeah. Well, and going back to the opening part with like
the red safe collections and so on, it's really difficult for us as Python devs to create those
because we could write that in Python, but that makes it fairly slow. You need that down at the
machine level, right? Like probably CPython. We'll see if it's CPython or RPython or whatever,
as we go through this series of talks. But at the time of speaking, recording, it's CPython,
right? It would be way faster if there was a in the standard library C implementation of a thread
safe thing that's not being coordinated by a bunch of calls from the Python level. Okay. I guess
closing this one out, Mark suggested adding a freezing method to data structures like byte arrays.
That's kind of what we were talking about. And Barry Warsaw said that he'd brought up a proposal,
a PEP that was a freeze protocol that was rejected 20 years ago.
Those were different times.
Those were different times, right?
How many cores do we have?
Or was it like a dual?
Single digit still.
Yeah, certainly a single dual, maybe a quad core if you were awesome back then.
That's not the case anymore.
So the benefit of having something like this is certainly higher.
So I was like, why was that rejected again?
We don't know.
Yeah.
Freezing comes up yet again in another one of the talks about a fearless concurrency as well.
So I think that something like that is probably going to get resurrected,
at least tried to be done again.
This portion of Talk Python To Me is brought to you by Sentry's AI agent monitoring.
Are you building AI capabilities into your Python applications?
Whether you're using OpenAI, local LLMs, or something else,
visibility into your AI agent's behavior, performance, and cost is critical. You will
definitely want to give Sentry's brand new AI agent monitoring a look. AI agent monitoring gives you
transparent observability into every step of your AI features so you can debug, optimize, and control
the cost with confidence. You'll get full observability into every step of your AI agent.
That is model calls, prompts, external tool usage, and custom logic steps.
AI agent monitoring captures every step of an AI agent's workflow from the user's input to the final response.
And your app will have a dedicated AI agent's dashboard showing traces and timelines for each agent run.
You'll get alerts on model errors, latency spikes, token usage surges, and API failures protecting both performance and cost.
It's plug-and-play Python SDK integration.
Open AI for now for Django, Flask, and FastAPI apps
with more AI platforms coming soon.
In summary, AI agent monitoring turns the often black-box behavior of AI
in your app into transparent, debuggable processes.
If you're adding AI capabilities to your Python app,
give Sentry's AI agent monitoring the look.
Just visit talkpython.fm/sentryagents to get started
and be sure to use our code,
TALKPYTHON, one word, all caps.
The link is in your podcast player's show notes.
Thank you to Sentry for supporting Talk Python and me.
I don't know if you wanted to jump to that one
because I think that one and the uncontentious talk
is quite, they're pretty related.
We were talking fearless concurrency?
Yes.
Yeah, let's talk that one.
So that's by Matthew Parkinson,
Tobias Rigstad and Rudolf Stoltz.
Hopefully I did a justice to your name, folks.
Yeah, so fearless concurrency.
This was one of the more detailed ones.
And so this one, I don't know how I feel about this one, Seth.
This is one of those things where it's like,
if we take this really wild idea that really changes the way people have
traditionally done programming for concurrency,
then we could get great benefits.
But it also is like, I don't know what your assessment is.
My sense is that most Python people don't think a lot about threading, haven't done much threading, and their skills of threading, problem solving, using fairly straightforward things like locks is still pretty much like, I think they have those in the language.
You know what I mean?
Like, not really like, yeah, oh yeah, yeah.
I use event signals and all sorts of like producer consumers, like not very much of that.
You know what I mean?
And so anyway, tell us what this is about because it's an interesting concept.
Yeah.
So.
Debate it.
Yeah.
This concept is all about, so like the central concept is regions and regions are essentially
in Rust, they have this model where a mutable reference is only allowed to be like a mutable
object is only allowed to be referenced once, right?
Like that's the ownership model in Rust, but that's like not compatible with how Python
programs are in general. Yeah, because we love our mutability. And so this is essentially like,
okay, well, what if we could have kind of like a looser version of that, where you have objects
that are doing mutability and all of that within a region, but then anything outside the region
can't mess with it. And then if you have that situation, which is more common and more like
understandable for like a Python programmer, then you can get a bunch of performance benefits,
because you know that nothing outside of the region
is going to be doing any sort of like that special mutability.
Just out of nowhere, we're going to change something
about your function signature or something.
And so then when you have this situation,
you can even do, yeah, like so this diagram is showing
all these references into that region from a specific thread.
We know because of how the region is created
that the other thread can't modify anything inside.
And so you get a bunch of performance benefits
for all of the operations that are happening inside that region.
So I think that's kind of like the, that's like the elevated top.
Regions are like Rust, but better for Python programmers.
Yeah, yeah, sure.
And if you want some other thread to have access to it,
you've got to make all the things in that region and let go of it
so that it can be transferred ownership over to the other thread and so on.
Yeah, it's an interesting idea.
Like I said, I feel like it's powerful,
but I feel like it might be a bridge too far, you know?
I don't know.
Yeah, I think that, again, immutability came up here.
They even had some talking about, like, being able to freeze regions.
And so, like, you create a region of objects
and then freeze the entire region of objects,
and then none of those references can get modified.
And so the whole freeze protocol discussion kicked off again.
Yeah, so maybe something to look forward to for each protocol in Python.
Yeah, the region-based ownership,
It was definitely an interesting. I feel like, yeah, like, like you said, there's, there's a bunch of people that were asking questions about like, how much is the benefit? Yeah, it's, it's this different, like to, to take advantage of it, you would have to change your code slightly. So it's not just this like free thing that happens. It's more of like, okay, if you're like a library or project that really wants to take advantage of tons of parallelism, you would use these features. It wouldn't be just like, oh, every Python programmer, once they upgrade, they just get a bunch of free performance.
No, no, of course not. Of course not. Yeah. I feel like there was some interesting questions,
like interesting discussion, but for some reason I kind of, I left it out on my notes here, but
let me see. There was, so one of the things is there's basically four PEPs proposed or at least
imagined. I don't know if they're actually proposed yet that would make this, this happen, but maybe
it's coming from a different section, but a different freezing conversation somewhere else.
but there was the conversation like, okay, well, I've got a list.
The list has a bunch of pointers.
Some other thread got a hold of one of the items that's somewhere in the list,
but I freeze the list.
And so the list is frozen,
but then you still have this object graph that has leaked some of the mutable data.
So you could use that one pointer to one part in the array
and you could be making changes to it.
So there's like this discussion of object graphs as their whole becoming invalid or like they're becoming problems with like trying to share those that were not obvious, right?
Like really subtle programming challenges, not a race condition, but kind of a syntactical structure behavior problem that you run into.
And you can say, well, this section is frozen, but someone got a piece of it.
So now what do you say about it?
You know what I mean?
Yeah, I think the idea with like freezing and regions and all that is it would definitely be tracking the number of references that are held by objects that are outside of the region.
And so like if you would then try to like freeze an object or freeze that region, it would know that it's being referenced by something outside of a region.
And it would raise an exception instead of like allowing that to happen.
Because like right now it would just allow it to happen.
Whereas like getting an exception that, hey, a race condition is possible in this situation.
We're not going to let you freeze this object or freeze this region like that.
I think that's like a better user experience because if you're using regions, you probably
want these properties.
And that is a big benefit of that proposed idea that what would have been a runtime, either
race condition or deadlock becomes an exception that tells you this would have been a problem,
which that's massive.
yeah so okay interesting my first impression is that it's too much it's too much for the python
people yeah i'm sort of counting myself i'm not like just throwing shade like i'm sort of counting
myself in the same group to some degree even though i've done a lot of like block event-based
style threading still you know no it's it is interesting i think that it is a really good
idea for them to break the project down into multiple peps instead of trying to like you know
land this huge jet plane at the very end of the project instead just like try to incrementally
because I think that it'll be interesting going into the future, seeing how many of these peps
land, right? Like, will it be all of them? Or will it be one of them? You know, like,
I think there are some interesting things in this project, even if we don't get the entire
region based ownership model. Yeah, yeah. Yeah. Okay. Interesting. Jumping back one in time,
we've got number three of nine. So I'm feeling like we're gonna have to go faster.
Yes, yes, we might have to. This one is really interesting. This was a long
at least a long write-up.
This is the state of free-threaded Python.
And the question is,
does it make sense to move to the next phase of PEP 703,
which is, I believe that's the one that defined
free-threaded Python by Sam.
So this was done by,
this presentation was done by Matt Page,
saying free-threaded Python has come quite far.
And I believe since actually this was done,
this PEP has actually moved forward to say,
yes, we are moving on, right?
So this is a bit of the lag that you were talking.
Yes.
So I just,
I shared a link with you also the,
this just came through from the steering council.
How long ago?
A day ago from this recording.
Oh yes.
We bring you the fresh news folks.
Yes.
Where PEP 779 basically removed the experimental tag from the free threaded build.
And yeah,
I think that this presentation probably had a good chunk to do with that,
where they showed off.
Here's the state of everything.
Here's our proof that the community is adopting it at the expected rate at this point in the project, especially like the scientific computing community where like the benefits of free threading are huge.
We're seeing all this uptake.
We're seeing within the bounds of the performance allowance for single threaded performance.
Can we remove the experimental so that we can see this like next wave of adoption?
That was basically the whole point of Matt's.
And it seems like the answer is yes.
It does seem like it's yes.
Yeah.
That's very cool.
Yeah.
It means yes for 3.14.
So what was it, June?
That means yes in like four or five months.
Yep.
Stay tuned in October where you get your stable.
But please test your betas.
Which, yeah, we're already in the beta, aren't we?
Yeah, we're already in the beta phase.
So test your betas, folks.
So I guess it's worth pointing out just a little bit for folks who haven't been tracking this
super closely, like you and I.
This free-threaded Python's PEP 703 deal, I haven't seen anything like it, but I haven't.
there might've been other stuff like this and I just didn't notice,
but I'm all about the threading.
So I've been paying more careful attention in that it was accepted,
but conditionally marked as experimental.
And with the caveat that we may take it away from Python later,
if we don't like it anymore,
which is an odd acceptance.
I thought.
Yeah.
That,
that mechanism of,
I think it was just this,
this knowledge that this project would last multiple steering councils and
multiple years.
And we were kind of going into the brave unknown a little bit and acknowledging that, that,
hey, if it doesn't work out, we're going to have to pull it all out.
And that is unfortunate, but it's just reality.
We don't know what we're going to experience, what we're going to find.
It's such a big change.
And so one of those criteria was it can't slow non-threaded Python down too much, right?
And it looks like that's within 10%, unless you're on a Mac, then it doesn't seem to matter
for some reason.
Apple Silicon.
Yeah, Apple Silicon is magic.
But also with memory, right?
I think it adds a little bit of a memory overhead
for extra data structures to track safe reference counting and stuff.
Yeah, and actually the new acceptance criteria for the next stage
actually explicitly mentions the memory allowance.
This is like in Donghee's new post about it
is that there's actually like an explicit number now.
I don't think there was before.
I think it was just tracking the CPU performance.
Yeah, interesting.
And I guess it's worth pointing out, there's a couple of resources that you highlighted here.
There's a resource page by QuantSight, which is a big data science crew, that talks about what are the different projects that are relevant, I imagine, to the data science folks.
And what is their status with supporting being tested, being released for free threading, right?
Yeah.
No, these sorts of statuses.
And there's also one from Hugo, which tracks which wheels have the free threading available
for just like an easy pip install.
And in theory, that kind of means that these projects have tested it with free threading.
Yeah, it looks like we're at 20%, I guess.
Yeah, we're doing pretty good for this stage of like, it's experimental and it might get
ripped away.
Like that was what it was before.
Exactly.
People are trying it out.
I mean, like, this is how you get proof of people willing to try it.
I know that inside of the actual Language Summit discussion, they also talked about, like, wanting to dig in deeper into this data, where it's like, okay, the projects support it, but how many users are installing those wheels to kind of show, like, how much is the community testing out free threading?
Because just because a project supports it doesn't mean that, like, the community is trying it out at the same level.
Right.
So maybe that'll be relevant for the future.
I suppose at least for the ones that offer true rethreaded wheels, you could use PyPI data.
Yep.
The Lime Hall, Google Cloud, BigQuery, or yeah, BigQuery.
The BigQuery thing.
There are other ones that are, well, it's just pure Python, so it probably works.
That's harder to quantify.
So yeah, basically that change came along here.
It says we support moving to what they call phase two, something like that.
So there's multiple phases still, but yeah, excellent.
talked about this fearless one. We're no longer afraid of it. People are tired of hearing about
threading for a minute. How about governance? Yeah. So Eric Snow did a presentation entitled
The Challenges of the Steering Council. That's pretty interesting here. Tell us about this one.
Yeah. So this one was kind of talking about as a core developer, how is the experience of having
a steering council governing the development of Python? How is that working out right now? What
What's the good? What's the bad? And I think the highlights are having a rotating, a completely
rotating governance set of people on a council. Even if that means that most people are still on
the council year over year, you still have that whole complete stoppage of time because people
are starting to kind of like wind down because they know an election is coming. And then,
so like PEP development gets impacted by that, right? If you're not timing your PEP authorship
right, then sometimes you just get these huge delays. Also talking about how much the need for
consensus impacts people's ability to participate in the discussions. So before, you could just
participate openly. You don't have to worry about like, oh, am I speaking as the steering council,
or am I speaking as individual or core developer? But now there's such a need for consensus that it
kind of puts steering council members in a weird spot where they can't participate in the discussion
unless they've already talked with other people in the steering council or do that as easily.
And I think there was one more.
Yeah.
One of the thoughts, one of the threads was I had a conversation with somebody who is a core developer,
but also happens to be on the steering council.
I felt like we were in agreement on this idea.
But then when I spoke to them as steering council member,
then the story changed a little bit because it was a committee response.
And you're like, I think Eric Snow himself expressed frustration that like, I've, yeah,
I've worked on this project.
I thought we had agreement.
And then turns out for some reason it wasn't right.
Yeah, I think, yeah, they, it's really hard to know if you have consensus when the like
response, right, is delayed because you can't tell then if it's consensus because like the
discussion is, you know, slowed down and no one's bringing up any new points.
or if it's because like people have thoughts,
but then they have to talk
to their steering council fellow members.
And then, you know, it's difficult to judge
and you don't really want to tip the hat
one way or the other during the discussion
because you don't want to get people with false hope.
You don't want to like tell people
not to work on something
when it's actually going to go through.
So it's challenging.
Yeah, two other issues.
I guess it's also worth pointing out before I say this
that Eric said, look, things are working pretty well.
Python hasn't stagnated.
peps are getting approved things are happening right so that's good but one challenge is just
it's slower to get responses about peps and so on because it's volunteer committee work rather than
one person who can just be the decider you know yeah it's it is really tough and especially and
this kind of comes through with like here's all these things that are happening to python all at
once and uh yeah good luck steering council with like trying to make all of those things work
together because the thing is the steering council wants all of these good projects that
are having to python to all land and to all have a good time but they all interdepend on each other
i know that there was like a like people were talking about delegation as like a potential
solution for this and i think the steering council like loves delegation they want to delegate more
but they sometimes have an issue with delegation when it comes to these topics that like overlap
with other big projects that are happening concurrently in Python, where you can't delegate
someone for free threading because free threading touches everything. And so if you delegate
something for free threading, then that person is not looking at all the other projects that are
happening in Python. And that's a problem. Yeah. Yeah. I think another two other things I want to
touch on real quick. There's a lot of interesting stuff in this one. One is visibility into what's
happening in the steering council discussions, right? And that talks, it's a little bit addressing
the surprise, but also just knowing. Kind of like you did for the language summit, you brought a lot
visibility and awareness of what's happening there. A lot of this wouldn't be known, especially what
happened in the discussion, if it weren't for something like that. So Guido pointed out that
California, where he lives, has the Brown Act, which requires all meetings, like governmental
meetings, to be open to the public for local governmental groups in charge of infrastructure
without private deliberations barring personnel issues or something like that right so basically
there's um regulations or rules for saying like here's how the stuff is open you know maybe all
the conversations are lives all the meetings are live streamed or who knows you know something like
that yeah no the there was a lot of different options thrown out there for like how to make
these meetings or the deliberations or decision making of the steering council more open one of
we don't put out there that like oh maybe they should just be open like everyone can see it like
a live stream or like the meeting minutes are just you know transcribed instantly and then published
the next day or whatever like something like that or because right now they publish meeting minutes
and they're they're getting more regularly doing that like actually getting the meeting minutes out
on time i know there was like some uh there was definitely some issue with that in the past where
like the meeting minutes were really delayed and so it's really hard to to keep up to date with
what actually got discussed.
You want the 2025 version, not the live stream,
but you put your AI assistant in all the meetings.
Sure, yeah.
And let it creep meeting notes.
Honestly, it probably wouldn't be that bad.
There might be a few things like,
oh, you got that wrong, sorry.
But in general, I think it'd be pretty good.
And then the last thing here is
there was some conversation of like,
well, deciding by committee's tough
and how much of the community should we listen to?
And somewhere it was proposed that maybe,
Maybe things like discuss.python.org.
We've had polls and people said what they wanted and didn't want, right?
And Barry wisely points out, like, polls are useful,
but there's a whole bunch of people, millions of users,
that are not participating in discourse.
And I just want to take a moment to, like, restate.
I think that Scott Hanselman has such an amazing topic or idea here
where he talks about the dark matter developers, the unseen 99%.
and I'll link to this.
So obviously we know what dark matter is in astronomy,
but like these are people who just go to their jobs.
They don't spend their evenings on discussion boards.
They don't go to conferences
and participate in panel discussions.
They're not on social media.
They just use Python or whatever language
and they do their thing and it matters deeply to them,
but you won't ever notice them in these polls
or PSF surveys or whatever
because they just don't do those things.
There's probably a good chunk of them.
Yeah.
And the steering council has the difficult job of representing these folks too, because
they try to do what's best for Python.
And that's for everybody, not just people that vote and polls on Discord.
Right, right.
That's what Barry was saying.
It's like, it's tricky though.
It's like, how do you measure that?
You know what I mean?
Yeah, it is super, super tricky.
All right.
Packaging.
Yeah.
So this one was really quite a quick talk or it was mostly just talking about, hey,
this PEP is happening.
The packaging governance process.
I know that this got discussed a lot more in the packaging summit.
Here, I think it was mostly just like, hey, this is happening.
Here's what the steering council needs to know.
Here's what core developers need to know.
This whole thing came out of the wheel next directive, which is like wheel next.dev.
They've got their own website.
And it's basically trying to adopt the steering council model, but for packaging, because right
now packaging peps tend to be delegated to like one or two people.
And obviously, if things 10x or 100x in complexity and concurrent projects, it is just not possible for one person to just be doing that work.
And so trying to adopt a council model, similar to the steering council.
And I think the biggest open questions right now are things like, how is that initial council and how is the voting body going to be formed?
Because the voting body for the steering council is core developers.
But what is the voting body for Python packaging?
Right, exactly.
And again, it runs into some of the issues of sort of delegating, but packaging touches
everything and so on.
Yeah.
Tricky.
Okay.
Excellent.
And you referenced this one, Python Unmobile by Russell, Keith McGee and Malcolm Smith.
I just had Russell on the show not too long ago to talk about some of this work as well.
But he says, after many years, this year, I can say that Python Unmobile is there, met
with a large round of applause from the room.
Yep.
Yeah.
It was it was an awesome moment, especially because I covered kind of like one of the last status reports before the big hurrah.
We did it with Russell and Malcolm.
Yeah, basically both of the peps for Android support and iOS support are finished.
And they are tracking really, really close to basically adding tier two support for iOS and Android to Python.
And tier two support basically means that if any feature change or bug fix or anything ends up breaking support for that platform,
then a release can't proceed.
So the platform basically needs to be supported
for a release to happen.
And that's a huge deal
because it means that people can be confident
that support isn't going to just be taken away
or not surprised it doesn't work, which is great.
So basically it just means there's a whole new,
hopefully a whole new set of users
that can use Python to build on these mobile platforms.
Yeah, that'd be great.
So specifically PEP 730 and 738,
meaning that CPython builds and runs on iOS
and builds and runs on Android, right?
And that the core development team
considers breaking that build
part of breaking Python, right?
There's still work to be done
in terms of tooling, right?
Like I'm not going to get a Python plugin
for Xcode and drag a storyboard across
and then publish it, right?
Some of that stuff is coming from the Beware team
backed by Anaconda, which is great.
But I think this announcement is like
the runtime CPython bits are in place.
Yeah, definitely.
So like, yeah, it's not like,
oh, suddenly Xcode just works
and you can just write an Xcode project in Python
just as easily as you would write,
you know, a web app in Python.
But yeah, the fact that it works at all,
like the fact that you can run it on an iPhone
or on an Android phone,
like that's huge.
And the core developer team is willing to say,
yeah, this is going to keep working.
They should.
It's not a flash in the pan, these mobile phones.
Some people use them.
Allegedly.
How many do I have around me?
I know.
As I have one in view.
Yeah, exactly.
Where's the iPads and all the other stuff?
Yeah, if I never see Xcode again in my life,
I would be too soon.
It's just such a bad, bad piece of software.
It's such a bad tool for building software.
I've had to work with a lot for our mobile apps.
I've thankfully not have to dealt with any app development yet
in my career. It's been all web development.
It's such, you don't appreciate
the freedom that you have. I know open source means freedom in some ways,
but just the ability to go, I made a change. I published it.
The world has it. It's not like I've had a debate with random people
who are in a hurry and don't care about what I've built, and then they tell me that it infringes
on something somebody else built, even when that's actually not true, because they don't understand
what it does. That's even outside. A lot more people involved in mobile publishing. And rules
that don't align with your incentives. Like we want to extract money from you. Anyway, that's a
long story of through app in-app purchases. Yeah. Okay. Another one, I hinted to this, like,
are we going to need to change the name of CPython? Because CPython means literally the C language
implementation of python what a core developers want from rust and do they want rust in their
c python you know is this a uh reese's pieces reese's peanut butter cup sort of thing you got
your rust in my c or something yeah yeah yeah uh yeah this was this was a really interesting one
because i think that um the room was maybe a little bit surprised by like how like open uh
core developers were about maybe the idea of something optional being in cpython that is
written in rust um because like cpython there's the core runtime right there's the syntax there's
the interpreter there's all that stuff that like everyone uses on every single python session but
then there's also all these standard library modules uh like os and sys and ssl and all of
these other libraries right and those modules are kind of their own thing they're their own little
project that just happens to live inside of cpython and i think the result of all of this
conversation of like oh what what does what do core developers want from rust was like hey let's try
let's try something uh maybe having a standard library extension module written in rust and like
what would that take what would that look like um would we need to change the build system would we
need to you know what would actually need to happen for for that to be a possibility um and i think
there's some like huge benefits to having rust I mean David talked about a whole bunch of them
where it's like this it's this new language there's lots of new programmers that are interested in it
has all the memory safety stuff it has all the performance stuff and also yeah brief threading
works really great with it there's just like tons of benefits to to having rust be a part of like a
python python developers toolkit it's like how can we can we also have that in the cord for libraries
and I think the answer was like try it out and see what happens and maybe who knows right like
they definitely like core developers caveat it as like it'll definitely have to be an optional part
of the standard library because not everyone is going to be using Rust on CPython and yeah maybe
not one of the core parts of this of the actual of the interpreter in the runtime because they're
they're quite well used and well maintained right now.
So we'll see.
I think it's going to be interesting to see if,
if David and some other interested folks will,
will put together something like a standard library module that uses rust.
Yeah.
Maybe in 2035,
we'll still be doing this.
We'll still be talking about,
but we'll be talking about how the C adaptive layer to integrate with rust is
working.
So we can still keep all these C extensions running instead of the other way
around.
Yeah.
A couple of interesting takeaways.
David points out, our best estimate is that somewhere between a quarter and a third of all native code being uploaded to PyPI for new projects is using Rust.
Yeah, so this uses like, basically use this, it's py-code.org, where it can introspect into Python, like packages, the actual files that are uploaded, and then looks for Rust.
And so like any package that is using Rust
and it's a new package or a new release,
you can see like what percentage of new projects
are using Rust versus like C or C++ or something else.
So David was able to extract that data point.
Yeah, there's a lot of Rust happening for new projects.
Obviously, old projects are likely very C, C++ dominated,
but what are new Python developers choosing to use?
Yeah, they didn't choose C.
They just chose not to rewrite it in Rust yet, which is a different barrier, I suppose.
Not saying they should, but I agree that choosing new projects is an interesting metric.
So a couple other things from here is like, should we rewrite CPython in Rust?
There's a lot of people like, or a lot of comments of like,
there's a lot of people who just don't want to learn Rust.
They don't care about Rust.
This is a challenge for CPython is that the core developers in particular
have a special skill of writing C
and writing CPython in particular.
And this moved the cheese for a lot of folks.
And they like, how much do they care, right?
Like they took Rust on Linux,
Rust in Linux core as an example, right?
People just, they don't want to change,
which I'm not saying they should, but.
Yeah, it's a really difficult question,
especially when there's like this really tight ownership
of like one or a few people
with like this very specific part of code.
And, you know, they've been maintaining it
since for a really long time,
and it's hard to try to force that sort of change onto people.
But then things that are new or things that are optional,
that's a really great place to start.
I think learning from the Rust and Linux project
is a really great idea for Python,
because it's in a lot of ways,
even though Linux maybe is an order of magnitude more complexity,
I think that the situation or the structure of the code
in the project is pretty similar,
where there's like this really big core.
And then there's like a ton of different smaller sub projects that are all have
their own little owners, governance, contributors happening in the background.
Yeah.
A hundred percent.
I mean, it is, it is 2025.
We could try, try again.
I mean, we could just vibe code it like, Hey, cursor, rewrite CPython and Rust,
or you go to jail.
Is that the meta these days?
That's there's this really great video.
Senior engineer tries vibe coding.
It's always telling it, like, if it doesn't do it, it'll go to jail.
But also it says, please, like, or you go to jail, please.
It's amazing.
I mean, as much as I joke, honestly, I do think AI code assistance could help in supporting
the transition.
I know that's good at C and it's good at REST.
Not that you should vibe code it.
That's not what I'm saying.
But anyway, we live in weird times, Seth.
We do.
We really do.
I think the other constraint here that maybe a lot of people don't track is that it's not just, I need to somehow make CPython work on Linux, Windows, and Mac.
And if we build it in Rust, that's a different tool chain.
There are a bunch of edge cases and platforms that are not very commonly used that maybe Rust itself doesn't even support that Python has promised to keep running on, right?
Yeah.
Or, I mean, even if not promised, right?
Like there's people that are just running, running on these platforms.
And then if something would break, they would only show up when something breaks.
And what do you do?
Right.
Like you've been supporting these people for a very, very long time.
And what, what, what happens then?
What, what was stability guarantees?
Do you give those people that, you know, maybe you're not like a tier one platform, but if
you've been, you know, making them use like they've been using Python totally normally
for all this time.
What does that mean?
So, yeah, well, we just talked about tier three iOS and Android.
support like does it work there i maybe i don't know but you've got like this little micro python
circuit python chip that i got that's like i don't know like size of a thumb or something
does the build system work for that i don't know yeah but i'm running python on it today yeah i
think that like one of the things that got identified was the state of gcc support for
rust as as like something interesting so that's something to track if you're if you're interested
in Rust and CPython working together,
that's definitely like a project
that's outside of Python and Rust's,
like, and, you know,
Maturin and PyO3s
if you want to watch that project.
Yeah.
Did say we need to go faster.
Lightning around.
Close things out here.
I guess there's really,
there's just the Pyodide.
We didn't talk about the docs
or the lightning talks.
What else should we say
before we call it a wrap on this?
Should we go,
let's go into the lightning talks
and look at Guido's.
I think that one was the most well-received
and interesting lightning talk,
which is contrasting how Python is developed today
versus how it was developed by Guido
and what sorts of things are we kind of like leaving behind
by developing Python in this way?
And is there anything that we can learn from how we use it?
Does he mean more committee, more community agreement?
Or what was he getting at?
I think it's the complexity side was the part that was really big for him, where it's like,
we're trying to, if you want to land a feature in CPython, you need to write a perfect pep,
come with a pull request that is, you know, performant and secure and the API is perfect
and it's been vetted and it's been used. And like, there's this super, super high bar to clear,
to add a feature to see Python.
And you're not allowed to get it wrong.
The first go around basically is I think was what he's mostly mentioning.
Because demanding perfection means it's like the,
the code equivalent of don't let good be the enemy or the perfect great be the
enemy of the good or something like that. Right. Sure. Yeah, exactly. Yeah.
Stuff like that where it's like, Hey, we, if,
if Python were developed in that way early on,
it wouldn't have worked out because that would still be in the lab or an idea
or something exactly so i think that's a really interesting one to check out if you're looking at
lightning talks okay cool now i i know some features have to be absolutely dead center in
the core of the cpython runtime like free threading or a no GIL initiative or some new memory model
or whatever but a lot of these things probably certainly with the standard library could maybe
You talked about the immutable, the thread-safe concurrency data structures.
Maybe there's a more formalized path of starting these things
as third-party libraries on PyPI.
And once they reach a certain bar maybe of adoption and maturity,
then they make a step towards that.
It would be interesting if, I know people can just go and create a project and do it,
but like here's the prescribed way of non-C runtime features being added to the language.
and it starts out in public and it makes its way over.
Yeah, I think that got discussed
in the last language summit too.
I'm not sure if there's been any progress
on like actually making a solid model
for like here's how you go from PyPI to PEP
to standard library.
But it's definitely,
I think it's just going to keep coming up
until that happens.
Because it's really common, right?
Like so many features get developed this way now.
It's also interestingly,
some of the ideas of that direction have been rejected,
like moving requests into cpython standard library was rejected because it would harm the growth and
status of requests not cpython even though request is clearly better than what's built into cpython
for your access you know not throw no shade that stuff's been around for a long time but yeah i
mean request is built on it so it obviously does some job well yeah yeah exactly it's just like a
more user-friendly higher level api in front of it and we have httpx for like concurrent basically
asyncio requests equivalent.
So there's certainly history or examples
of stuff starting out there becoming very popular
but not wanting to go in,
but specifically things that you might want to.
Like, for example, would data classes be a thing
if Pydantic was on a trajectory
to sort of fill that role or adders from Hennig
or something like that, right?
Maybe not, I don't know.
Yeah, no, I think that that whole road of experimentation
and then moving into the standard library,
like, we're just going to keep seeing it
because it's just, it's such a great way
to get stuff in the hands of users really, really quickly.
Yeah. And I don't think just like,
if I just went out and made a library,
said I'm doing a library
and I think it would be fun to have this as part of Python.
Like people go, good for you, Michael.
They would ignore it. Right.
But if it was a little bit blessed by the steering kit,
like we're experimenting and considering this idea
as core developers, it starts here,
but if it gains traction, it becomes Python.
I think that is a different positioning
than just like a random project that looks interesting.
Yeah, definitely.
I think that last year,
one of the things that got suggested was like,
hey, maybe we allow people to have those sorts of projects
once they reach some amount of maturity
and like direction to be housed under the Python GitHub org
to try to give them some sort of like legitimacy of like,
yeah, this project is on the track to going here
and here's us showing that it is, right?
Yeah, yeah, yeah.
I feel like I should just say one more thing though.
I do think there's a lot of value in having Python be smaller
and having a bigger ecosystem outside of it.
I'm not suggesting that everything should just be moved in into Python.
I do think that just go like, I don't care what CPython does.
If I like this HTTP library, I'm going to use it.
And if it wants to implement itself in Rust or OCaml or whatever,
I don't care.
If that's better, they can go do that.
And then I'll use it and it'll be great, right?
and that doesn't have to go through committees and all this kind of stuff.
So I'm not necessarily saying like everything should try to like find a hub
and spoke model into the core Python,
but those things that do intend to be there,
it'd be cool to see like this sort of progressive path.
People can get to it sooner. Anyway. Yeah.
Final thoughts on that before we call it a show.
I think we nailed it. Honestly.
No, we definitely did. We definitely did. Yeah, no, let's,
let's wrap it up. Thank you for doing this. This writeup.
It's really interesting.
I always value this look into, you know,
to where's Python going.
It's a lot to take from it.
Final thoughts on this year's Language Summit?
It is a really exciting year to be a Python developer.
I think that 3.14 is,
it's got so many really interesting things
and changes to try.
I am quite excited to get my hands on the beta,
but then also the stable releases.
I really am excited to see what people actually
then go and do with the stuff, right?
like building web apps with Python,
building mobile apps with Python,
building these massively parallel
applications with Python.
It's a pretty good time
to be a Python developer right now.
It's only getting better.
Absolutely.
All right, Seth.
Thanks for being back on the show
and thanks for doing the write-up.
Thanks for having me.
Yep. See you later.
This has been another episode
of Talk Python To Me.
Thank you to our sponsors.
Be sure to check out
what they're offering.
It really helps support the show.
Take some stress out of your life.
Get notified immediately
about errors and performance issues in your web or mobile applications with Sentry. Just visit
talkpython.fm/sentry and get started for free. And be sure to use the promo code
talkpython, all one word. Want to level up your Python? We have one of the largest catalogs of
Python video courses over at Talk Python. Our content ranges from true beginners to deeply
advanced topics like memory and async. And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
*music*