Every year, the Python core developers and a few other key players in the Python ecosystem
meet to discuss the pressing issues and important advancements
at an event called the Python Language Summit.
While Python is a community known for its openness,
this meeting is typically held behind closed doors, mostly for efficiency's sake.
On this episode, we'll give you a look behind that door.
We have Alex Waygood here on this episode to break it down for us
and give us a report from inside the Python Language Summit.
This is Talk Python to Me, episode 375, recorded June 29th, 2022.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy and keep up with the show
and listen to past episodes at talkpython.fm
and follow the show on Twitter via at Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube
to get notified about upcoming shows and be part of that episode.
This episode is sponsored by Reflect.run.
If you can browse the web, you can use Reflect.run to create sophisticated tests for your web app.
And it's brought to you by Microsoft for Startups, Founders Hub.
Get early stage support for your startup and build what you've been dreaming about.
Transcripts for this and all of our episodes are brought to you by Assembly AI.
Do you need a great automatic speech-to-text API?
Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/assemblyai.
Alex, welcome to Talk Python to Me.
Thank you.
It's great to be on the show.
Big fan of the podcast.
There's so much going on with the Python Language Summit, especially this year.
I think there's quite a renaissance of new ideas to sort of look at the foundations and the fundamentals of Python.
And a lot of it has to do with speed in different aspects.
Maybe that's through threading or through raw performance or reference counting garbage collection.
And so we're going to dive into all those ideas and more by just talking about your coverage of the Python Language Summit 2022.
It's going to be super fun.
But before we get to that, let's get to your story.
How did you get into programming in Python?
And how did you get inside the Language Summit anyway?
Oh, yeah, sure.
So I started programming actually only around two years ago.
But my first line of code during the pandemic started off as a hobby.
Still actually is a hobby.
Had to have something to do while staying indoors.
Exactly.
Yeah, so Python is my first language and I'm entirely self-taught.
And yeah, once I started, couldn't stop.
That's cool.
What kind of things were you looking to build?
Were you just looking to learn a language or did you have some idea of something you wanted to create?
So I started, so I was doing a journalism master's at the time.
And there's a sub-community of journal coders.
So people who use programming languages to gather data, scrape the web to find stories, essentially.
So I thought that sounded pretty cool.
Yeah, that sounds very cool.
Yeah, so I started learning Python to help with that.
And then sort of started to realize I actually enjoyed Python quite a lot, just for its own sake.
Started building, built a card game using Pygame.
It was one of my first projects, which was a lot harder than I anticipated.
All the first projects are.
Oh, yeah.
Yeah, definitely.
And then built a bad website using Flask.
And then eventually started contributing to open source.
And that's about where I am now.
Fantastic.
Yeah, yeah.
That's really cool.
It's interesting that you bring up journalism.
I had Carolyn Stransky on a little while ago, predated the pandemic.
Is it?
Did it?
Yeah.
Maybe not.
I don't even know when the pandemic was.
A couple of years ago.
Anyway, we talked about Python.
Looks like you just hit before the business started.
Just before it really, really kicked it.
Exactly.
Yeah.
We talked about Python and AI and journalism.
And there's a ton of neat things that people are doing to sort of automate the act of gathering data and reporting on it, right?
Yeah.
No, it's a really cool space.
Directly employed in journalism is my full-time job at the moment.
But it's something I'd love to dip into again at some point.
For sure.
Yeah.
Carolyn was talking about things like monitoring certain websites like the National Geography, whatever the foundation is there, that alerts people about earthquakes.
And I would bring up details and sort of pre-fill.
So like some folks in LA, like on the LA Times or something, would get an alert.
There's an earthquake.
Here's most of the details.
Just put the details around it and hit publish, you know, within 10 minutes or whatever.
That's pretty cool.
A little beep and then go write your article now.
One of my first projects I tried to do, again, biting off much more than I could chew, was there's a, in the UK, we have this body called Historic England, which catalogs England's old buildings and heritage assets.
And I have this all online, but it's not like in an easily downloadable form.
You know, you can't just like download the CSV of the National Heritage List.
So I decided that I was going to try and scrape this from the website.
Of course, the scraping is easy, but then the data cleaning is a nightmare.
Because like there's no consistent format and some of it's from the 1950s and yeah, it's horrible.
Well, it would have been cool if you could have gotten it right and shared it with everyone.
I got, I got some way there, but yeah, it's way too, way too difficult for one man.
Like just started learning a few months ago.
Yeah.
Of course.
It's those kinds of projects that are really good for learning programming.
You know, they're.
Oh yeah.
I learned a ton.
Don't regret it at all.
Yeah.
You're like, here's my goal.
And then you just start frantically searching for like, well, what are the steps I need?
And then how do I make those steps happen in my programming language, Python in this case?
And like, you might not normally care to figure out how do you parse a CSV file out of this,
but you're going to have to do it now because you're trying to, you know, aggregate on, you know,
add onto it, append onto it and so on.
So yeah, those kinds of things are great, great projects.
Cool.
All right.
Well, how'd you get into the Python language summit from a journalism anger, from the open
source angle?
What was, what's the story here?
I was invited in the autumn, I think, to become a triage with CPython.
So at that point I'd contributed a lot of docs, documentation fixes, just something I was pretty
good at because of the journals and masters.
You actually know how to write.
So yeah, I do know.
I'd also contributed code to a few modules at that point, a few small fixes to,
I think, functools, enum.
Yeah, a few standard lib modules.
So I'd been invited by Ken Jin, who's one of the typing module maintainers to become a triage
during the autumn.
So that got me onto the CPython developers' Discord channel.
And then in, I think it was February or March, there was a discussion there where a few cordels
were asking who they were going to invite to become the blogger this year.
You know, Alex does journalism.
Yeah.
I got this, I got this master's.
I mean, could maybe I do it?
And they said yes, which was very flattering.
Yeah.
Fantastic.
And great of them.
And I really, really appreciate it.
So it's Ukash, Mayata, and Sentil this year who organized the Language Summit.
So massive thanks to them for inviting me to be the blogger this year.
I actually appreciate it.
Yeah, that's great.
You must have been also at PyCon then, I'm guessing, because if you're at the Language Summit,
you're at PyCon.
Yeah, what was your experience there?
Was it a good time?
Yeah, I had a blast.
It was great.
Yeah.
It's awesome to meet all these people I've been, you know, doing up and sort of stuff
with online for several months.
Yeah.
It was really cool.
Cool.
I really appreciate these conferences because there's people I work with or talk to in different
ways through, you know, through GitHub, through Twitter, through the podcast.
But you don't really get to see them in person because they're halfway around the world until
you show up and have a beer together or hang out together.
I think that was, I mean, the talks are fantastic.
But yeah, that was definitely the best bit for me.
Yeah, that's the same for me, actually.
That's the thing that I dig the most.
All right.
Let's talk about the Language Summit.
Sure.
So maybe tell people really quickly, what is the Language Summit?
Sure.
The Language Summit is an event every year.
It's just like a day or two days before PyCon itself starts.
Most of PyCon is available to just like anybody who's interested in Python.
The Language Summit is generally only available to like core developers and special guests.
So it's a big exclusive.
That's not because they want to be like secretive about what's happening in there.
It's more so that it can just be a sort of frank conversation between trends, I think.
Sort of.
Yeah.
Does that make sense?
Yeah.
I mean, it's where the business of planning out Python gets done, right?
Yeah, exactly.
Yeah.
It's not the only place.
We have our peps and we have other places where conversation happens.
But it seems like one of the places where, you know, some of the ideas of the peps are discussed
and there's a quick feedback loop amongst a lot of the core developers.
Yeah, exactly.
I think it's just, you know, get everybody together all in one small room, talk Python for the whole
day and then see what comes out of it.
Awesome.
How many people show up there?
How many core developers and other folks?
Around 30 this year, I think.
So mostly core developers, a few triagers and a few special guests.
So Zach Hadfield-Dobbs, I think, from Hypothesis was there.
Sam Colvin from Pydantic.
So yeah, a few open source maintainers outside the Core Dev team as well.
Right, right.
Yeah.
Yeah, Pydantic's interesting.
Obviously a great library.
It's interesting to me because it kind of, a lot of its meaningful functionality is in
the way that it breaks with the tradition of Python, you know, in the same way, like type
hints.
Now all of a sudden don't just mean something, but like they are the core way in which that
library works.
Whereas like most of the time it's a suggestion or a hint as the name would suggest.
Sure.
Yeah, yeah.
And in the way it's quite coercive as well.
So you don't have to like, yeah.
Yeah, for sure.
It's, so he's a good guest to have because he's, he's both got a popular project and
one that's kind of an outlier to some degree.
Yeah.
It's hugely popular, isn't it?
Yeah, it sure is.
We've got, you know, SQL model by Sebastian Ramirez, which is basically take Pydantic models
on top of SQLAlchemy and you've got Beanie from Roman Wright and there's some other ones
that are just like sort of using Pydantic as their, their layer, which is really cool.
So obviously the reason we're chatting today is this year's summit was covered by Alex
Waygood.
That's awesome.
That's me.
Yeah.
Yay.
Nicely done.
And so I, when I saw this article or series of articles, I guess you might say come out,
I thought it was really fantastic because like I said, I think there's just so much that's
exciting going on here.
No, it's not.
Well, we're going to change the language a little bit here or there, but there's, there's stuff
that everyone's going to get.
That's really huge stuff in that.
Yeah.
Yeah, absolutely.
So I thought what we could do for our conversation is just go and order and just sort of chat
through them.
You can give me a sense of what it was like to be in the room.
What are some of the main ideas of, of each of these?
And we'll, we'll just chat about them.
So the first one was a very exciting project by Sam Gross.
Yes.
Who I think works for Meta.
Yeah.
I think he does.
Yeah.
I think he does part of the Cinder stuff.
Yeah.
And this is Python without the GIL or, or no GIL.
I don't think he's on the Cinder team, but, but yeah, he is working at Meta.
Right.
Okay.
Cool.
Yeah.
There's other stuff from Cinder.
We'll get to later.
Yeah.
But yeah, Python without the GIL or, you know, his, his no GIL story.
There's been a, you know, from a historical perspective, we've had attempts to remove the
gill or change the performance characteristics of the GIL and so on.
And maybe let me just set the stage a little bit with this GIL or global interpreter lock
for people listening.
When I heard this, the global interpreter lock means you can only run one statement of Python
at a time, even if it's happening in multiple threads.
I thought, okay, well, this must be some odd constraint put on the language so that things
like threading are easier for people.
But as I learned more about it, the real purpose of the GIL has nothing to do with threading
per se.
It has to do with memory management.
Yeah.
And so the way memory management happens in Python, at least in the primary first pass
sense is it's reference counted.
So everything, numbers, strings, classes, dictionaries, they all have a ref count.
And if that ref count ever reaches zero, it gets deleted as long as there's no cycles.
And the problem is if you're going to change that number on the object, normally you would
have to do that in a thread safe way.
You will lock it.
But that turns out to slow single threaded Python down a lot when it's unneeded.
And so the global interpreter lock is there to meant to basically allow for that reference
counting to happen quickly in the single threaded case.
And that made fantastic sense 30 years ago.
Now that we're sitting here with our 16 and 32 core CPUs, all of a sudden, we might want
to run more than one thread and get stuff done.
You know what I mean?
Yeah.
That's the history of the GIL.
And so there were other things like Larry Hastine.
He was there, right?
Yeah.
Just to interject for a second.
It's really fun to see sort of how long a project has been to try to remove the GIL.
You can go back 10 years ago and there's a talk by David Beasley on weird things going
on with the GIL in 2010.
And then I was writing this after the summit, looking through the archives, past language
summit bloggers.
I think there's like three successive years running where there's presentations about
the latest project to remove the GIL.
But like this time, it actually seems like it could happen.
It's really cool.
It could happen.
Yeah, it certainly could.
Sam Gross's work seems to be the most likely candidate.
And all the other attempts, their challenges have been, yes, you might remove the GIL and you
might make the parallel computing faster, but you're going to make single threaded Python
so much slower that it's, we don't want to accept it, right?
If you could say, well, you can use core, you can use all the cores on your machine, but
now everything runs half as fast.
That's not a huge benefit to a lot of people.
Yeah.
And especially because, because of the fact that the guild's been there for so long,
the vast majority of Python code is with only one thread, right?
So it's like, well, it could make your Python code faster, but only if you rewrote all of
your code, which not many people want to do.
True.
The other major problem or challenge that is there is how does it work with the C extensions
that are so important to making Python work well, right?
NumPy and all those types of things, right?
Yeah.
So Larry Hastings was there and he worked on the Galectomy, which I think is still the
best name of all these projects.
The Galectomy.
Yes, definitely.
Yeah, but it sounds like he thinks that Sam's project is already farther than his.
This portion of Talk Python to me is brought to you by Reflect.run.
Reflect is the fastest way to create end-to-end tests for your web app.
Most of us have encountered flaky, unreliable tests over the years.
For a lot of us, testing our code is painful, but it doesn't have to be.
Reflect was created by developers who are tired of dealing with constant problems inherent in
code-based testing tools for web apps.
Reflect is an automated, no-code testing tool that enables you to shave countless hours off
your end-to-end testing timeline.
If you can browse the web, you can create sophisticated tests with Reflect.
navigate to your site within Reflect's simulated browser and perform the actions you want to test.
Reflect will auto-generate selectors and do the painstaking work of test creation and maintenance
for you in minutes.
Instead of creating and maintaining a separate code base for your tests, you can manage all of your tests within Reflect.
Features include visual validation, efficient for debugging and eliminating weights, cross-browser testing, run tests across all modern browsers,
including Safari, Chrome, Firefox, and Edge, and email and SMS validation.
The best way to appreciate what Reflect can do for you is to see it in action.
They put together a nice six-minute video you can watch at talkpython.fm/reflect dash video.
That's reflect dash video.
I encourage you to watch it and see how straightforward and composable their tool is to use.
Once you're ready to try it out, sign up at talkpython.fm/reflect.
And as a special offer for Talk Python listeners, you'll get a free t-shirt when you sign up through this link.
That's talkpython.fm/reflect to see how easy web testing can be.
The link's in your show notes.
Thank you to reflect.run for supporting the show.
Maybe tell us a bit about what Sam was proposing there.
So yeah, Sam has got this fork of cPython where he has removed the GIL and it all works.
I think, you know, there's still a few rough edges, but it all basically works essentially.
So now he is looking to...
So if you want to, you can try that right now.
You can go and download Sam's blog, new gill, and most Python programs will run fine on it.
That's it right there.
Yeah.
For those watching...
Yeah, I'll put a link in the show notes.
Yeah.
People can check out the GitHub repo and it's just a fork of Python, of cPython, and then goes from there, right?
Yeah.
And now Sam is hoping to essentially create a separate mode of cPython that you can enable with a compiler flag,
which would enable new GIL.
So to get his changes merged into the cPython main branch, essentially.
So that would mean you would have to build cPython separately in order to get a version of cPython when no GIL would work.
So it wouldn't be like you'd be able to just open up the repo and go like, import no GIL.
It wouldn't be quite that easy.
Right, right.
It is a bit of a hassle that it's literally a separate compilation step, a separate binary and so on.
But maybe it could ship.
Maybe the cPython distribution, if this really works out well, could be shipped with that.
Like it could be a set of Python or Python 3 or whatever you type.
It could be Python ng or something like that.
You know, like some extra command you can run.
But at least it would be nice at least if you didn't have to literally go find a different installer and try to avoid the name clashes of what Python means, you know?
Yeah.
Yeah, for sure.
And this is a change from his original proposal.
So his original proposal was for a runtime flag.
So that would mean that you would be able to, I don't know.
I don't know how exactly it would work, but do something like import no GIL.
Yeah.
And reading your write up here, it sounded like Sam has come to the conclusion that there's too many differences for a runtime flag to make sense.
And it's got to be a compiled type of thing.
Exactly.
So yeah, that was his proposal.
How was the reception?
There were a lot of questions for Sam.
So I think there were, I think like a few of the other proposal presentations finished under time later on in the summit.
And then we went back and asked some more questions to Sam because we still have questions.
Yeah.
So I think everybody in the room definitely knew.
So like it's crazy.
If you look at the viewing figures for these blogs, like the blog on no GIL is off the charts in terms of how many people have clicked on it and read it.
Interesting.
Okay.
So it's like, the last time I checked, it was like 40,000 people had read the no GIL article and the next highest was 5,000 people.
Wow.
There was a huge amount of interest in this feature and the people in the room knew that there was a huge amount of interest in this feature.
So I think there's a lot of interest in making this work if it can be made to work.
Sure.
But there's just a lot of complications about how to get that.
So there were a lot of people asking what exactly the plan is here because it's this huge project that Sam's been working on for months and months.
And how do you merge that into cPython?
You know, you obviously can't have one PR where you have tens of thousands of lines of code changed all it was.
So how do you split that up?
You know, how do you...
I think Sam was looking for a kind of pre-approval before submitting a PEP.
I think some people were reluctant to...
Right, right.
Just taking the temperature of the room to see if it was just...
Yeah.
If it was welcome or unwelcome, right?
I think the general mood was sort of cautious, if that makes sense.
Yeah.
Like, yes, we'd need to set the plan before we give our stuff.
Yeah.
That was the kind of vibe I got.
Okay.
There was some feedback, like from Barry Warsaw and Itamar Osterker about the impact it might have on third-party libraries.
I think Carol Willing also talked about that because especially these C layers or these native code layers are super common in the data science space, especially.
So, yeah, some conversation about that, right?
Yeah, I think there's a lot of concern about with some features new to the language, for example, with typing was added a few releases back.
I'm very involved with the typing community.
I'm a massive fan of typing.
I am too.
Fan, not involved.
Sure.
But, you know, it's kind of got a little bit of a bad name for itself in some ways because there's some people who go to maintainers and demand that typing to be added or whatever.
Right.
And that's not really felt on the maintainers because everybody's volunteer doing it for free.
It is getting easier because one of the holdups used to be, well, my library is for Python 2 and 3 and I'm not going to maintain two versions and so on and so on.
Right.
So, the typing wouldn't work in Python 2.
At least now we're generally past that holdup.
But still, yeah, it's effort that the person might not want to put out there.
I'm a TypeShed maintainer.
Yeah.
I'm very involved in typing.
So, yeah.
Tell people about TypeShed.
TypeShed's pretty cool.
Oh, sure.
So, TypeShed is the repository of stubs for the standard library and also a bunch of third-party stubs.
So, TypeShed is like the only version of the standard library that mypy knows or PyWrite or PyType or any other type checker.
They don't actually know what's going on in real standard library at all.
They only know this bundle of stubs and TypeShed.
They don't feel like I'm explaining it very well.
Yeah.
So, you know, I'll pull it to one for app pairs.
And people, these are not PY files.
These are PYI files.
Yes.
And if you look at them, the implementation is super straight.
Information?
I don't know.
The implementation of all these is super interesting because all the functions are dot, dot, dot.
And the default values are dot, dot, dot.
But what you have is you have function name, variable name, type, return value, type, or class, field type, field type, field type, field type, right?
Yeah.
So, it's like a Python file would like...
Yeah.
I suspect some people don't even know that this is a thing you can do to improve the understanding of editors and stuff, right?
In mypy.
A static type checker will use this information to inform the, like, the errors that's flagging on your file if you use it to check a file.
So, if you import appders in your Python project and you install types appders, then mypy will use the type in some type check to understand, ah, okay, this app does instance has an app name.
Oh, interesting.
To add the address of type checker.
Do you know what the editors do?
Like, does PyCharm already have this information?
Does VS Code already have this information from other sources or behind the scenes?
So, PyCharm...
VS Code does use type checker completely.
PyCharm, I think, mostly uses type checker now.
It was kind of...
They used to have their own way.
Yeah.
I think it was a bit of a journey for them to move to type checker.
I'm not sure if they 100% do yet, but yeah.
Okay.
Yeah, very interesting.
Let's see.
We were talking about the CPython stuff and Mr. Hypermagnetic asked, will CPython ever become Rust Python?
They also pointed out that type, hence, saves lives.
Saves lives.
It's great.
But back to the first question.
Did that come up?
Did Rust ever come up?
My first thought is that's a pretty far bridge, but did it come up?
There is already Rust Python, I think.
You can go and use that if you want.
Sure.
I think it's quite a long way from becoming the default, like default, you know, from becoming the leading version of the reference implementation of Python.
Yeah.
Okay.
We can come back to that in a little bit because it'll circle its way back a little bit.
Yeah.
All right.
We're halfway through the show and we've got one of our items done.
Fantastic.
Yes.
Let's go to the next one.
No, we'll pick up speed as we go.
Yeah.
This next one is a per interpreter gill, which actually has been a little bit around from PEP 684.
And it's still in draft mode from Eric Snow.
And so this also goes back to dealing with the GIL.
And it tries to, instead of remove it, say, well, you know what the GIL does is it makes you have single threaded code.
So what we're going to do is if you want to run a thread, you just start a new sub interpreter in the same process.
And sure, it has a gill, but it's meaningless because there's only one thread per interpreter.
And so it's a way to kind of sidestep that problem, right?
Yeah.
It's kind of funny.
So the first talk is like, yeah, let's get rid of the GIL.
And then Eric comes along and says, but what if we had lots of gill?
The problem is the GIL is shared.
Yeah.
Although we got to rename it if there's a per interpreter GIL.
Yeah.
It's not globally, right?
It should just be a per interpreter ill.
The gill, the g part, the global doesn't make sense anymore.
A pill?
Yeah.
A pill?
Yeah.
That sounds a little bad.
But it's interesting to point out, you know, like you pointed out in your article here, that back in 1997, you know, posted something saying, massive changes for separate thread state management.
All per thread globals are moved to a struct, which is manipulated separately, you know, basically trying to do the same thing.
And it turns out, though, that through another picture that you've got laid out here, there's actually a lot of global state shared across threads and different things, right?
That's the problem.
I think if I understand it correctly.
So, I mean, I'm angry mouth.
It's wrong.
I have had him on the show before, so I'll link to that episode as well.
I think it is possible now to run multiple interpreters within the same process.
But it just doesn't work very well, if I understand correctly.
So, it's like, you know, running to all sorts of problems, which, web safety, and, yeah, various conditions.
Okay.
There we go.
Interesting.
Yeah, so it sounds like he's been working on this for a long time.
I think you opened with a funny quote.
Hopefully, the speaker began.
This is the last time I give a talk on this subject.
He's been working on it since 2014.
Yeah.
I think at the time he gave the talk, he was hoping to get it in for 3.11.
But didn't quite make it.
Yeah, exactly.
So, maybe it'll be 3.12.
Yeah, because 3.11 is already frozen.
Yeah, and it's still in draft mode.
Okay.
So, that's a good one.
People can check that out.
There's a tension between many of these projects in that the optimizations one are making might be complicating the work the others are doing.
Yeah.
And that's also true for the next one here, which actually, I think, is the biggest news of Python 3.11.
I completely agree.
Performance improvements.
Yeah.
Performance improvements for 3.11.
I feel like it's a shame that so many more people read the no-kill one than this one, actually, in a way.
Yeah.
But, you know, I've been watching a C-Python repo.
I know how much work has been going into this.
And I think it's really impressive.
Yeah.
So, essentially, the top-line news from this is Python 3.11 is going to be about 25% faster than Python 3.10.
And this is mainly a result of implementing a PEP by Mark Shannon.
Not sure I can remember the number of the PEP.
It's known as the Shannon plan.
Yeah.
I'm making Python five times faster over five years or something like that by doing, like, this 1.25x per year, which they did it this year.
That's incredible.
The main chunk of this is that there are loads of, like, small optimizations that have gone into this.
But a lot of them have to do with implementing what's called a specializing adaptive interpreter.
Okay.
What does that mean?
What is that?
So, this is essentially an interpreter that monitors your program as it's running and spots if you've got, like, an inefficient bytecode that can do lots of different things.
So, like, maybe it's an add bytecode that could plausibly, I'm almost settling in and get some details wrong here.
But, you know, maybe it could add two lists together or add two ins together.
You know, it's just like a generic add bytecode.
And then the specializing adaptive interpreter will spot, oh, hang on.
Okay, we're in a tight loop here.
Only numbers are being, only ins are being added here.
We can replace this bytecode with a more specialized one, which will do the same thing faster.
Yeah, because there's probably a lot of checks and different types of bits of indirection to let it add strings and lists and so on.
But if you know it's numbers, then just do the number thing without the checks.
Exactly.
So, that's known as quickening.
So, like, as the program's running, specializing adaptive interpreter quickens your code and replaces the bytecode with a more specialized one.
This portion of Talk Python to Me is brought to you by Microsoft for Startups Founders Hub.
Starting a business is hard.
By some estimates, over 90% of startups will go out of business in just their first year.
With that in mind, Microsoft for Startups set out to understand what startups need to be successful and to create a digital platform to help them overcome those challenges.
Microsoft for Startups Founders Hub was born.
Founders Hub provides all founders at any stage with free resources to solve their startup challenges.
The platform provides technology benefits, access to expert guidance and skilled resources, mentorship and networking connections, and much more.
Unlike others in the industry, Microsoft for Startups Founders Hub doesn't require startups to be investor-backed or third-party validated to participate.
Founders Hub is truly open to all.
So, what do you get if you join them?
You speed up your development with free access to GitHub and Microsoft Cloud computing resources and the ability to unlock more credits over time.
To help your startup innovate, Founders Hub is partnering with innovative companies like OpenAI, a global leader in AI research and development, to provide exclusive benefits and discounts.
Through Microsoft for Startups Founders Hub, becoming a founder is no longer about who you know.
You'll have access to their mentorship network, giving you a pool of hundreds of mentors across a range of disciplines and areas like idea validation, fundraising, management and coaching, sales and marketing, as well as specific technical stress points.
You'll be able to book a one-on-one meeting with the mentors, many of whom are former founders themselves.
Make your idea a reality today with the critical support you'll get from Founders Hub.
To join the program, just visit talkpython.fm/founders hub, all one word, no links in your show notes.
Thank you to Microsoft for supporting the show.
Have you heard of Grant Booker's specialist project?
No.
So, if you look that up on GitHub, it's a project that he published a few weeks ago, I think, and it's really cool.
You can see, it's like visualizes the way Python 3.11 will quicken your code that it's running.
So, I'll send you a pass and link.
Yeah, yeah.
Send your link.
Yeah.
Tomer points out that they've been following the faster CPython repository.
And yeah, I'll link to that as well.
You know, Mark Shannon and other stuff.
The ideas for making CPython faster over time and different things.
Yeah.
So, yeah.
Very cool.
Yeah.
So, that does like the ideas hub with all.
Visualizing.
It's specializing adaptive interpreter.
Okay.
Yeah.
All right.
Very interesting.
So, this is the thing.
Pip install specialist is a thing you can do.
And then it'll what?
It'll show you like a printout of the code where it's actually found improvements?
Exactly.
So, it'll show you where it's quickened your code and where it's been unable to quicken
your code.
So, I think the green bits here, specialist has, yeah, quickened those bits of code.
But the other bits, it's been like, yeah, don't know what to do here.
Got to leave it.
I said it.
Couldn't do anything.
Yeah.
So, for people listening, if you just pull up the specialist GitHub repository, which
I will put in the show notes, there's a bunch of pictures and colorized code showing you
where Python 3.11 was able to make it faster and where it wasn't.
This is super cool.
I never heard of this.
Yeah.
And this is a project by Brant Booker, who's been one of the major collaborators on the
FasterCPython project.
Right.
Coming from the top.
Yeah.
What also is neat is this is not just for 3.11.
3.11 is the first step.
They're like only halfway through.
Yeah.
3.12 is currently.
It's pretty well funded, too, right?
Like, Microsoft has, I think, a team of six people possibly working with Guido and Mark.
Sounds about right.
And then also Bloomberg has contributed some resources or some help.
Yeah.
It's really got a lot of speed here.
A lot of inertia behind it, I guess I should say.
And speed.
Absolutely.
All right.
This one, actually, I think this is the big news.
I know that it probably didn't make the biggest splash of the headlines, but.
I think it's going to, yeah, because this is going to make everybody's code
faster.
It's not like one small micro-optimization.
It's across the board.
Right.
Yeah.
The threading stuff is very exciting and interesting, but I'm going to go out on LM and say, I think
a lot of people think they need it or they think they want it more than they actually
need it.
So, for example, if you're running a website with APIs and stuff, you know, G Unicorn or
Microwave's Geek or whatever, they all spin out a bunch of worker processes and you can
have several worker processes per core, meaning you're already like saturating every core of
the CPU.
You know, so in those scenarios, it's nice, but it doesn't help that much in terms of, you know,
a lot of stuff that you don't really need the threading.
On the data science side, you might, but at the same time, you often, you're doing the computation
in C or you can use async and await if it's IO bound.
There's a lot of ways where this problem is actually already solved.
It just doesn't feel like it's solved.
And so this one though, this fix it, this makes multi-threaded code faster, single-threaded
code faster.
It's just, it just makes all the code faster, which is great.
This could be a given at a run for the money.
You know, when the listener asked earlier about Rust being the reference implementation
for CPython, well, what is it then?
RPython?
I don't know.
Maybe CPython isn't the name for it anymore.
The reference implementation for Python.
This one here, Python in the browser, could put some pressure to move in that direction.
Right?
So this one has to do with WebAssembly.
Tell us about this.
For a while now, there's been a project called Pyodide, which has been like a third party project,
which has been monkey patching, essentially, CPython to get a version of CPython running in
the browser.
Pyodide has been the basis for several cool projects, which are all sort of just starting to take off
now.
I feel like we've sort of reached this like critical point where it's all the finest of
starting to fit together and make sense.
And over the last two years, Christian Himes, co-developer and contributor Ethan Smith have
been working to upstream loads of these changes that Pyodide has been making to CPython itself,
which would mean that Pyodide doesn't need to monkey patch CPython nearly so much anymore.
And so I think that's actually will just work in the browser, which would be huge.
Yeah, that's fantastic.
There were a bunch of changes made to make this possible.
And I can't remember where in the article you said, but yeah, over 60 PRs.
Yeah.
And a GitHub issue, right?
That's one.
We just like see the numbers.
Consider supporting mscripten slash WebAssembly as a build target.
And guess what?
That's not a thing.
Now you can actually go in and say --with inscripten target equals browser as to compile
CPython.
And that's a big deal.
I think it's going to make it possible to use Python where you would have otherwise used
JavaScript.
For sure.
So I think this is possibly one of the biggest gripes that anybody using Python for web development
has.
And then have to like use JavaScript.
Yeah, people will say sometimes to me that I'm being mean or inconsiderate or something
when I say that we might not want to write in JavaScript.
You're like, why are you hating on JavaScript?
I think the frustration that a lot of people feel in the software industry is not that they
necessarily hate JavaScript, that JavaScript is the only option.
Like there's almost nowhere else in programming where we go, there's one language and one runtime
and that's it.
That's all you get to use, period.
Right.
On the desktop, on embedded, on the web, like on, you know, server side web, like you
can pick tens of languages at least.
Right.
And you pick the one that works well for you and the one you like.
And except for in the browser, everyone is forced to do this one language, which is frustrating.
And so as Python developers, where we like Python, it would be great if we could continue to use
a language that we prefer for things like this.
Right.
Yeah.
And now you can.
There's a few challenges with this.
One is that the WebAssembly binaries are a bit large, not huge.
They're not huge, but they're like five or 10 megs instead of 50k.
So that's a bit of a challenge.
But there's places where this is already highly valuable.
So for example, if you're doing like an Electron JS app, you could write that largely in Python
using this stuff already.
And it doesn't matter because you already downloaded an entire copy of Chrome.
What's another 10 megs?
You know, is it 200 or 205?
Like, I don't care.
It's the same.
Yeah.
I think Simon and Willison might have done that a few weeks ago.
Okay.
I created an Electron JS app with PyScript?
Yeah, I think so.
I'll have to look into that.
That sounds really fantastic.
Let's see.
So this is cool because PyIodide is great, but it's like this sort of project maintain
alongside CPython.
And this is saying the core developers and the team behind Python are allowing you to just
compile a limited version directly, right?
So PyIodide could say build on top of this one and not have to maintain their own copy.
Exactly.
Yeah.
So we do need to be careful here.
Like, it's mscripts in the WebAssembly are not fully supported by CPython yet.
There was a lot of concern about that at the summit.
Like, if we say it's supported now, then it's a big statement to put out there.
So definitely not fully supported yet.
Yeah.
Okay.
Good to point that out.
And there's plenty of things that are not supported because they're probably not just
haven't, they're not ready.
Some things that will never, ever be supported.
Like TK Enter support is probably never coming to the browser.
Yeah.
You know what I mean?
Or other things that are not permitted by the browser's sandboxing rules and so on.
Anything that can be run in the browser needs to be extremely security conscious because
nobody expects to have arbitrary code execution on the browser.
It sounds very, very suspicious.
Like, you're going to let me run binary code in the browser, but it's subjected to exactly
the same rules as JavaScript.
And JavaScript gets JIT compiled to binary code and then run anyway.
It just feels better that it's like, oh, here's a script.
It's like, no, it's the same thing.
So very cool.
I do want to just point out, give a quick shout out to PyScript, which you also did in
your article.
This is super exciting.
This takes it and makes it way, way more real.
This is where you really do put Python in the browser.
This is built on top of Pyroidite, I think.
Yep.
Just enables you to embed Python inside an HTML file.
And it just works.
Yes.
Yeah, it works pretty well.
Opening tag, py-script inside an HTML file.
And don't need to download anything.
Yeah.
Pretty incredible.
You can also say source equals app.py in your browser.
And as long as that can be delivered as a static file, it'll pull that up and run.
I just, quick follow up on this.
No, this is a different one.
I'll roll it.
But I do want to point out that I actually, I don't know if people know this.
I did a video called Python PyScript WebAssembly.
And then I actually created an offline progressive web app with it.
So once you've installed this app, it no longer has to download that larger binary.
So if you look at the code, it's like super, super simple.
You can get this cool little offline app.
And it is like launch time, you know, down to one second, maybe one and a half seconds.
And it's just so bizarre to write Python for like JavaScript events.
So you can say like on click equals here's the Python function and all sorts of stuff.
So people can check that out.
I'll link that in the show notes.
This is a really big deal.
This WebAssembly stuff that's coming in.
It's coming from these different angles.
It's coming from Pyodide, from PyScript, from the core developers compiling to WebAssembly.
All of those things are pretty fantastic.
It's really cool to see so many people collaborate on the same thing at once.
From seven different parts of the community.
It's true.
It's happening.
There's two parts where that's happening, right?
In this GIL thing and in the WebAssembly side of things, right?
They're not necessarily coordinating, but they're all working on the same problem.
And surely we'll get some good outcomes from that.
All right.
Let's talk about the Cinder one next.
So this one does come also from Meta and more Instagram, I suppose, directly.
But this comes from the Cinder project.
And this has to do with some of the optimizations.
You want to tell us about this one?
These are essentially async specific optimizations.
So Cinder, for those who don't know, is a performance-oriented fork of CPython.
So the Instagram team essentially were like, we really love Python, but it's a bit too slow for our web servers if we're going to have the whole thing written in Python.
So they forked it and implemented.
There's a ton of different optimizations implemented in Cinder.
Many changes.
Yeah.
There's a ton.
If you check out the Cinder project, there's just a whole list of all these different things.
Some of them have to do with JIT.
Some of them have to do with immortal objects and some have to do with other things as well.
Yeah.
Async IO.
Lazy imports.
Yeah.
Loads of stuff going on.
Yeah.
With all the attention recently on making Python faster, the Cinder team is hopeful that they will be able to get some of their optimizations merged into the main drive to Cpython.
So this presentation was specifically about some of the async specific optimizations that they have been implementing in their fork.
So essentially, the issue is to do with eagerly awaited coroutines.
So if you have coroutine, then generally, if you have a coroutine function, you'll call that function.
It will create this coroutine object.
That coroutine object doesn't do much until you await it.
And then eventually you get the result back.
But that can be inefficient in some situations.
Because if the task being done in the coroutine can just sort of finish immediately, then there's no reason to create that coroutine object.
Right.
And to schedule it and to do all the stuff on the loop and then wait for it.
All of that is just overhead.
What's done in the Cinder fork is they detect when a task can be immediately finished and don't bother correcting the coroutine object in that case.
So let me see if I can come up with an example for people that might make it concrete.
Kind of complicated.
Yeah, no, it is.
But I think once you get this feel for it, it's no problem.
It's not that bad.
Probably bad to implement, but not bad to understand.
So imagine you have an async function that's going to call an API, but you might have an in-memory cache that says, have I already looked this up for this particular argument?
Right.
So your code could say, if this value is in the cache, just return that value.
Otherwise, await HTTPX get da-da-da-da-da.
Right.
So that first case where you call something that's in the cache, by default in Python now, it's going to still schedule that on the loop and it's going to make it run on the loop and wait for all that to happen in this inefficient way.
So the optimization is like run it as a regular function until you hit an await and then go through that process.
Something like that, right?
I think so.
That's my understanding.
And people can send me messages and let me know I got it wrong.
But I think that's the basic idea.
There's scenarios where, in my case, if it's in the cache, it doesn't ever really need to be treated as a async coroutine ever.
You just get the value back like a regular function.
But if it goes past that, then it does need to be one.
And that's the distinction, I think.
Okay, cool.
So there's actually a lot of improvements and performance things coming from the Cinder project.
There's this one, but there was also the lazy imports, right?
PEP 690 and that one and so on.
On discuss.python.org, there's been a, I think a discussion has reached to over 100 comments now on lazy imports.
So if you have views, that is where to send them.
Absolutely.
That's a whole different proposal where you could, we should introduce an API to enable or disable lazy imports.
So with lazy imports enabled.
So at the moment, all imports in Python are eager.
So if you type in import functools at the top of a file, it will execute the entire functools module and then put a reference to that module in your file for you.
Whereas with lazy imports enabled, it would see the import functools statement.
It'd be like, meh, not going to do anything with that.
And then wouldn't actually import the module until the first time functools was referenced later on down the file.
Right.
Because the problem is there's a cost for doing an import.
It's not like a hash include, which might be a compile time thing.
There's an actual runtime cost for every import.
So PEP 8 says all the imports go at the top to keep them orderly.
But if there's many apps that might or might not use some import, depending on what part of it runs.
Right.
Yeah.
And so if you could delay that, that expense only if you use it, that would be great.
And this can have a major impact on startup time for Python CLI apps.
Yeah.
Especially.
Yeah.
The one that we were talking about is this ASIC optimization.
So that's the one that was actually covered, but it's just one of the things coming out of Cinder, which is cool.
Yes.
And then I think maybe this path forward for immortal objects.
Is that also coming out of Cinder?
Sounds like it.
No, that's another one.
Similar, but not the same.
This is linked to the current up to Gil talk, essentially.
Okay.
This is one of those proposals that's kind of very much in the weeds of how Python is implemented.
So it's a proposal to introduce what's known as immortal objects.
So an immortal object is, well, an object that never dies.
So generally in Python, as we were talking about earlier, objects have a reference count.
And if that reference count reaches zero, then the garbage collector comes along eventually
and deletes it, freeing out memory that was holding that object.
So this path proposes introducing a class of objects where the reference count would never
reach zero, meaning that the object would never be cleaned up by the garbage collector and would
never die.
So this would have the advantage.
Yeah.
Because why are you bothering to like check and check on these objects that you know will
never, ever have any sort of reason to go away?
Right.
So like there's the non-singleton, for example, like it would be quite rare to have a program
that doesn't use none at least once.
Or the number five, which is pre-allocated, right?
As well as the number 200, like the first, the last, the first negative five in the top 255
or something like that.
Yeah.
But nonetheless, Python will like doggedly keep a reference count for these objects and
like track where they are.
Yeah.
So for a lot of these, yeah, pre-allocated object numbers, in terms strings, the empty
tubal, I think is also singleton, the non-singleton.
These would all become immortal objects if this path accepted.
And that would, I think in the short term, make Python a little bit slower, probably.
So I think a naive implementation makes it slower by around 6%.
But with mitigations, you can make it so that performance impacted is marginal.
But then if you do implement immortal objects, there's, it makes things like a paratexta
gill easier.
It might also simplify no gill, I think.
Yeah, probably.
Because once you know something's immortal and probably also immutable, then you can share
it all you want.
Yeah.
Exactly.
Yeah.
So you don't have to worry about.
Yeah.
So some of that state that's really hard to create one per interpreter, you're just like,
well, it doesn't change.
So here it is.
Yeah.
You don't have to check it either.
Yeah.
Cool.
It just kind of makes sense when you think about it in a way, I think.
You know, like, why would you track the reference counts for all of these objects?
Exactly.
You know, like, true and false are never going to be gone.
So just forget it.
Just leak that memory or whatever, right?
Yeah.
All right.
Let's see.
What else we got to cover here?
Maybe the issues and PR backlog?
Sure.
It's one of the, I think that's the longest one.
Okay.
Yeah.
This is a pretty interesting aspect because it has to do with the developer in residence
and Lucas Lange and all the improvements that having somebody dedicated to that role has
brought, right?
There are a lot of open issues and open PRs on CPython.
But this talk was actually kind of taking a step back and looking philosophically about
it and sort of saying, well, what is an issue for?
You know, why there's all these issues.
Some of them haven't had activity on them for five years or whatever.
Like, why is that issue still open?
Like, what is that doing for us really?
And also, I guess, really quick shout out.
This is from Edreet Catrail.
Yes.
This talk.
So I think it's like two perspectives, right?
You see the person who, when they open their phone at the bottom, it has 26,214 unread messages.
The first is inbox zero.
Like, you know, it's like, well, if we can't close this issue and we can't deal with it within
five years, it's just friction.
That's one side of the argument, I suspect, is it's friction.
The other people are like, well, this is history.
Yeah.
Historical friction.
What do we do about it?
Sahih Spachaka, one of the most prolific SuperIcon core developers who's contributed more to
SuperIcon, like I'd say.
You're sort of saying, well, you know, sometimes I do come back to issues after five years.
I do.
I am planning on working on it, but I'm working on a lot of things and have hundreds of local
branches and I'm working on loads of things at once.
And sometimes I forget about something for five years and then come back to it, which is
totally fair.
It is fair.
But I don't think like one person isn't going to fix all of those issues.
You know, when you've got, how many is it now?
See, six, over 6,500 open issues on the CPython repo.
Yeah.
I don't know how I actually fall on this.
I mean, on one hand, I totally get that you want to keep it around.
On the other, if it was something really important, it would probably resurface again anyway.
You know what I mean?
Like...
No, I completely get that.
I think at the moment, my personal opinion is we do have too many open issues at the moment.
And a lot of them just aren't ever going to have...
Either aren't going to get fixed or like, if they are going to get fixed, it's not because
of the issue being open.
Like somebody else will just come along and be like, I'm going to fix this now.
It's on GitHub now.
You could apply a tag to it like closed due to old age or something.
Yeah.
And then just close them.
They can be reopened.
People could go, well, I really want to see all the ones that were closed due to old age,
plus the ones that are open.
You know, just create a search that shows that view.
Somebody's really bored and is like, I really want to fix some Tkintered feature requests
20 years ago.
We can scroll through those.
Yeah.
Yeah, for sure.
Okay.
It's an interesting conversation and discussion and what to think about, but it's not something
that directly affects people.
Like that's the perfect kind of thing that's like handled at this meeting, right?
Because it's really about those folks.
Yeah.
All right.
The final one, the F string grammar.
We got f-strings in Python 3.6 and it's one of the most popular languages added recently,
language features.
Everyone loves it.
I've heard people upgrading to 3.6 and beyond or throwing away old versions just so they can
write f-strings, which is great.
But it turns out that the actual parser for f-strings is kind of insane.
I had no idea.
Tell us about that.
I think it was how many lines of code is it?
I think it wrote it in the article.
1,400 lines of custom C parser code just for f-strings that's separate from the regular parser.
This whole file is just manually handwritten C code to parse f-strings.
And Pablo brought up this crazy slide on that.
This talk is by Pablo.
And the Salgado.
He is a core developer, steering council member, and lead manager for Python 3.10 and 3.11.
So this is his big project.
So yeah, Pablo brought up this crazy slide showing the dance that the interpreter has to go to
whenever it encounters an F string.
It's like a passed.
It sounds really tricky to figure out because you've got all the captured variables.
You've got to figure out how to pass those over.
Then it goes to the parser and it's like, oh, geez.
Okay.
Yeah.
So what is the idea?
The idea is to make this part of the regular parser?
Just move this over to bring it into the peg parser and all those kinds of things.
Okay.
Yeah.
So since Python 3.9, Python has had a generated parser.
So you just write all the grammar rules down in this file according to a mini language for
the grammar.
And then the program will generate a very large C file to parsing Python according to those
rules.
So it's a much nicer way of doing things.
It's much less error prone.
Just generate all the C code instead of writing it all out.
And so Pablo's big idea is, yeah, let's just move all this F string parsing into the grammar.
Do it all at the same time as that.
Be much cleaner.
It's nicer to maintain.
And it also has some exciting things for users.
It will mean that the code team will be able to do some big work on improving error messages,
for example, for f-strings.
It's currently quite hard to do because if you touch one corner of this C file, it could have
a chain reaction to the rest of it and cause you 10 bugs and nobody wants that.
Yeah, that's great.
That's one of the other areas of focus there has been lately on improving error messages.
That's good.
Yeah.
310 had improvements just in general for error messages.
Yeah.
Maybe that also comes from the peg parser, right?
Like maybe that's related.
If like the peg parser already has better error messages and you can get this into the peg parser,
it'll just bring along better error messages more easily.
So the peg parser is smarter than the old parser has.
So like the old parser couldn't like look back when it encountered the syntax error, essentially.
So like if it encountered the syntax error, it would just kind of throw up its hands and die on you.
Whereas the new parser is able to catch the syntax error and then kind of look around context
and then give you a better message using that context, essentially.
That's great.
Yeah.
Yeah, yeah, sure.
I think that pretty much covers it.
Anything else you want to mention to people about the Language Summit?
You wrote it up pretty well, I think, but there's something else not in there.
Pythons.blogspot.com.
It's the address if you want to read that.
Yeah, for sure.
I'll put the article in the show notes.
I think we've pretty much covered everything.
We've covered a lot anyway.
Yeah, we have covered a lot, Alex.
That's great.
All right.
Well, thanks for all of this and all your work on the other things as well.
Before we get out of here, let me ask you the final two questions.
If you're going to write some Python code, be it 312 or something new or older,
what editor are you using?
I'm actually using Idle quite a lot these days.
Yeah, right on.
I've used Pyjarm for a while.
I've tried out VS Code several times.
I've never really got on with it.
I'm not quite sure why.
Yeah.
I loved all the features Pyjarm had, but nowadays I'm just enjoying something that just starts
up really quickly.
And it's just really simple.
Something simple.
All right, cool.
Yeah.
And then notable PyPI package or library, something you want to give a shout out to?
I mean, we kind of sort of did that in a meta sense with TypeScript or TypeShed, rather.
Yeah, am I allowed to shout out my own package?
You can shout out whatever you want.
Absolutely.
I'll just give another shout out to Specialist, I think.
I think that's really cool.
Yeah, Specialist is neat.
I'm glad I learned about that today.
That's cool.
All right.
Well, I can seem magnanimous by shouting out somebody else's project.
There you go.
All right.
Well, thanks for doing the write-up.
Thanks for taking good notes and sharing it with everyone.
Because while it makes total sense that the Language Summit is this closed-door story where
people can have open conversations and just keep it amongst the core developers, I know
everyone in the community really appreciates having a sense of what's coming, where the focus
is, what people are worried about, and so on.
So thanks for getting that out in the light for us.
Yeah, no worries.
It was fun to do.
Yeah.
Really fun to have this conversation.
Yeah, you bet.
Thanks.
Awesome.
Thanks, man.
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.
If you can browse the web, you can create sophisticated tests with Reflect.
Navigate to your site within Reflect's simulated browser and perform actions you want to test.
Let Reflect handle the painstaking work of test creation and maintenance.
Sign up and get a free t-shirt at talkpython.fm/reflect.
Starting a business is hard.
Microsoft for Startups Founders Hub provides all founders at any stage with free resources
and connections to solve startup challenges.
Apply for free today at talkpython.fm/foundershub.
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.
Thank you.
衝き心惑
Thank you.