Python has come a long way since it was released in 1991.
It originally released when the standard library was primarily the totality of functionality
you could leverage when building your applications.
With the addition of pip and 368,000 packages on PyPI, it is indeed a different world where
what we need and expect from the standard library is not the same.
Brett Cannon and Christian Himes have introduced PEP 594, which is the first step in trimming
outdated and unmaintained older modules from the standard library.
Join us to dive into the history and future of Python's standard library.
This is Talk Python To Me, episode 360, recorded March 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 Microsoft for startups founders hub.
Check them out at talkpython.fm/founders hub to get early support for your startup.
And it's brought to you by Fusion Auth.
Your authentication and authorization platform built for devs by devs.
Check them out at talkpython.fm/fusion auth.
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.
Brett, Christian, welcome to Talk Python to Me.
Thanks for having us.
Yeah.
Thank you.
First time for me.
Yeah, Christian, it's great to have you here.
That's super.
And Brett, I think you may have been on before.
Memory recollects.
Yes, I have been on.
I have been on previously.
I love having you on.
It's always fun to talk about stuff.
And it always seems like somehow we touch on WebAssembly.
I think one of the very last conferences I went to was PyCon and we recorded like on the
expo floor talking about WebAssembly.
So maybe we'll find a way to get back to that.
I do remember that conversation very distinctly, actually.
Yeah, that was fun.
Even though you've been on a lot, maybe just real quick, tell people about yourself.
You've been Python core deving for a long time and something to do with VS Code and Python
as well.
So tell people about that.
Just stuff.
Yeah, just keep it short and sweet.
I am the dev manager for the Python experience in VS Code at Microsoft.
I have been a Python core developer for 19 years.
And I've been a member of the Python Steering Council since its inception back three and
some odd months ago, I think.
I don't even keep track of when that started.
Yes.
And that's me.
Awesome.
Christian, how about you?
Tell people about yourself.
I work for Red Hat.
You may have seen that.
So first...
You have a Red Hat and you work for Red Hat.
That's awesome.
Yeah.
At Red Fedora, by the way.
So I work for Red Hat in the security engineering department.
I work on something that could be easiest to describe as an open source implementation of
Active Directory.
And currently working on just containerizing all the things and getting that up to the internet.
So that's a fun one.
As part of my security work, I also do security for CPython.
So I take care of some of the models and I'm part of the security response team.
Been in quite a while for the, I think, 14 years, give or take, probably.
A long time, eventually.
So I started doing Python like 20 years ago.
That was fun.
Awesome.
Yeah.
Anything else you want to know about me?
No, I would just like to say thank you on behalf of everyone for not, for keeping our
machines from getting rooted because we're running Python web apps.
That's pretty awesome.
You're welcome.
Seriously, though, how often are there meaningful security problems in CPython?
I know that one of the big talking points about moving away from Python 2 was like, well,
if you don't come along for the ride, you're not going to get security updates.
But how often is that a big problem, really?
How often are there problems where our CVE is filed?
You're like, oh, we got to jump on this and quickly get it out before.
The last version of Python that came out before we had the emergency release for the bugfish.
So the 3.10.2, I think, had like 11 or 13 CVEs.
Although only one that directly affected was in the Python code.
So we also ship a bunch of extensions.
Like we ship a library to pass XML that had like six or eight CVEs.
We had a Zlib fix.
We had something else.
So it's not just Python core that's affected.
But since we bundle and ship several libraries with CPython, especially Windows and the Mac installers,
you may be also affected.
If you have Linux distros, they typically have their libraries debundled and use system libraries and they update them out of bounds.
But yeah.
Okay.
Well, that's actually more than I realized, to be honest.
You don't hear too often about it being a big public problem, like log4j or something like that.
Yeah.
I'd say typically the CVEs we end up dealing with is the bundling that Christian mentioned, right?
Like Christian does a lot of work to make sure we're constantly compatible with the newest versions of OpenSSL.
So for instance, on 2.7, had you not moved over, you're going to have to do the work to be able to use OpenSSL.
I think 3 is the newest one or the one coming up.
So that's the real kind of concern and less of we screwed up as core devs and we have a nasty CVE.
It's usually something we depend on that typically triggers this kind of thing.
Thank goodness.
Interesting.
Yeah.
All right.
Well, speaking of the standard library and stuff, let's start out by talking about Python just on GitHub,
because I think maybe the time of yours releases, it might be already a week old.
But Brett, you were one of the big proponents of moving CPython and the Python organization over to GitHub, right?
Yeah, I drove that move.
Thank you.
That's awesome.
It's so nice to be over there.
But one of the challenges has been that bugs.python.org has kind of been its own island, especially since this move, right?
Yeah.
So when I helped move us off of Macarial to Git and thus moved us to GitHub for pull requests and stuff,
I basically had to choose my battles.
And the battle I chose was changing our version control system and no longer self-hosting our version control system.
I was not up mentally to the challenge of also trying to move the development team over to a new issue tracker as well.
So I purposely punted on that problem and tackled the one I thought I was capable of handling and dealing with.
And that's why we ended up with this somewhat split personality problem of Python being on GitHub for pull requests and for code hosting, but not for issue tracker.
Well, Ido said yesterday, I believe it was yesterday, maybe the day before yesterday on Twitter that, hey, it's happening.
The bugs, python.org is migrating over and then it got delayed until April 1st.
So hopefully that happens really soon.
But what was really surprising to me was just how long that migration is, right?
It's not like a copy the files over, get in it, get commit or the equivalent of the for the issues.
It's days to migrate all the issues.
Yeah.
So there's tricky parts to this.
I mean, one is we're getting internal help from GitHub, but obviously it's not common to move issue trackers into GitHub per se.
Like a lot of projects, I think, just start on GitHub and have for like a decade.
So the idea of moving over is kind of a new thing.
And on top of it, not very many projects have the volume of issues historically to move over that we have, right?
Like we have like 7,000 open issues, I think, alone.
So the volume there also kind of causes an extra overload.
And because GitHub, as I said, they have some internal tooling for this, but it's not like something that they work on month over month.
It's there and we're using it, but it's not optimized because it's just not a typical business concern, which I mean, totally makes sense, right?
How often do you have a project of our size and age wanting to migrate over like this?
Just for the numbers, so we have almost 59,000 bugs in total on the bug tracker.
Yeah.
And almost 8,000 open.
Yeah.
7,000 some hundred.
Yeah.
And trying to translate over as much metadata as possible is computationally expensive, right?
Because what we have to do is we have to generate a dump and then the dump has to get...
It's a different data model, right?
And it's a different day model on top of it.
Correct.
So, for instance, one of the reasons this took so long was we had to first decide we wanted to do this, convince people that we should do it, find someone.
It was at Summelade initially to come in and kind of figure out how to map things and get things working.
And then earlier this year, we had Wukash step in and help out as well as the developer in residence to help push this over the finish line.
And on top of all that, having to process all that data, export it to the right format, and then have GitHub's tools pull it in and not cause a strain on their system.
Because, I mean, this is a lot of data to suddenly dump in and have to replicate across their entire cluster, right?
So, there's a reason why it takes so long.
And we also don't want to have it happen during...
Because we're probably going to be run at a low process priority, which also means we want to do it on a Friday in the afternoon so that it's over the weekend and not when GitHub gets hit the hardest.
So, there's a lot of coordination going on.
And as we all know, GitHub had some stability issues the other week.
And so, they just said, can we just wait until a little later to make sure that Sol's good and solid and everything looks good.
So, the plan is April 1st.
Excellent.
Very exciting.
And we also have a good track count to actually break GitHub.
I'm not sure if anybody interviewed the live stream.
Pablo's changed the master branch to main branch to rename the default branch.
But, yeah, we broke GitHub.
And it took a while to recover from that, too.
So, since our repos are so gigantic.
So, we started with ZVS, then moved to SVN, subversion, then went, recorded all this stuff to Mercurial,
and then to Git.
And I'm not sure how many revisions we have in the tip, but it's gigantic.
So, just to be ultra clear here, thanks to GitHub for working with us directly.
And actually, they donated money to help us make this all happen.
So, they've been really great partners in all this.
Thanks to Ezio for getting this started.
Marietta for the initial pep, by the way, and even starting this conversation.
And for Rukash to stepping in and helping get it finished.
Yeah, definitely a team effort.
A lot of people involved, and thanks to all of them.
So, Tushar out in the audience is joking, is this why GitHub has been crashing the whole
week?
But, Christian, you were joking, like, maybe, is this actually, did you guys actually cause
problems?
Not that I know of, specifically.
Yeah, okay.
But I also, yeah, not that I know of.
Yeah, okay.
I hope not.
I apologize to the world if we did, somehow.
Well, it wouldn't be the first time.
There's been other outages and other crazy things.
Yeah.
And unfortunately, at our sites, we would not be the first time.
Yeah, for sure.
I think there was a huge DDoS attack not too long ago.
Anyway, also, Kim out in the audience asked, assuming there are usernames and email addresses
on the original issue.
So, like, how much did you all care about having fidelity across those?
And, you know, this could have been an opportunity to just say, you know what's awesome?
Command A, archive in your inbox.
To just kind of catch up and be okay.
Like, you could have just dropped it and said, we're just going to start over.
And if it's important, it'll find its way here.
And if it's not, then it wasn't.
Yeah.
I mean, there has been talk about this.
There's varying opinions on how important the digital archives are.
Like, do we need to move all the closed issues over?
Should we only move open?
Like, we actually discussed this when we were looking at potentially up to a week to do the
migration versus the two or three days it's actually going to take now.
So, but everyone has different opinions of how important the history is.
To specifically answer the question, though, from the audience about usernames, as long as
you have your GitHub username attached to your bugs.python.org account, that should map over.
And you've got until April 1st to get it in there?
Yeah.
I don't remember if we map email to email.
There might be some privacy issues.
I can't remember where that all landed.
Like, lawyers were consulted.
And I was out of the loop on those.
But I believe if you at least have specified your GitHub username on bugs.python.org, we will be able to do the map.
Yeah.
Fantastic.
All right.
Well, thank you both for the update on that.
It's not exactly why we're here, but it's so timely.
And I think, you know, you're both involved in it and stuff like that.
So quite cool to see it coming along.
I personally really think that it's fantastic that CPython is on GitHub.
I know it's not that different if it was, say, self-hosted Git or GitLab or even Mercurial or SVN.
But there's just something about it.
It seems more open to contributors given just sort of the status of GitHub where a lot of people seem to hang out and the whole PR flow and those kinds of things.
That was part of the motivation.
Somewhat ironically, we actually had to teach a bunch of core devs how to use GitHub as part of the migration.
Because, I mean, to be fair, some decent chunk of the core devs don't contribute to other open source.
I mean, Python alone is a big enough of a project that it absorbs a large chunk of your time.
So they just didn't have to know how to do any other open source development for a different project other than however Python did it.
And if we weren't on GitHub, they just didn't have a need to.
Plus, we also did the move a while ago.
So I think it's coming close to a decade at this point.
So it was also a different time.
This is a great question 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.
So let's start by maybe talking about, speaking at different times, let's talk about the standard library from, maybe you guys could approach it from a historical perspective to start.
Because we're going to focus on stuff that's in there that maybe should be removed and the benefits of taking it out and stuff.
But when it got put in, it seemed like a good idea.
So when I think about Python, one of the key phrases I hear, I don't know its origin, but the batteries included story, right?
Python comes with batteries included and then its frameworks did like Django and so on.
And it's a huge selling point, right?
This is a language that has a bunch of support built in, right?
Yeah, so the rough history, for those who don't know, Python went public February of 1991, right?
So 32 years ago, it's predates Linux, right?
Like it's really crazy when you look at the history of when projects came out, how long Python's been around.
But the other thing to think about is who was on the internet or the World Wide Web even in 1991?
Like who even had internet or even a modem back then?
And so what that led to was people contributing things to Python that Guido would look at and go, oh, yeah, that's useful.
And then just pull it in and put it in the standard library.
And it grew and grew and grew.
And then at some point in the 90s, like there was a website called the Vaults of Parnassus, which had animated GIFs of wall sconces with little candles with the flickering, whatever, like totally a bit like you can imagine what this is like.
It's back in GeoCities days, right?
And that's where you went to get your code.
And all it was was zip files of Python code.
There's no concept of wheels or conda packages or anything like this.
There were literally just zip files of code that you just unpacked and just copied over the directory that contained the other Python code.
And you just vendored everything.
There was no there was nothing else.
And stuff moving stuff around the internet was slow as well back then.
I mean, a lot of people were on dial up.
Yeah.
Like internet made noise back then.
You were blazing fast with your 56k modem if you were lucky enough to have that, right?
So that meant that it was really hard to find high quality code out there, right?
And getting done and put up and all that.
So things just kept getting added and added to the standard library.
And it kept getting bigger and bigger and continued to be useful.
And it was just a different time, right?
Like, hell, not even everyone in the internet even had a web browser, right?
Like I remember when I first got on the internet.
Right.
I mean, didn't Mosaic come out in 93?
Yeah.
And actually, one of the very first graphical web browsers was Grail written by Guido in Python, right?
Like if you go look up the history, right?
It was like, I think Guido missed being the first graphical browser for like months or something crazy.
There's a weird history in Python in terms of early web.
But what this all led to, right?
Like, and I remember, by the way, when I first got on the internet, it was Usenet and Gopher.
It wasn't even the worldwide web, right?
That was still AOL days back then, for those of you who can date yourself based on that knowledge.
Usenet, Gopher.
Yeah, it was a different time, Michael.
It was a bit of a sidebar.
Like, things were so basic back then.
But at the same time, there was so much like imagination for what could be, I think.
Because so much of it was unmaterialized.
And you're like, ah, I can see where this is going to go.
Yeah.
And internet was even much more expensive in Germany.
So I know that until, so I was lucky, I went to university in 2000.
But before, when I was living with my parents, I had to pay the internet by the minute.
So local calls, so we're not free in Germany.
You had to pay for them.
And I know that like end of 99, I was lucky.
I paid like several hundred a month to have like a free, like a persistent internet connection.
Very persistent.
But I used the only phone line we had, but I didn't have to pay by the minute.
But I paid like in bulk.
Right.
It's super expensive.
That's why lots of people.
So I started actually using mailboxes.
So I dialed in mailboxes.
Right.
And they're like this weird concept that you were sending messages.
You push the message and later in the night, the mailboxes would call other mailboxes.
They do this Unix, Unix copy to copy the like the messages around.
And next day you receive the message from a friend who was living like in a different city.
Yeah.
I remember that was amazing.
Like all the backends that would just kind of sync up.
And it was like sort of this distributed, like the PBS world and some of the other stuff.
Yeah.
So it made a lot of sense back in the days to have all the useful bits and pieces in Python.
So that's why the library was so big.
And so we have just Python code.
It was easy.
But we also have lots of C code and C extension.
And these were really complicated to compile and build.
So you had to like make files and figure out which compilers and libraries you need.
And building things for Windows was super painful for the Windows people that they had to get the right compiler version.
They had to figure out their VC vars bat setup.
Yeah.
And each Python version had like its requirements for different like Visual Studio versions.
Yeah.
So I think that's, you know, people get a sense of the time, right?
Like at that time, it was amazing for Python to say, as much as we can get into the standard library, it's going to be a benefit to people.
Because if you need to parse CSS color codes, hex color codes, and it's built in, that's a bonus, right?
There's not the idea of pip and fast internet and all those things, right?
Or even disk details, right?
Like as Christian was saying, compilation was hard enough as it is.
So getting something in the standard library and ported over to C code for performance was a huge deal.
So it's not even just distribution.
It was literally just creating these things.
It was difficult.
Sure.
So it just shows how far we've come, right?
That these were even problems that we used to have.
Yeah.
It's pretty interesting.
Do you think if Python were designed today from scratch, you know, this is the kind of the language we want, it would be packaged in the same way that it is now?
Like, would it have a large standard library?
No.
So that would be controversial.
I agree with Brett.
Yeah.
Well, which is why we're friends and why we wrote this pet that we're going to be talking about.
It would just all be written in WebAssembly.
Oh, we have friends.
Thank you.
We went to a movie together, one of the PyCons of Portland, man.
Yeah.
And we are friends on Nintendo Network.
Yes, on Switch.
Yes.
Yeah.
Look at more recent languages like Rust and Go and stuff.
They have a much more targeted standard library.
They're able to lean on the community and people seem fine with it.
And I think that's a key thing is we get to learn the less.
People have gotten to learn lessons from us, but we also can learn.
We would have been able if we started now to learn lessons from other people.
And I think that'd be one of them is targeted standard library that is very tight and very
targeted, very foreign, very stable.
And that's much easier to maintain would probably be the good way to go.
Because it makes getting yourself up and going a lot easier versus, oh, this isn't useful
until I have this huge standard library, which as a burgeoning project would have been really
difficult because you had to build a lot of code to make that happen.
Right.
I do value having it there, though, at the same time.
I understand why it would be smaller.
I just think there would be some use cases that it would be less of an obvious choice to
use Python.
Like, for example, if I just want to script something on my computer, knowing that it has
Python means it has all these libraries where as opposed to if you've got to start installing
dependencies just to get your sort of automation scripts to run, like there's this bootstrapping
stuff that has to happen.
Yeah, from a philosophical perspective, we actually don't have a definition of what the
standard library is, right?
There is no PEP.
There is no guidance over what the standard library is now meant for, what it should or
shouldn't have.
It simply doesn't exist.
It's always been previously based on Guido's opinion somewhat.
And then now that's the steering council, it's somewhat based on just kind of consensus on
the dev team.
And that's kind of what the steering council will approve more or less.
But there is no guidance, right?
Like, should we make it so that, as you said, that simple automation script for managing
your computer?
Should that be, have enough in the standard library to make that happen?
Should we be able to have a simple HTTP server?
Right.
I don't know.
Should we have Tkinter?
Right.
Where is the line?
And we don't have an answer right now.
There is a discussion going on right now, actually over on Python Dev discussing this kind of
thing because there was a proposal to potentially rip out URL Lib.
I think it was partially done by Victor Center to kind of not get a rise out of people, but
to kind of spark a conversation.
And some people are going like, okay, URL Lib was written back in the day when OSes did not
necessarily ship with the network stack.
Right.
And when we could plug into it.
Would it be better to actually rely on the OS?
Right.
Do we really have to have all of that code in there just to parse things and figure things
out to make the right HTTP requests versus just going to macOS or going to Windows or using
curl and Linux or any Unix platform really, and just have it handle the request?
I don't know.
But I mean, this is the kind of question we're getting into now.
And we'll probably get to, I mean, we'll talk about later.
I have one of my infamous Brett's grand plan things around the standard library.
And this all ties into actually finally into making that decision of what do we want the
standard library to be?
So we have better guidance for ourselves as to where it should go.
And that's what should or should not be in the standard library.
Now, not to spook people, I don't know if this means we never deprecate anything that
doesn't follow this policy that's in there now.
But I would like to, at least as a core dev, know what we want it to be for today compared
to the cheap shipment model of useful Python code on the internet, pre-internet.
Right.
So, and Michael, earlier you asked me about security bugs.
And so Victor's proposal or Victor's threat on Python dev sparked by a discussion I had
with Victor on internal communication channels where I pointed out that ULLIP is actually a
place where we have lots of security bugs.
And even in very trivial things like to insert like parsing like in URL.
So something like splitting up the protocol, the host, the path name, the suffix.
This is not trivial.
And the way how our internal like parser works, it's written for a more forgiving and more open
world.
But people also use the routines, the like real open URL parse to verify and validate potential
hostile requests that sometimes fails because we are too open.
We are too nice.
And so this was one of the other reasons why the discussion should spark.
It's also a bit related to WebAssembly, but I think we can postpone it for later.
But there are two interesting interactions with how WebAssembly or the WebAssembly runtimes
environments work and what's not going to work with ULLIP.
Yeah.
And the WebAssembly discussion also comes back to what Brett was talking about for sure just
a minute ago.
So defining what is the standard library.
Do you want to come back as well to that later?
But let's talk about your PEP.
Which one of you wants to introduce?
PEP 594, removing dead batteries from the Python standard library.
Christian is the original author.
I just PM'd it to the finish line.
So I'll let Christian take this.
Yeah.
I ran out of steam and Brett just pushed and pushed it.
Helped me to push it over the finish line.
Yeah.
So what's the idea here?
The idea here is to remove things that are in our personal opinion and maybe with some
reasoning no longer like super required in the modern world.
So there are especially some parts that cost us lots of time and energy.
The interesting or the most relevant library for that is like NNTP.
So the library to interact with new servers that we've got your information.
Like Usenet?
Usenet.
Yeah.
Usenet.
So since we don't have a server implementation of NNTP, so the use standards, only the client
libraries, we need to use like actual new servers for testing.
So we need to connect to some servers and do some testing.
These servers are no longer like stable.
So we used to use libraries like sites like Gmain a lot or one French new server that was
stable, but they're sometimes don't work like we expect it to work.
They're sometimes just not available or the NTP connection fail or get like issues with
GLS connections.
And these issues we're having blocked our whole CI chain.
So when you do pull requests, you run your tests against Windows and Linux on X664 and
on also MacOS.
So like think for platforms.
But once your pull requests is merged, it also kicks off the whole build bot farm.
There are like 20, 30, 40 different platforms that run the tests host commit.
Anytime one of the NNTP servers had a hiccup, we have like false alarms and like indicating
problems somewhere which were not problems with the code or with the test, but rather with
the infrastructure that was failing.
And it was one of the motivations while I wanted to remove an NNTP.
Sure.
And how often are people depending on that these days?
One.
Two.
Who's maintaining it?
There was a really interesting list you all have of like, these are the things we want to
consider to remove.
There is somebody who understands and maintains it now.
A lot of them have a no for that, right?
Yep.
That's another aspect of this, right?
It wasn't, it was things that were failing our test suite because the thing we had to rely
on just wasn't stable enough or available.
But our parts were just simply no one wanted to step forward and say, I will make sure that
this keeps working in modern versions of Python and compiler errors are dealt with.
And I will deal with any feature requests and bug reports and all that.
Right.
Because the standard library before this PEP was more, had numerically more modules than
there are countries in the world.
Right.
Like the standard library is that vast.
And I think, I don't even remember if I even delved into sub sub modules of packages.
Like I think literally the top level namespace.
Top level.
Yeah.
So there is a aspect here of maintainability of just simply, there are only so many core
devs to handle the influx.
Hence why we have 1,600 pull requests that are currently open.
And at some point you just have to kind of stop and go like, okay, who is benefiting from
us carrying this forward?
And how much of a detriment is it to the project to keep it going?
And some of these things, yeah, it was just a question of, right, is this useful enough
to the world for us to put the effort into maintaining it and having to make a call on some of them?
And sometimes no one stepped forward.
And sometimes some people very much stepped forward and said, I totally rely on this.
And then it became a question that's like, okay, is it just you that needs it?
Or is it a large or decent enough size chunk of the community that still needed it that
it warranted keeping around and continuing to support it?
Because I did a number crunch the other day of certain sub directories in the Git repo.
And if you look at just straight code between the standard library and the interpreter, 60%
of that is standard library.
Wow.
Yeah.
How much does it influence your feeling and opinion about something, whether it has some
C component or if it's just pure Python?
Is it easier to keep a pure Python thing around that just is sort of higher level, doesn't
require as much nuance, or does it not really matter?
At least for this PEP, I don't think we really took that view specifically.
The management is more just a side effect almost.
But this was mainly, as the title puts it, dead batteries.
So when Christian brought this list up initially, it was, I don't think these are useful in modern
times.
Less than, oh, well, this is also written in extension modules, which makes it harder
to maintain because you can't just ask an average Python developer to come in and help maintain
it.
You have to ask someone who knows Python and C extension modules to come in and help maintain
it.
It was, that was never the motivation directly.
Okay.
Yeah.
But knowing cross-platform networking code in C is, is technically, I would say, harder than
knowing standard Python.
Oh, yeah.
This portion of Talk Python to Me is brought to you by Fusion Auth.
Fusion Auth is an authentication and authorization platform built by devs for devs.
It solves the problem of building essential user security without adding risk or distracting
from the primary application.
Fusion Auth has all the features you need with great support and a price that won't break the
bank.
And you can either self-host it or get the fully managed solution hosted in any AWS region.
Do you have a side project that needs custom login and registration, multi-factor authentication,
social logins, or user management?
Download Fusion Auth Community Edition for free.
The best part is you get unlimited users and there's no credit card or subscription required.
Learn more and get started at talkpython.fm/Fusion Auth.
The links in your show notes.
Thank you to Fusion Auth for supporting the show.
Let's first talk about the status.
So, accepted.
All right.
So, this is happening.
The first PR to document the modules being removed got committed last week.
And I now, now you all get to see the curtain pulled behind how Python is developed.
I'm going to publicly ask Christian to review my PR to deprecate AIFC.
I know he's busy, so.
But the first PR to actually, or maybe he reviewed it before the podcast.
I don't know.
But the first PR to actually deprecate AIFC, the first module in alphabetical order is now up.
So, I'll just be cranking through them until beta.
I feel like I saw in the release notes here that the Python 310.4 was out.
And this has deprecated various modules according to this PEP.
Is that right?
Yeah.
So, the steering council made the decision that it was useful enough to backport the documentation deprecation.
So, Python 311, obviously, because that's going to raise a deprecation warning.
But 310 and 3.9 also document that these modules are deprecated.
Because we didn't want people coming in in a company where they're on 3.9 at the moment,
start using these modules, and then be surprised in two years' time or what have you when they upgrade to 3.11 or later.
And suddenly, oh, this thing I've been using is suddenly deprecated.
Oh, this went back farther than 3.10, huh?
Mm-hmm.
Because 3.9 is still accepting bug fixes.
Got it.
So, that's what that means.
It's purely documentation.
The code is not changed at all.
It is literally just, if you go to the module index or any of these modules,
it will just have a big deprecated term on it.
Yeah.
Quick bit of nomenclature, real-time follow-up.
Mr. Hypermagnetic says, what is pure Python if not CPython?
Christian, you want to sort of disambiguate the CPython from Python that has C?
So, in Python, we have models that don't have, like, dedicated C models that are just written in Python code.
There are other models that have a minotary backend in C.
Like, if you look at the SSL model, which I maintain, the binding still must have written in C.
And the public-facing SSL model is FSA and adds on top of the C backend.
And this we would consider as a non-pure Python package because it requires C code.
There are also other models we had in the past.
A lot of the data structures like list and so on, right?
Yes.
All the core data types are written in C.
Yeah.
But they count.
They are present always.
So, we're just talking about, like, things you would import and use.
Got it.
I see.
Yeah.
And then we have accelerator modules as well, like Datetime, where they're implemented twice.
Once in pure Python and once in C.
So, like, PyPy will use the pure Python version or any platforms that can't compile the C code for whatever reason.
And then there's the full C version for performance.
So, pure Python just means the entire chunk of code for that module that you import is written only in Python code.
There's no C code at all.
Directly.
Obviously, what you import can transiently cause that.
For sure.
Yeah.
Christian, what's the idea?
Are we just going to, just when 3.11 comes out, all the modules are just yanked?
At 3.30.
So, 3.11, they will.
What's the plan here?
It's not so immediate or so abrupt, is it?
No.
It's going to take a couple of years.
So, in 3.11, you'll get, like, the deprecation warnings.
I think that's a plan, Brad, to just emit a deprecation warning.
So, if you would import a model and have the warnings model enabled to show you deprecation warnings,
then you would get a warning pop-up.
And even in your CI, turn the deprecation warnings into deprecation exceptions, so into a hard failure.
And then you see, I would fail and inform you that you're importing something deprecated.
This will continue in 3.12 and 3.13, the models are gone.
Right.
Okay.
So, that's over, basically, a more or less two-year period because 3.11 is pretty imminent, right?
Yeah.
October.
So, 3.13 would be October 2024.
Yeah.
Sounds far off now.
I'm sure it's not in practice.
Yeah.
And to be clear, if, for some reason, the community really spoke up very vocally across a large swath of people, we might consider postponing.
I don't think there's anything here we would not yank.
But if people need, for some reason, more time to move, we might consider holding off.
But we're fairly confident that most of these aren't.
And already, honestly, the ones that people really care about are already getting copied and put onto PyPI.
So, people can totally still get the original code.
And to be very clear, you're already using code from Python, which means you're already using the Python license, the PSF license for this code.
So, copying and pasting this code is totally fine.
And we encourage it if you need this code, right?
Because it's deprecated, it's not going to be changing.
Unless it flat out breaks because of some change in Python that requires an update, this code is more or less after this deprecation lands.
That code is not getting in touch.
Which means you could totally copy what's in there just prior to the deprecation or what's in 3.10, honestly.
Because, once again, these modules aren't really being updated.
These are the ones that are being basically ignored and just dragging along anyway.
Exactly.
So, you could totally go in, copy the code over into your own code base, paste it in.
Save it under the exact same name and it should more or less keep working the same way.
You'll have to maintain it.
Yeah.
So, there's kind of two paths forward for people who are like, no, I really need AIFC audio file parsing or whatever that is.
One, somebody might decide it's really important and they want the CPython version as a pip installable thing that you can then add back into Python with a dependency.
Right?
That could be a possibility.
Yeah.
Or, as you just described, you could vendor it, which means just copy the file and you just have a copy of the source code internally and it's just part of your app now.
Yep.
Exactly.
Oh, and IFC has an interesting backstory.
So, when I posted my first draft of the pap, I got contacted by a lead technical director from DreamWorks Animation Studios.
They wanted to keep the model in CPython.
So, Python is heavily used in the movie industry.
So, if you see any blockbuster, it's probably powered by Python internally.
Even so far that Python just won a special prize for the animation awards, the annies, what they're called.
That's right.
And Guido got that award, right?
Yeah.
Basically, the...
Guido got the physical award and some core devs, including Christian, got requested certificates.
Yeah.
And I believe, yeah, Christian's getting his.
Oh, that's fantastic.
The UIworks Award, that's the second guy who invented Mickey Mouse, for example.
So, UIworks and Walt Disney invented Mickey Mouse together.
Fantastic.
That's a cool honor.
And probably an unexpected one from working on Python.
Christian and I have been doing this long enough that I think I've mentioned this on the podcast.
When I first got involved as a core dev of Python, I still had to explain to people what Python even was, right?
Or if I was lucky enough that they knew what it was, they just would go, is that the language where white space matters?
Right?
Yeah.
Is that the one that's weird?
Yeah.
So, it was a totally different time.
And now we're being used to help power helicopters, help plan flight paths for helicopters on Mars and hunting the video of the lander that made that helicopter take off and processing images of black holes and gravitational waves.
I just had an interview.
Your JWST episode that I haven't listened to.
Yeah.
It's nuts.
So, no.
I never thought any of this would ever happen.
So, yeah.
Having blockbuster movies have their entire management pipeline for their assets written in Python, it's always mind-boggling where Python is and what it's powering.
I mean.
That's cool.
It's not just all your cat videos and photos on Instagram anymore or videos on YouTube.
Yeah.
It's both amazing and par for the course.
Yeah.
And I can't believe I just said it's not just Instagram and YouTube anymore.
We've also been there long enough that people have realized we power huge websites.
Yeah.
Absolutely.
Lots of stuff in the world.
Yeah.
No, it still blows my mind constantly.
Yeah.
YouTube was originally written in Python.
I think it's still lots of parts of YouTube are powered by Python.
Last time I spoke with someone there, it was.
Yeah.
Sydney out in the audience has an interesting question.
Like, so there's a list of things that are deprecated here.
Some that were threatened but kept.
You know, they were on the list and then they're just like, ah, maybe not.
Sydney asked, might there be further removals in the future?
Maybe.
Yeah.
So here's the deal.
This PEP was done because Christian, I personally think rightfully so, thought we needed to do
a bit of house cleaning and get rid some stuff that was just kind of just sitting there rotting
in the corner and not being loved.
Some things got kept because to keep the controversy low, Christian was very conservative with the list.
And basically, if anyone stepped forward and said, no, no, please don't take that out.
That was a core dev.
It more or less just got left.
Very few things are on this list that people still pushed back and said, we're removing
even if core dev wanted to keep it.
That being said, as I said earlier in this podcast, right?
Like Brett's crazy grand plan here is, was to help Christian get this PEP done, get initial
clean done.
I've started a conversation over on Python committers about how to maintain the standard library,
right?
Like what does it take to add a module and to remove a module?
Because that's actually not very clearly stated either.
It's been very just kind of open.
My perspective from the outside of what defines the standard module is just, it's write only,
like stuff only gets added and it's defined to be what's in the shipping version of Python,
right?
I mean, that's kind of an implicit definition.
Right.
But how do you get something in there?
Right.
Like, did you know that GraphFlip was added by a couple of core devs just because they thought
it was a good idea?
Yeah.
It wasn't, no one asked like the chain counts or anything.
That's how it's been historically maintained.
It's very much just an open thing.
And there's a proposal to kind of make it a bit more structured and you could argue more
rigid depending on your view of this whole process.
More modern.
Maybe.
By suggesting that you need a PEP to add something because it's a shared cost to all the core
devs that we have to maintain it.
You'll notice I have a slight theme here of maintenance costs.
Or...
I have a puppy for you.
One that's fluffy or one that I'm going to have to pay vet bills for?
Clean up the poop.
Might ruin your carpet, but it's also cute.
So you'll...
Yeah.
I've got a cat.
I'm good.
I don't know if it's not the joke.
So I've just watched Brad's keynote from PyCon like three or four years ago.
I think it was...
Maybe.
It was the first one in Cleveland, whichever one that one is.
I can't remember.
2018, I think.
I think it was 18.
Yeah.
Once that's settled, my hope is, once again, come up with a policy of what that means for
the standard library.
Once we have that policy, there will probably be a discussion about what does that mean for
the current standard library?
Do we leave it as is?
Do we maybe slowly transition over or not?
I don't know.
Some people like Lukash, for instance, have advocated never removing anything from the standard
library ever again.
And literally just saying, this is deprecated.
We will never touch it or update it.
It's dead, but it's sitting here so we don't break code.
Other people are way more, let's strip it to its bones.
And if you need this stuff, we'll make it as a separate package or something.
Some people have talked about keeping it as is, but separating the development process.
So it's actually an externally maintained thing and it has its own release process and schedule
and all that.
The answer is, I don't know, but this is not the first time I've deprecated modules and
had them removed.
I was also in a competition with Fred Drake back in the two to three transition to see who could
remove the most number of lines of code in Python.
And I won thanks to removing the compiler package.
So I have been around long enough to say, probably, I just don't know when, just because I will
never say never when it comes to a project that's 32 years old.
But there are no specific plans right now outside of this PEP of deprecating and removing anything
else from the standard library.
So if that's the question concretely, no plans.
But philosophically, I am not willing to say anything.
I never say never.
Yeah.
So one of the things that stands out, let's talk about the modules real quick.
Then I want to, I want to kind of talk a broader thing because I think it's going to lead us
down a path.
So maybe just give us a quick overview of the highlights, let's say, of things being removed.
I talked about this table here.
It's under the deprecated modules heading on the PEP.
And it has a module name, when it's deprecated.
Some of them are like deprecated in 3.6, when it's to be removed, when it was added, whether as a
maintainer.
And interestingly, I thought this was cool.
There's an alternative that's new or better and maintained that you could just use, right?
Yes.
If you look at the table, you'll know some of the stuff's actually been somewhat documented
as deprecated all the way back to Python 2.0 or 3, right?
Like you also have to understand some of the stuff got documented as don't use anymore.
A long time ago, we just didn't take the code out.
And this is more of a push to actually finally remove the code and the documentation.
I see.
But yeah, so we have AIFC, which I believe is the audio format.
Correct.
We have async chat and async core, which were very early async server things in the standard
library that you shouldn't use, obviously, because it's on this list.
Yeah.
An alternative is asyncio, which was added in 3.4.
Yeah, it's actually asynchronous.
I think the async check, async core were added for Zope back in the days.
I know that the Zope server used to use async core async check a lot.
I don't even remember what the hell audio app is.
Audio app is low level, like conversion.
And math operations used by IFC, WAVE, and some of the other sound models.
So this just provides math primitives in C.
CGI is literally what it sounds like.
It's helpers to write CGI scripts.
That sounded like one of the bigger, harder to work with ones.
Like there's no maintainer.
It was designed at a different time.
Yeah.
And the funny thing, though, is a lot of packages still use bits of it because there's weird
little helpers in there.
But if you also go look at what the helpers are doing, most of them are either a one liner
or they delegate to something else somewhere else in the standard library at this point.
And they have horrible APIs now because they very much expect it to be CGI.
All right.
So they're reading from like environment variables and files to get the things to process versus
passing them as an argument.
From STD in and STD out.
So pretty much hot code STD in and STD out.
Yeah.
So there's actual pushback on CGI.
But I think when we pointed out like this just delegates to here or this is literally a
one liner that I can paste in when you're in the discussion of what it does, like just
copy and paste this reject literally and or just whatever.
Most people, I think, were OK with it.
This is actually, I think, one of the first modules to get put up on PyPI like a couple
of weeks ago.
CGI TV is tracebacks, pretty tracebacks in your CGI code.
I mean, once again, if you don't have CGI code, you don't need the tracebacks.
One goes, the other comes with it.
Yeah.
Chunk, I think, is literally just chunking data.
It's literally just breaking up into chunks.
Not a little bit like editor tools.
Yeah, I think so.
If I remember correctly.
Well, it's a format to distribute files used by mailboxes or so.
If I remember correctly.
Yeah.
I will let Christian talk about crypt.
Yeah.
Crypt is a binding to the ellipsis.
Crypt function is used to password hashing.
No way around.
The problem with that is that the only guaranteed algorithm that's available is horrible.
And if you need some of the better ones, they're probably not available in your libc.
So there's like optional algorithms for password hashing.
And even there are problematic.
So I've used one of these replacement ones.
So they're much better.
Like Bcrypt or passlib or anything else that's doing it right.
Yeah.
That's great.
Yeah.
And image shader is just a very limited approach to detect if you have a PNG, GIF, JPEG, whatever,
based on the first couple of bytes of a file.
Just the same with audio headers or sound headers.
They just detect file formats.
But they only support a very limited setup file formats.
And there are better libraries that are more efficient and support much more different file formats.
Yeah.
So after image headers, MSI lib, which helps with Windows MSI installers.
Okay.
Why do we have this in the standard library kind of question?
I think we used it originally to help write the installer for Windows.
And I think we don't use it anymore.
So it's no big deal.
We already talked about NNTP lib.
NIS.
Who still uses NIS?
It's on yellow pages.
Yeah.
Exactly.
Do people even know what sun is anymore?
Right.
We're getting to that point in our lives.
I think it's a synonym for Oracle.
Yeah.
Exactly.
OSS audio dev is just a wrapper on an audio library.
Once again, does that really belong in the standard library?
Yeah.
It was used by Linux before they had alt sub, before they had pulse audio and pipe wire.
So this is like from the old 2000s.
No.
Pipes library more or less got replaced by subprocess.
So it's literally just Unix pipes.
SMTPD.
I don't think we need to be able to run a server to send email in Python.
Standard library.
So that's why that's there.
Yeah.
And there's a IPI alternative.
Yeah.
Send header.
Coach, you already talked about.
SPWD.
It's the binding to the Etsy shadow file.
So that's the place where Linux actually keeps the passwords for users.
But that's the wrong approach.
So if you want to log in a user, you don't check the password.
You ask the PAM stack if the user's allowed to log into a service set.
Sun.
Are you is another audio format from Sun?
So Telnet lib.
Yeah.
Telnet.
Server.
This was specifically to be a server, not a client of Telnet.
It's not a client library.
Sorry.
The client library.
So I don't think you have a server.
But actually, I would have to open the code and read the code.
UU.
That was used by UUCP.
So Unix to Unix copy.
It's a chunking format to transfer binary data.
And XDR lab, another Sun library that is the binary format used by NFS.
And remote procedure calls.
If you have like Sun remote procedure calls for network fault servers.
From 1992.
Indeed.
There's an interesting high frequency of Sun being mentioned here.
Yeah.
I mean, Python used to run cleanly on Solaris right out of the box.
Yeah.
And Sun developed lots of internet standards we still use these days.
Sure.
For sure.
So hopefully all the listeners were shocked and had no clue any of these modules existed.
And hence why we're getting rid of them.
Where's the threatened list?
It's down here somewhere.
The modules to keep.
Yes.
So we got ColorSys, FileInput, GitOpt, OptPars, and Wave.
Those are the ones that avoided being cut.
Mm-hmm.
ColorSys, to be frank, is just basic math.
It's nothing special.
But CoreDev said, I use it.
I'll keep it around.
I'll maintain it.
Okay.
Like parsing RGB color.
Yeah.
FileInput.
I don't remember about FileInput.
I think someone just said, I use it.
GetOpt and OptParse.
Where once again, is it worth getting rid of versus AugParse?
And is it widely used enough?
And it was just one of these.
There's just too much code out there right now to warrant working it out.
So we just said it's easier to keep.
And Wave plays WAV sound files.
And basically, it's used by education.
It's a quick and cheap tool to show kids computers can do fancy stuff like make noise.
Oh, yeah.
That's actually really nice if you've got your turtle moving along.
It could laugh when it gets to the end of its little thing or whatever, right?
Yeah.
But I mean, that's another good point, Michael.
Like, oh, turtle.
Well, that requires us shipping TK Enter, which requires us shipping Tickle TK.
And it's just like, where do you draw the line?
Yeah.
But it's turtles all the way down.
You know that.
Hey, and as someone who learned turtle back on an Apple IIe with a good old green and black screen,
like, I totally get it.
But I mean, these are the questions we're starting to ask ourselves, right?
Like, where's the line?
Yeah, indeed.
All right.
Before we run out of time, let's have a broader philosophical conversation about this stuff.
You said you have a big plan.
You know, one of the things that I think is interesting about Python is where it runs in all these different
places.
I mean, you've got Mac, Windows, Linux, but you also got Raspberry Pis.
You've got helicopters.
You've got robots.
And then you even have, you know, CircuitPython and MicroPython, where it's like really, really
small.
And I do think it would be interesting to say, here is a subset, a portion of Python and a
portion of maybe even the language syntax that if you program to this, you're guaranteed
to be able to run it everywhere, right?
Is there a way to agree?
Maybe that compiles to WebAssembly and runs in the front end on a browser.
Who knows?
So for any of you who read my blog, you'll know I've been doing a long running blog post
series on the syntactic sugar of Python.
And part of the reason I've been doing that is I've been trying to figure out what I've been doing
and I've been doing that.
I've been doing that.
what I've been doing that.
What I've been doing that.
What is the core set of Python constructs that must exist to basically reconstitute all the other
parts of Python and its syntax.
And kind of if we were to start from scratch almost, what would that look like?
Now that's interesting from a language level, but from a standard library level that comes
into play only in terms of support, right?
Like we dropped this feature, would that break things, right?
Like name tuple.
Right.
Well, for example, does TK intern need to be in the WebAssembly front end version?
Probably not, right?
No idea.
I guess not, but you know, maybe.
Probably not.
Yeah.
I mean, that's the tricky question, right?
It's always one of these things of who are you optimizing for?
Who's the target audience?
How do you define that?
Right.
Like other than stuff that we have to have just to make CPython run, nothing technically has
to be in there.
Right.
Some have said, oh, we should have enough to at least bootstrap in pip.
So if you can at least get pip or some installer in, you can then at least get yourself going
and start installing dependencies.
Yeah.
But as you mentioned earlier, like it's nice to be able to also write that little automation
script that helps maintain your system and not have to pull anything and have to create
a virtual environment for every little script you ever write.
But where's the line on that?
Yeah.
When I saw Python on Linux on just like a bare server, I can apt install Python three, but maybe
that's not enough.
Maybe I need to also install sometimes Python three dash VE and V or, you know, it's like
broken up into bits, right?
The Debian question is a very hot topic with Christian in the room.
But I personally argue against Debian's policy on that and say VEMV would be considered a core
part, right?
I think it's core as well.
And I wasn't so much picking on VEMV as just like there are environments where it comes
with in pieces to some degree.
Okay.
I need to find the right words to not get into trouble again or to get into.
Last time I burst a bit uncareful.
Somebody accused me to wage a crusade against Debian.
It's a philosophical disagreement.
Yeah.
So Debian has the policies to split packages in a smaller part so they can have a minimal
installation.
And they also don't like the way how we have like virtual AMP and short pip provided because
it's actually duplicating code.
We have like a zip file of binary wheels with compressed setup tools and pip, which contains
vendor packages.
Debian wants to use their distribution provided version of pip.
So this is a conflict.
Like we from the parts of the core developers, we think that the usability is more important
here.
So we want users to be able to use standard documentation instructions to use Python install
extensions.
This is more important for us.
And this is a debate which had like multiple session between Debian engineers and the steering
council.
There was several heated discussions.
And yeah, there are just different philosophical like interactions.
Got it.
So, I mean, the key point is, is there are a lot of questions about like, if you start to
slice and dice the standard library into parts that you can install in groupings, for instance,
is that truly part of the standard library?
Or is that just an optional install on PyPI that the core dev team just happens to maintain,
right?
Because you can no longer rely on it.
Yeah.
I mean, if you went down that path, it would almost be a little bit like the anaconda story,
right?
Like here's the essence of what I got.
But if I install what I normally install, I get more.
There'd be like a minimum install and like a fuller install, which I think, I don't know
how I feel about that.
Well, if it gets me Python on the front end, I'd have to write JavaScript.
I feel pretty good about it.
I'm starting to think, I don't know.
At least for some part, it makes kind of sense.
So let's go back to Tickinter.
So Tickinter depends on TK, Tickle TK, which depends on your graphical user interface.
So X11.
And if Python would always require Tickle TK, then you would have to install, I guess, like
100 megabytes of libraries on every container image that has Python because the whole X11
stack is very big.
So you get your whole like graphical user interface libraries down to the actual graphical server
that renders all the output.
It makes sense that most distros split up to Tickinter and ship that optional package.
But some distros go a bit further and split off packages that we consider to be core, core packages.
So the inner core that should be always available and working.
Like date, time and tuples and stuff like that.
Yeah.
Stuff that has no third party dependencies, basically.
Yeah.
Okay.
Interesting.
What about WebAssembly?
You guys started actually building for WebAssembly, didn't you?
Yes.
Steve Dower pointed out that I don't remember the way to look it up.
Super easy.
But that there's sort of a proper core dev version of WebAssembly CPython now.
It's REPL EASNHS.
I just posted in the chat with the chip one day.
Yeah.
I mean, basically what happened was that the core dev sprints back in October,
I started to look at seeing what it would take to compile CPython to WebAssembly.
And I was lamenting in our build channel on our core dev discord server that, all right,
the build setup was kind of old and creaky and I needed some help to figure out what to do.
And then Christian working for Linux distribution knows how all this stuff works.
And so he started to answer my questions and I did some initial cleanup.
And then Christian really got into it and just totally really started to clean up our entire build process in terms of modules and such.
Because there's a setup file in the repo where you can specify what modules you do or don't want built in to Python,
both compiled it all into like a .so or DLL, compiled into statically into the binary or just completely left out.
And Christian went through with some help with Erland, I think, actually, and cleaned up, you know,
cleaned up a bunch of the whole structure so that we were using more of PKG config and just made it just a bit more modern.
And while he was doing that, Christian would bring up stuff about like cross compilation,
because that's another thing we do is you do a cross build, right?
You can build, I mean, you can totally build on your Mac right now, Michael, 4x86 64 bit, even though you're running an M1.
Oh, interesting.
Right.
So it's just flags.
That's pretty wild.
Yeah.
But the way you get WebAssembly building that way is you just specify typically in script in the as a C compiler,
which basically is clang and you just specify.
And basically under the hood, it's more or less just specifying the right flags and everything to just make clang build for a different CPU target.
And then Christian was starting to talk about like, oh, well, for cross builds, can we do this and that?
And I kept saying, no, it won't work for WebAssembly because of this and won't work for WebAssembly because of that.
And then Christian just looked into it and was like, oh, I'll use this as a motivator.
And then Christian just ran with it.
And Christian figured out all the problems and just got really into it.
And it's been patching CPython's main over and over to the point that as of, I don't know, less than a month ago.
So for two weeks now, we can run the entire test suite without any failures.
Yeah.
On WebAssembly.
Yep.
Cleanly.
Inside Node.js.
So you compile the, so these are a bit earlier.
So when you build Python for WebAssembly, you have to not only tag WebAssembly, but also like the runtime.
So these things are called triplets, so platform triplets.
So you have like which CPU you target, which vendor and operating system and additional flags like GDBC.
And default target is a WebM32 mScripten.
So you do compile to WebAssembly with CPU instruction for 32 bits.
And mScripten is the runtime platform.
And mScripten can target multiple like different platforms.
So this is mScripten for the browser, but you can also compile it that it uses Node.js backends and Node.js like file system access.
So we can actually.
Oh, you probably have more permissions and more capabilities.
You can run threads, you can run sockets in a limited way.
That's fantastic.
And you can access the file system.
And so it was a process of running the test suite, figuring out why it's crashing.
So we had in the beginning like this completely like really crashing the runtime.
Not just itself, but there's like a virtual kernel layer written in JavaScript that provides syscalls written in JavaScript to the WebAssembly model.
It's a bit weird.
So I was writing kernel-like code in JavaScript and the unit test code for that in C.
So that's mScripten.
Very cool.
Yeah.
So this REPL.EthanHS.me, which I'll put in the show notes, it's got my mScripten version of Python 3.11.
And I can do fstring stuff and the thing that's right here in the browser.
Hasn't been updated in a while.
It's a bit old.
Need to talk to Ethan.
It's like six weeks old.
That's old for the web, I guess.
Well, I mean, we have a cron job running on Ethan's GitHub repo for this that runs nightly against Python.
Cpython itself to make sure it continues to compile.
We need to get a build bot going.
I've got Microsoft's degree to fund one via Azure.
And just we have to get it to, I haven't talked to Christian about it yet, but we'll figure out getting a build bot going.
And then we're, I, part of one of Brett's crazy grand plans around Python WebAssembly is we're defining an official platform support for Cpython right now for in PEP 11.
And my hope is we're going to get it so that Christian and I are listed as the maintainers of the WebAssembly support in Cpython.
And we'll get it listed as an official tier two, what we're calling tier two supported platform, which basically means it's backed by two core devs, at least, and a build bot.
But the idea of tier one is something the entire core team supports and is based on continuous integration.
That's really exciting.
Yeah, well, one of the actually nice things about WebAssembly is we could theoretically even get that to a tier one because WebAssembly is an abstracted assembly language, but it's not CPU dependent.
So we could actually compile it on GitHub actions and test on that just as equally as Mac, Windows, or Linux and have it still be fully tested and work on CI.
And I mean, you can take this idea really far, right?
Like suddenly we could start having executable code examples in the documentation for Python because we've got a runtime now.
We can literally make that work.
Yeah, because yeah, you don't have to worry about security or compute costs because it's in your browser.
You hack yourself and it's your compute.
Right.
Selfishly for me at work, when this works, I can start talking about shipping the node version of this with the Python extension for VS Code or as its own extension.
So like you don't have Python installed?
Install this other extension that's going to come with Python compiled to WebAssembly and you'll just have it.
Or VS Code.dev browser version.
We could potentially start shipping that with VS Code.dev and have the Python extension pull that in.
And now you'll even have a runtime in the browser that ties into what I think is a nice editor.
So there's a lot of possibilities here that we really want to get going with.
And then when you start talking about WASI, right, then you start to get to edge compute.
Christian just got that working like literally, I think, last week.
I don't know where it stands yet.
Working again.
So the first version was like hacking and patching lots of things out.
Oh, yeah.
All the P thread work.
Yeah.
And the new version like a week ago was using a library from a company that's also working on Python support.
They're like stubs and hacks.
Single store labs, right?
Yeah.
Single store labs.
Yeah.
So WASI is even more restricted and limited compared to what was in MScript then.
So you don't have any support like for threading, but you can't compile Python without at least the threading library headers.
And they just had like book arounds for that too.
So you can't spawn a spread.
So if you try to start a thread who just failed, at least you have enough like of the CIPA available to compile Python for bits and bits.
That's super exciting.
Just to be clear on that, it's not a completely new effort.
There's actually a productive version of Python for Rep Assembly in the browser called Pyodide.
Yeah.
And which is also now used by Jupyter Lite.
So Jupyter Lite is Jupyter Notebooks on top of Pyodide.
Yeah.
Jupyter Lite's looking really interesting.
Yeah.
And we actually met with the Pyodide team and more or less what we came to an agreement seems a little weird to phrase it this way.
But basically an agreement where we will keep trying to make it so that the main branch in CPython can compile cleanly to WebAssembly.
And that frees them to focus on JavaScript API to tie into it and on getting the scientific stack compiled over to WebAssembly because you have to do some hacky bits.
Right.
Because you got to compile like matplotlib and stuff because it's got C in it.
So you got to compile it over there.
Or I don't know.
Some of those like NumPy definitely.
Exactly.
Because traditionally they had to do all the patches and all the work every Python release to get it working.
And Christian and I are just in a better position to be able to keep that up and going.
So we just said, let us handle that part.
You don't have to worry about patching anymore.
You can focus on the stuff that's more unique to WebAssembly and what you're able to be good at over there.
So that's kind of where we're divvying up the workload here is we're just going to keep main working.
And then they get to stop worrying about that once they start worrying about Python 3.11.
So one of the first things that Ethan and I did just we took the patch that's that were developed by pilot developers and adjusted them and made them compatible.
So we can actually merge them and have them in the upstream code.
So a lot of their patches was just replacing things, but not in a way that would work if you would build the same source code for Standard Python.
So they're just hacking around and getting things working, which is totally okay for their approach.
But you couldn't just take their pull requests and their patches.
So we had to make them in a way that this would work for Standard Python and WebAssembly Python.
Yeah, fantastic.
Well, two things spring to mind for me when I hear this.
One is, does this mean I could write Electron apps and just have the slightest shim that then just lets me run like a backend in Python?
You know, the sort of Node.js side of that in Python, which would be awesome.
It should because Electron ships with Node.
So as long as you have access to the Node runtime.
Yeah, and you just get it on top of there.
And then instead of writing all your sort of core logic of your app.
You'll have to shim out back to JavaScript appropriately and have those APIs, which you might want Pyodide for potentially.
But yeah, basically, yes, that door is open.
Yeah, that's cool.
I don't know Electron.js well enough to say, oh, I could totally just go do that.
But I see that as a possibility that would be awesome.
Yeah, so what we don't have probably won't add in the near future is any kind of bindings to JavaScript.
So you can run like Python in your browser as like an isolated process or work web worker.
But communication back and forth between like the outside world in the Node.js or browser world and Python, that's provided by Pyodide.
But we don't have that.
Right, right, right.
So there's a very fun and great talk by Katie Bell.
She also helped us to kickstart the port.
She gave a talk at PyCon AU a couple months ago.
It was like 10 minutes introduction.
Two minutes compiling Python to WebAssembly and 28 minutes get STD in working.
So just STD in, STD out working took like half an hour of her talk because that's surprisingly, surprisingly hard with WebAssembly.
Yeah.
We kind of made the decision that at least for now, we are not interested in trying to develop that FFI back and forth with JavaScript and having that opinionated API.
And that's, as I said, kind of the agreement we've come up with Pyodide right now is they already have an API.
We're going to lean on them to provide that for now at least and probably will continuously.
I don't really necessarily see us changing this.
And we'll just provide the lower level functionality of just the runtime.
Right.
Yeah.
But if you all build that, it's a great foundation for other people to run with.
Exactly.
Yeah.
And then the other one, but first of all, is this the talk that you're talking about?
Yes.
That's the one.
That's Katie.
Okay.
I'll put, yeah, that's Katie's talk.
Great.
I'll put that in the show notes.
The other one is, is that the right URL?
Danger.
Yes.
Is this a Blazor project from the C# .NET team?
Yep.
This is .NET, the .NET runtime as a front end framework running in the browser, which is pretty awesome.
And it seems like there's just so many parallels that could be brought to the Python world that like you don't have to do Angular.
You can just do PyBlazor.
I mean, that's not the name, but you know what I'm saying?
Like it's closer to possible.
And I think this is actually something that would be really neat.
Yes.
The trick here, and I think Blazor does the same thing right now as well, is from my understanding, Blazor has a WebAssembly compiled .NET runtime that gets loaded into the client.
Yeah.
And then that's how it does the execution.
If I understand how Blazor works correctly.
And so you could do a theoretical same thing with Python.
Now, obviously there is size issues to consider here, right?
Like this is not something you necessarily on a really slow connection somewhere would want to actually pull down.
Because I think the one time, is it 5 megs now, Christian?
Or is it 3?
So the uncompressed Wasm is like 6 megabytes.
It gets down to like 4.
And then you have the big bundle of the data file that contains the Python compiled files.
It's another 5 or 6 MB.
It's big.
But actually it's smaller.
Okay.
3 MB.
Can you scroll up a bit?
The .data file.
It's the standard library.
Did I?
Did I care a lot?
Yeah.
Group tab.
Python data and Python web.
Yeah.
So it's 3 megs for the standard library, 212 kilobytes for the wrapper.
And you've already cached the Wasm.
So it's probably 6 MB.
But so we can probably make it a bit smaller.
So currently that comes like with elementary and decimal model and all the hashing libraries
compiled in.
So we currently create one gigantic binary.
There are ways to have side models like shared libraries with Wasm.
It's a bit more complicated to get that right.
And also it increases the size of the main binary, the main model a bit.
I didn't go into that yet.
It's something I look into maybe in the future.
But as you were talking about earlier, Michael, about like slicing and dicing the standard library,
if you're shipping the runtime, you can also shrink that down by just dropping all the parts
of the standard library you don't need.
Right?
So if you run like module finder or some other script that's going to go through the standard
library to figure out what you do and don't need, you could actually just compile your
own version of Python, CPython for WebAssembly only with the standard library that you want.
Interesting.
You get it really small, right?
So which of these three, Python.js, Python data, and Python.wasm is the, has cEval.c in it?
The Wasm file.
The Wasm one.
Okay.
So that's two megs and then plus the standard library bits, right?
Yeah.
So it's a little over five megs in total for everything, which isn't huge.
Like an internet project that you might need?
Totally fine for Electron apps, as you said.
It would be totally fine for a single page app.
It'd be fine for Gmail.
Yeah.
It's something you're going to leave up and running constantly and not change.
Yeah.
It's within the realm of probably what Facebook's already downloading onto your machine right
now anyway.
Yeah.
Just run an ad blocker and it'll do less.
All right.
I think we are well over time, but you guys, it's, it's always great to talk to you.
Yeah.
Good work.
I dream of Pi Blazer happening.
And I also saw a nice, interesting comment that triggered a thought.
It's progressive web apps are not really a thing we can do in Python very well because
for a progressive web app, it's really got to be all offline in some meaningful way.
But, but if you could bring Python.wasm down, maybe use local DB, there might be some really
interesting ways that progressive web apps become way more interesting to us as Python
web developers.
Okay.
Now I have to confess, I have no clue what the progressive web app is.
I don't know anything about lecture web development.
I got Python working on the browser, but I don't know how browsers work.
Awesome.
I will give one last tease though, Michael.
I had two motivations for getting into this whole WebAssembly thing.
Browser, mobile.
Because every phone has a WebAssembly runtime.
Thanks to all of them shipping out the browser.
Yeah.
Okay.
Now I'm also very interested.
I would rather have a mobile option than a offline than a front end web option.
So there we have it.
Although these may well go together, honestly.
Yeah.
All right.
Well, thank you both for your hard work on this pep.
And then it's super interesting to see how it kind of ties back into this, like more focused
runtime than more places.
Yeah.
All right.
Before you get out of here really quick, last question I'm going to ask you.
Just keep to one since I kind of know the answers for the other.
I'm pretty sure.
Anyway, notable PyPI package you want to give a shout out to before we dip.
Oh, man.
There's one that runs WebAssembly, like something you can have, like Python that'll basically
interoperate with any WebAssembly one.
I can't remember quite what that was called, though.
I think WasmTime has one.
Yeah.
There's a couple.
There's a couple of people who've posted stuff to PyPI that let you load a WebAssembly
code and actually run them.
And I think WasmTime might be one of them.
WasmTime is a WebAssembly runtime run by the Bycode Alliance.
And it's usually the most cutting edge of all of them.
So if anyone wants to play with this and looking for a runtime, WasmTime is probably a good one.
Python embedding of WasmTime.
Python plugin.
Perfect.
And you can ask Christian what his favorite editor is.
Yeah.
The right one.
The good one.
I use a couple.
So I use PyCharm.
I use VS Code.
I use Vim.
So depending on my needs.
You use them all?
Yeah.
You've got a whole survey, the whole spectrum.
Yeah.
That's awesome.
Cool.
And then a notable package you want to give a quick shout out to before we get out here?
It's very late.
I don't know.
The Python standard library.
Yeah.
The lack of certain things in the standard library.
It's like an anti-module.
The fact that you guys are taking it out.
Oh, the anti-gravity model is also fun.
Oh, yeah.
Sure.
All right.
Anti-gravity.
PIP install anti-gravity.
Now.
Maybe it's in the standard library.
I'm going to give you all up here on the WebAssembly one.
That would not work.
I removed that.
Oh.
Because that requires the browser model, which requires the sub-process.
I'm in a browser.
So you can't run any processes.
So it's.
Yeah.
I know.
I'm just kidding.
I tried.
For people to see.
I tried to import anti-gravity inside the WASM REPL.
It didn't do it.
Not yet.
I wonder if I can do it.
Yeah.
I don't know.
It may be.
Maybe it can.
It should.
They all should.
All right, you guys.
Thank you so much for being here.
I'm excited to see this progressing.
I see it leading to good places.
Thanks for having us, Michael.
Bye.
Bye-bye.
See ya.
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.
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/founders hub.
Fusion auth is your authentication and authorization platform built for devs.
If you have a side project that needs custom login and registration, multi-factor authentication, social logins, or user management,
then download Fusion Auth Community Edition for free.
Check them out at talkpython.fm/fusion auth.
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.
I'll see you next time.
Thank you.