On the last episode, we explored Pyodide, a project whose goal is to bring the CPython
scientific stack to the browser via WebAssembly. This time, I meet up with Brett Cannon,
one of the more well-known and prolific core developers, to explore what role WebAssembly
has for CPython in general and what opportunities might exist for Python and WebAssembly at the
moment. This is Talk Python to Me, episode 213, recorded on-site at PyCon on May 3rd, 2019.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter,
where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python. This episode is brought to you by
Microsoft. Be sure to check out what they're offering during their segments.
It really helps support the show. Hey, folks. Thanks for listening in today.
Just a quick heads up on the audio on this one. We recorded it live on the Expo floor hall at PyCon
in Cleveland this year. I think the audio is actually amazing and came out great, but you will hear our
voices straining a bit to talk over the crowd, and my voice in particular has a little road wear from
all that conferencing. So sorry for my fading voice, but you'll enjoy the conversation with
Brett for sure. Brett, welcome back to Talk Python.
Thank you, Michael. Glad to be here.
It's great to have you here. It's been too long. I mean, what has it been like? Three episodes?
Has it even been that many? I don't know if it's even gone that far.
I know. I don't think it has. But we're back together because we had a great show talking about
the steering council, the future of Python governance, and all that kind of stuff. And then we hung up.
Well, we stopped the recording. And I just threw this offhand comment about, oh, and what do you
think about WebAssembly? Yeah. I mean, this happens every time I come on your show. We end up chatting
after the hangup. And then it comes up, oh, we should have brought that up while we actually had
the microphones recording. Yeah. And so we're going to be here at PyCon. We're recording live from the
PyCon Expo Hall Center here. And that's what the background noise is everyone hears. So we're
going to talk a little bit about WebAssembly. And I guess maybe we should start with what is this
WebAssembly? Why is it interesting? To me, it seems like WebAssembly is starting to gain some traction.
Yeah. So I'm going to preface all of this as I'm a fan and keep up on this out of interest. I actually
almost made something similar to this, my PhD thesis, except my PhD supervisor, Eric Wellstetter,
was smart enough to say, no, that's a bit ambitious for one PhD because that's going to take three or
four other PhD students. And he didn't want to dedicate that much time of his life to the topic.
I'll be your advisor, but come on, not for life.
Exactly. So I'm just going to fully admit, I could quite possibly say something wrong about this.
But basically to explain what WebAssembly is, is the browser vendors all got together realizing that
while JavaScript is nice, it's not the end of the world and the best answer necessary for everyone.
and they want a more lower level kind of target for languages in browser. And so they basically
designed an assembly language specifically for the web. And the key thing here is you can think of it as
basically like x86 or ARM or RISC or any of those other chips that have the low level assembly commands
that the CPU actually executes. But the key thing here is it was designed to be performant,
but also verifiable to be safe because as we know on the web, you can't trust everything that
could send to your browser. So they very much made sure it was fast and verifiable, which is
and cross-platform, which is also very cool.
Yeah, I think that's the first danger when you think, all right, we have this binary thing and
we're going to download it and execute it in your browser. They're like, oh my God, is this ActiveX?
Is this calm? Is this the thing that's going to hack all the machines?
We all know you do not download a random binary off the internet and run it and expect not to get
some nasty malware installed on your machine. And the same goes for WebAssembly. You don't want
a buffer overflow in your browser, right? That's hard enough just for the browser vendors to do with
the render. The last thing you want is the JavaScript or anything else you download to just make
a button flash to actually cause a buffer overflow and suddenly take over your machine.
Right. So WebAssembly is kind of this assembly language. It's faster, it's binary, but it's run
within the same sandbox as JavaScript.
Yes, from my understanding.
More or less.
Yeah.
But there's some really interesting things. A lot of things that compile to see can be made to compile
to WebAssembly.
Yeah. And that was actually the original way they tested this idea was there was a project called
asim.js and they created a tool for LLVM called mscripten. And what they did was they just came
up with a subset of JavaScript that you could actually compile C down to. And it was basically
typed arrays to simulate a stack in memory and a bunch of other stuff. And they basically made it
work. And they were able to show that if you added certain markers to tell the JavaScript's
execution engines that, hey, you know what? This is actually asim.js, not normal JavaScript.
They could actually get really good performance out of it. And that was enough of a motivation
for them to go like, okay, let's make this a real thing. Let's not do kind of a weird little
subset of JavaScript. Let's like do a proper assembly language that will still get us the
exact same compile target and safety with even better performance.
Right. Let's not try to treat JavaScript truly as assembly language, but make something that
executes like binary bits, right?
Exactly. Everyone's already compiled to JavaScript and knows it's possible, but let's actually take
it to the next level and actually compile to a reasonable target.
That's awesome. Did you happen to catch the birth and death of JavaScript by Gary Barnhart?
No, I didn't.
Oh my gosh. So this is such an insightful thing. So people out there listening, they're interested.
They should definitely Google that. Maybe I'll put it in the show notes.
It's a talk he did at PyCon, I think 2015. And it imagines a future where JavaScript takes over the
world, talks about the future, like 2030, going down this Asm.js world and things being compiled
deeper and deeper and deeper in the world, just being all JavaScript. And it's both super insightful
because it talks about these things and predicts stuff. He's got examples of like having Quake,
which is written in C run in Chrome, but then recompile Chrome to run in Firefox. So like
Firefox is running Chrome, Chrome is running Quake, all like nested together in this, like it's
turtles all the way down with JavaScript.
Well, actually, I don't know if you caught Dan Callahan's keynote at PyCon US in 2018,
but he did something similar where he showed a VR of a computer in a basement running similar
Windows 3.1 running a browser in it. So you can go very deep with this stuff.
Right. And so many of those were these sort of these proof of concepts into some JavaScript
world. But WebAssembly is like, well, that's cool. Let's make that official.
Yes.
That's the stage for what the heck is WebAssembly. Now the big question is, CPython, right in its name,
we know it's written in C. What are the possibilities for it being interacting with,
doing interesting things with WebAssembly?
There's basically two current projects that I'm aware of. So one is Pyodide,
which I believe you'll have an episode out on this, if not already.
Due to time shifting. It's not out yet, but it's out before this. So people will have heard of that.
So go back and listen to that episode. But basically, someone at Mozilla has taken CPython
and the scientific Python stack, so SciPy, NumPy, Pandas, all those.
Which are heavily C underneath, right?
Oh, and more, right? Because this also includes Fortran stuff.
Like, this is deep level stuff, right?
SciPy is crazy to compile.
But what they did was, is they actually compiled that whole stack down to WebAssembly.
And they got it running.
And if I remember correctly from the blog post, they said it was three or four to 12 times slower,
which is not great.
I mean, compared to some things, but it was still actually fairly performant to the point that they actually,
Mozilla has a demo, I believe, of Jupyter Notebook style workflow for data science exploration that actually works reasonably well.
Yeah.
And what's cool about that project is they've actually compiled the libraries that you need.
So you can import NumPy, you can import Pandas in the browser.
It'll go get the WebAssembly equivalent, suck that down on demand, by the way, which is cool.
It doesn't even suck it all down in front.
It's like, wait till you hit the import statement.
And it sucks it down and it runs.
So that's pretty cool.
But to me, what that feels like, and not to take anything away from it, it's super cool,
is that feels like, let's take the compilers we have and point them at the version we have
and make them run in this place best we can.
But it's not saying, what if we imagined what a CPython-developed for WebAssembly could be?
Yes.
It's very much a, let's take what we have already and see if we can make it work.
Not a, let's make this a target of something.
And what does that look like?
That's a good question.
That is a good question.
So I think it's, I mean, it's super noble.
It's awesome that they've done it.
And like having Quake run in the browser, it proves it could be done.
Yes.
But size, size matters sometimes on the web.
Right.
And they fully admit in the PyoDiode project, I believe the download for the interpreter is
40 megs, roughly.
So it's not small.
We might all be living with one multi-meg pages now, unfortunately.
But they're not 40 megs.
No one's that crazy.
So there's definitely issues.
Now, I'm also going to say that not all use cases for WebAssembly necessarily require a
smaller download size.
So for instance, if we were doing an Electron app.
Like Visual Studio Code.
Visual Studio Code.
Or something else.
Slack or any other Electron app I can see out on the shore floor from someone sponsoring PyCon.
They don't have that download size restriction.
They could totally just embed a 40 meg version and be done with it.
Right.
The Electron JS apps, for people who don't know, already embed the binaries of Chrome plus the
binaries of Node.
So throw in a few more megabytes of WebAssembly.
Who cares, right?
Whatever.
But obviously, if we wanted this to be on the web or in more size restricted situations,
like we're talking more embedded space or you're embedding it in a smaller, more native desktop
app, like think Blender or something.
That's where you start to care about the size.
So directly compiling and see Python.
While great is a great solution for today, it might not be if we want to potentially expand
the possibilities in the future.
Right.
And Python is doing awesome.
I mean, we've seen the stack overflow, the incredible growth of Python article.
Yep.
I mean, look around PyCon this year.
Like to me, when I walked in here, I felt like, wow, Python's grown up a little bit.
Like these booths are a little more corporate, a little more pro.
They're like taller.
I don't know what that means, but they're like twice as tall as last year.
Yeah.
I mean, I was kind of shocked when I came in here and I saw stuff hanging from the ceiling.
I saw people with walls put up and these aren't just like custom for the booth walls.
I mean, this is really slick stuff coming in here.
So yeah, Python's definitely come a long way since I started using it.
Yeah.
And so my point is, that's amazing.
But how far would it go if it could be in mobile, if it could be on the front end of web,
if it could be the foundation of these Electron JSA?
I mean, there's like lots of growth.
There's headroom here for more.
Yeah.
And if you get a chance, watch Russell Keith McGee's keynote from PyCon US 2019.
It was on Friday.
He did a really good job of outlining why this is a potentially great growth opportunity for Python.
We're in a lot of spaces, right?
As I said, we're embedded.
We do scripting.
We do some desktop apps.
We do web.
We do data science.
But for instance, we haven't really tapped into the mobile space or the web space front end.
Obviously, we got backhand covered.
So there's definitely opportunity for us to grow the community and help bring more people in.
Because I've been told we have one of the best communities in the world.
So I'd like to honestly do this just so we can get more people actually in and participating and off of communities that they might not be happy with.
Yeah.
And to me, it feels like WebAssembly kind of holds the key to unlocking some of those possibilities.
Yeah.
I think it's a definite possibility.
I don't think we can necessarily claim it's definitely a panacea or that it's an obvious black swan event.
Another reference to Russell's keynote.
But I think there's definitely enough there to make it a very interesting possibility worth looking into.
Okay.
So I guess let's think about you are on the core dev team.
You are also on the steering council.
You obviously don't make all the decisions, but you're in a place to have some internal insights.
What would need to happen?
Or is there any possibility of CPython having an official WebAssembly story?
I don't know.
So in any official capacity, I have to say, I don't know.
Personally, I would love to see it.
One thing I can say is we've had some very initial discussions on the steering council about kind of coming up with a vision document of what would it take to make Python two times faster?
Right.
And kind of like outlining like what do we view as necessary?
What do we view as acceptable?
What do we view as total fertile ground?
And we don't care what you do.
And we've just started talking about this.
So there's nothing specific there.
But I mean, you could theoretically think of some company going like, oh, okay, I've read this document.
I see kind of where you're going.
We're going to take a stab at it and we're going to try to make a WebAssembly Python.
Now, who knows what that means?
That could either mean let's see what happens if we didn't do see Python to WebAssembly, but we still had an interpreter that was more restricted to make the size smaller.
Or someone could even do a straight Python to WebAssembly compilation target.
Now, I don't know what we'd have to give up for that.
For instance, for my reading of the spec, WebAssembly doesn't provide a way to directly execute on the fly compiled WebAssembly like actual assembly does.
Right.
That's how JITs work.
They actually write to a memory point and you basically treat it like a function pointer in C and that just magically gets executed.
There is no equivalent from what I can tell in WebAssembly.
So that would potentially make eval and exec a problem if we were trying to compile Python straight to WebAssembly.
But I think there's opportunity there to explore all this stuff and see where it goes because there's general excitement from what I've been seeing and hearing from people about this idea, not just for Python, but the overall tech community as a really clear, cool opportunity.
I mean, Cloudflare is doing JavaScript on the edge computing, but it's JavaScript, but you can compile the WebAssembly.
And then recently Fastly came out and just said, we're doing straight WebAssembly.
That's all we're doing for their edge computing.
There just seems to be a real kind of conglomeration of people, at least in the web space around this as a thing.
And obviously, we all know the web's got a lot of money and a lot of push.
So I think it's worth at least considering and taking a look.
Yeah, that's a super interesting point.
There's definitely a huge, huge number of users there.
I mean, Flask, we consider Flask to be like one of the more popular things, right?
It's got 41,000 GitHub stars.
Just Vue.js has 140,000.
I mean, like the scale is massive, right?
So the days are early, I think.
So if we could tap into the whole WebAssembly space at the early days, you know, how much could we make Python a first class citizen there?
Yeah, I mean, and that's really what I would love someone who has the time and resources to actually look into, right?
Like really doing the research, finding out how possible it is.
What would we gain?
What could we make it as fast to see Python if it is slower or faster by how much?
It's something I would just love for someone to just go out and try.
Yeah, it's super interesting.
I mean, we talked about Pyodide, and that's really great.
But that's super focused on getting the scientific stack on the client side in the browser.
Yeah, and I believe Mozilla even admits that it's fully a proof of concept.
It's to show that this is possible.
I don't know how far they plan to take it.
So I don't know where they could even push it.
But I mean, it'd be great to see.
Yeah, another one that's really interesting that's not anything to do with Python but comes from your home base in the Microsoft world is Blazor.
Are you familiar with Blazor?
A little bit.
Yeah, so Blazor is take the .NET CLR, which is also JIT-based, and take C# and turn that into a front-end single-page app framework through WebAssembly.
So if they were able to get the CLR and all the UI bits down, it seems like the CLR and CPython are sort of comparable in size and complexity, ignoring the libraries.
I think it definitely shows that with the resourcing, it's definitely possible to use WebAssembly as a target, even as it is, which the WebAssembly team and the website and everything are very clear that this is very much a minimum viable product.
And they are still very much working towards it.
Like, they just announced something called WASI, W-A-S-I, which adds a system interface.
That's what the S-I stands for, to WebAssembly, because they realize that with a portable target, you can now actually start using this for more desktop application and execution, right?
So basically, if you start to treat WebAssembly as kind of the world's common interpreter layer, and you start targeting that, it starts to really open up.
And in order to make that work, you really have to have that layer of basically POSIX on Unix would cover.
And so they're very much working towards that.
It's still early days, but once again, there's definite possibility there.
Absolutely.
So let's bring it back to your original statement.
What if you could make CPython two times, well, Python two times faster?
What are some of the ideas you have there?
For Python, it's in general or specifically for WebAssembly?
Let's start with in general.
I think the key thing there is going to be really outline exactly what is like things we just cannot give up, right?
Like compatibility, at what level?
Where would we go?
Like, okay, if we gave this up, the community would just never even contemplate it.
It just would break way too much code, whatever.
It just wouldn't work.
Right.
If C extensions went away, that's probably a bridge too far.
Exactly.
Right.
Like, what would we be okay with transitioning, right?
Like we've done two to three and we know how difficult that was, but we also know why that was difficult.
If we had ways to automate bridging and such so that that pain wasn't there, that's a possibility.
I think it's PEP554 that is multiple sub-interpreters.
Yeah.
Eric Snow's PEP.
Yep.
Would it be possible to maybe use that as a compatibility layer these days?
Right?
Like you take the stuff that runs over here and you got to do an eval.
So we're going to do the eval and another.
That's an interesting idea.
I honestly have not thought about it.
That's all I know.
I haven't really thought much about it either.
But it seems like you might be able to have like a compatible older CPython that handles the cases that's not as fast.
And then like a proper, maybe like a jitting.
That comes tricky because all that's running in the same process.
So suddenly you're getting a multiprocessing scenario and that always has its own kind of worms that if you're not really aware of how it's working and what the edge cases are, it can really show my problem.
So I don't know.
Maybe it's not worth pursuing.
Yeah, probably not.
Yeah.
I know a lot of people want that idea of when we're doing the two to three bridging and no one ever really got to work properly.
So I'm going to assume in any other scenario, it just ain't going to work.
It just wasn't worth the trouble.
Okay.
Interesting.
I honestly don't know.
Like I know there's Rust Python and people are working on that.
I've always been curious to see what Rust could give us in terms of safety and performance.
I also know though, some people don't want to go that route because at least in CPython's case, Rust is not available on every platform where there's a C compiler.
And so there and the embedding story is there, but it's not necessarily quite as straightforward if you don't put in the work to do that.
I mean, you can give FFIs through C through Rust, but that's an extra layer of work.
Right.
Maybe slower too with another layer.
So I think the key thing here is also don't focus too much on CPython itself.
I mean, if we're talking website, we're talking basically a whole new thing.
So I totally up and just even first proof of concept for whatever.
I would want people to try anything and don't tie yourself to CPython as necessarily the starting point.
Tie yourself to CPython as kind of the way to test your compatibility.
Although I would still say, don't tie yourself to every edge case and every little potential bug.
Because Guido has even said before he retired that really small edge casey parts of the language that no one really uses would be up for consideration from being deprecated and removed from language if it made a massive performance difference.
So people have also never done that exploration.
So we even have that potential, regardless of WebAssembly, of ways to potentially speed up Python.
This portion of Talk Python To Me is brought to you by Microsoft.
For ultimate developer productivity in the cloud, use Azure extensions for Visual Studio Code.
You can deploy and debug your serverless Python apps directly from your editor.
On Azure, you can run your Python apps as serverless code on Linux web apps and functions or on top of managed Kubernetes and easily connect data from database services, including Postgres and MySQL.
You can also use Azure DevOps to create cross-platform builds of your Python packages with hosted macOS, Linux, and Windows build machines.
And publish them to Azure Artifacts for your own hosted PyPI feed.
Azure DevOps is free for open source projects and many are using it already.
Get started for free at talkpython.fm/Microsoft.
We've had a lot of progress, right?
Yes.
From 3.5, maybe 3.4, let's say 3.4 to 3.7.
Yes.
The stuff that Victor Stenner was doing and other people, you would hear, oh, dictionaries got this much faster.
Function calls got 20% faster, bound methods or whatever, right?
Year over year, that stuff's compounding as well, right?
And I don't think we've even necessarily hit all the low-hanging fruit, but I do believe that we're reaching a point where I think on the team,
we're realizing that our goal from years back of keeping the interpreter simple, specifically to make it easier to contribute to,
by making it easier to comprehend how it works.
Basically, Python's so big, we can't really do that anymore.
I think we've hit the point now where we don't worry about whether a single individual can fully comprehend how the entire interpreter works,
because we realize that so many people rely on it.
We need to keep it maintainable, obviously, but we don't need to keep it simple.
And that's a very key distinction.
And so I think there's opportunity there, once again, if someone had the time and resources to really dig into that
and see what would be possible to actually speed up CPython itself and obviously whatever crazy thing someone might do.
What's the possibility, likelihood of some kind of JIT making it a point?
I know you worked on Pigeon.
Yep.
Which maybe, I lived in a different country when we last spoke about Pigeon.
Maybe tell people quickly about what that is.
Pigeon, for those of you who don't know, and it's spelled P-Y-J-I-O-N,
was a project with Dino Veland, who was a co-worker at the time, now at Facebook, and myself worked on back in 2016, I believe?
Yeah, I think it was 2016, yeah.
Where we looked at what it would take to jet CPython executable bytecode using .NET.
And we got the project to the point where we developed a PEP for adding a hook into CPython to allow you to override the eval loop,
the actual function that you pass commands through.
Which is like 3,000 lines switch.
It's an impressive thing.
It's a very large thing.
Eval.c, yeah, that's it.
Eval.c has got a, it's quite the impressive function.
But basically, we tried a way to hook into it such that if we took some Python bytecode and compiled it down into .NET IR,
which is stack-based as well, which made the translation, I'm not going to say straightforward, but at least possible,
we did it and we managed to hit the Python benchmark suite pretty much even.
Unfortunately, once, after we did our PyCon talk, work got in the way and we just weren't able to pursue it any farther.
Yeah, I remember you said it got even and that's pretty good.
How much more do you think it could have gotten better?
A lot?
Or is it kind of like...
That's one of those things where with JITs, you just never know.
Like if you talk to the PyPy folks, they'll fully admit, I'm sure, that PyPy is excellent and can go really fast if it works for you.
But for some people, they need very deterministic performance because JITs always work on hot code and such.
And it can be very variant based on the current workload.
Right.
With the reference counting in CPython, it's pretty predictable.
Yeah, exactly. So I don't know what PyJint could have been had we put more time into it because JITs, by definition, are very load dependent.
And so there's just no way to even speculate.
How much does a GC and generational garbage collectors are required around JITs?
I mean, most of that unpredictability has more to do with the garbage collection side of things than they do with the JIT.
Because you could pre-JIT stuff and things like that if you had to.
I don't think it necessarily really ties into it specifically.
So for those of you who don't know, CPython uses reference counting to do its memory management, which basically means we keep track of the number of places an object is referred to in your Python code.
So every time you do an assignment, the count goes up by one.
And every time a variable goes away, goes down by one.
And basically when an object hits zero, we garbage collect it.
Yeah.
It's very straightforward.
But the nice thing about it is it's very deterministic, right?
So if you define your dunder del on an object, you can actually see that execute fairly quickly after you actually delete the object.
With garbage collection, you don't get that.
So really the bigger problem with that has always been the C API.
Because it's very directly exposed for C extensions to be able to properly manage the memory that they need for any objects they create.
And that has always been a stumbling block for things like the GIL because in order to control that kind of stuff, there's overhead.
And the real key thing is the global interpreter lock exists specifically for reference counting because that's how we make sure you don't accidentally stomp on each other when like two threads try to both increment or decrement.
And you don't want to lose all of those because if you get the count wrong, that's a memory and that's not a good time.
It's either a crash or it's a memory like depending on which way the race condition runs.
Yeah, whichever badness you want, choose one.
Yeah, okay.
You just don't get to choose though because one of the threads will choose for you, which is the problem.
So I honestly don't know from a JIT perspective if it really specifically matters depending on how you decide to handle it.
But getting off of a rust kind of opens things up because it gets rid of that single point of contention with the GIL.
Right, okay.
That's interesting.
I think the GIL gets more negativity than it deserves, honestly.
It's one of those things where if you're IO bound, it doesn't matter.
And if you're CPU bound, it can, but only if your load is that high that this is really a critical thing.
Right.
So there may be some C library that's already doing parallelism for you or...
Yeah.
And if you look at Eric Snow's work with subinterpreters, there's the potential there that if Eric can get it all working to have per interpreter gills,
which would then give you per thread interpreters, which would then let you have GIL release because basically each interpreter in its own thread running on our gill, which should still have its contention.
But it's equivalent to basically running completely free threads, which would help a lot.
And it doesn't require us to completely rewrite every extension.
And we don't have to try to detangle all this world.
And we get to keep the very straightforward and determinist reference counting.
That's all really interesting.
And I guess sort of a roundabout.
The reason I was asking about a lot of these things is if your goal is to make Python run twice as fast, there's all these options, but there's all these limitations because of the history of the implementation of C for Python and the C, you know, Val.c and all that.
What if it was written in something like Rust or something else?
I guess let me also preface that with like Rust is all about compiling to WebAssembly.
So could you get your one benefit and then unlock this other WebAssembly world at the same time?
I think it's definitely possible from my understanding.
I don't know what kind of restrictions your Rust code has to be placed on it in order to compile down to WebAssembly.
But I think it's definitely there.
For some people, CPython is just a Python interpreter.
And it's not a critical aspect that it has this extensive C API that allows you to do these C extensions.
And for others, it is.
And that also varies based on people who embed CPython and a C or C++ application and those who don't.
Like design apps that have an automation or whatever.
Yeah, like Blender is a perfect example.
Blur Maya, a lot of the 3D, the special effects tooling in movies often embed CPython specifically because they want Python embedded as a scripting tool.
So for those people, that would matter if the hypothetical Rust implementation didn't provide those kind of hooks.
But for others, it wouldn't.
This is one of those things where for me personally, I've always viewed it as Python the language as implemented by CPython the interpreter.
And so I view the key component as the language.
And we just happen to have this CPython implementation, which, by the way, is really great for embedding as a thing.
But I don't think that necessarily means that CPython, in my personal view, as like special or in some way untouchable or unreplaceable in terms of at least having other options.
I mean, PyPy exists and it does have users, right?
There's a reason it's there.
It doesn't work for everybody.
And that's fine.
The key question is, is does the community and do other people who have the time and resources to put in the work to look at making Python faster, whether it's through WebAssembly or through Rust or through helping make CPython go faster, do they have the stomach and the, honestly, gumption to take some of these paths and try to make it happen?
That I don't know.
And honestly, I can't answer that until the community as a whole kind of comes forward and says, we're going to give this a shot and we see what happens.
Yeah, I mean, that's a really big question.
We just kind of put to bed this whole Python 2, Python 3 saga.
And I know it's a totally different story, but it's kind of just churn and fatigue for some folks.
And so, you know, how much do you want to like rattle that cage?
Maybe just let things settle for a while.
I don't know.
I know for a long time, a lot of people have hoped that once Python 2 was laid to rest, that the mental, honestly, the cumulative mental capacity of the community would suddenly be freed up because suddenly all this Python 2 stuff would kind of just go away.
The weight is off us.
Yeah, the bite of our collective brain that had to still deal with Python 2 would now be free to just try to make Python 3, which then honestly is just going to be Python, just make Python faster and better.
And I would like to think and hope that that's going to happen, but I honestly don't know.
Once again, that's going to come down to the community coming forward and saying, you know what?
We want to help make this happen and we're going to work with everyone as necessary to make that a thing.
Yeah, well, maybe we're entering a period of where lots of flowers will bloom.
Some of them will wither.
Some of them will grow into trees or whatever.
But, you know, for example, taking CPython itself and just compiling it to WebAssembly and getting it to run, say, in like an Electron JS app, like that would be a huge win for deployment, I think, because all you deploy is this little WebAssembly binary and it just loads up in the Chrome.
And maybe that unlocks one area of growth.
Maybe Pyodide does something for the data science and there's a bunch of different areas.
And eventually we find what's working, find ways to adapt them.
I don't know.
What do you think?
I'm honestly, one thing I'm curious about with WebAssembly is whether the phone OSs are going to start potentially adopting it as a target as well, right?
Like I could imagine a world where Android and iOS suddenly started allowing WebAssembly as a compiled target versus specifically Swift and the raw C stuff on iOS.
Or the equivalent on Android or its art on JIT.
And I don't know if WebAssembly will catch that much.
But if it does, that really opens it even to an even greater extent in terms of the usefulness and potential importance of WebAssembly.
Because if you get that, then suddenly you have the web and you have mobile.
And with Wazoo, you get desktop.
That's a crazy amount of the user base in terms of just flat out computer users.
It's just crazy.
Yeah.
I mean, the three places I see missing the huge growth opportunities are desktop, mobile, and front end and web browsers.
Yeah.
That kind of hits them all.
Yeah.
And once again, I'm just going to keep harping on this.
It's really going to come down to the community coming forward.
And I do want to say I personally really hope that whatever the community does do, we're able to work together as a community.
Like, I don't want to see fragmentation of, oh, I've done this thing, this version of Python that's slightly different.
And, oh, this person over here has done a version of Python that's slightly different.
And we haven't talked as a community about what we care about.
And try to also pull everyone together to kind of work towards a common goal versus, oh, I think we should do it this way.
No, I think we should do it that way.
Okay.
Well, I'll re-implement Python with a garbage collector over here.
And, oh, here.
And I'll do it a different way over here.
And there's no way for them to work together.
I understand experimenting with different ways, but I would still want them to hopefully end up in the same spot together such that we're just not wasting time and energy.
Because as you commented earlier, we already did that with the Python 2 to 3 transition.
It was somewhat painful, but we got through it.
And there was reasons for it.
And I don't regret it.
But I also don't want to ever purposely do that again if we can avoid it.
And so my big hope is we can get the community to come together as a group to try to decide how we want to make this happen.
Yeah, I definitely second that.
I don't want to dictate much is my key point.
And I can't speak for my other steering council members, but I don't think they want to either.
I think our key goal in anything, if anything does come out, is how can we help shepherd the community towards a single point and try to give guidance to help make sure that everyone is able to work together as a community.
I think that sounds great.
One of the things that might be cool, you talked about maybe eval not working, for example.
And is that a problem?
I don't even know how much of a problem that would be.
I don't know.
I mean, for instance, for a long time, named tuples required it.
Yes, I remember.
Yeah.
And a lot of people didn't know that.
And then that just got changed, I believe, in 3.6, perhaps?
Maybe 3.7?
Yeah.
Versus blur for me.
Yeah.
So yes, for the longest time component that a lot of people use in the starting library would not have worked.
So it really, it's one of those things, as I said, I don't know.
Edge case stuff.
I think the team would be open to ditching things that really can be shown as like, yeah, not a lot of people use this.
And boy, is it a pain to implement.
Let's really consider getting rid of it because it's just not important enough to keep around for that performance boost.
One of the thoughts I was having is, what if there's like a, something like a subset standard Python language, like, okay, maybe we can't have meta classes, or we can't have eval, or something that's kind of edge.
Or maybe, I don't know.
But if you target like this subset, it's guaranteed to run in some WebAssembly world, in CPython, maybe in PyPy, maybe like we're a...
Well, so have you heard about mypyC?
I've heard of it, yeah.
Yeah.
So for those of you who don't know, the mypy team has implemented a tool called mypyC, where basically they can take a subset of Python that's fully typed, run it through mypy, and they use mypy as actually a compiler front end to drive it to a Python C extension backend,
and actually emit a Python extension for your Python code.
And it was originally written for mypy, I assume because Dropbox wanted mypy to run faster.
But they've actually gotten mypy to run four times faster than what Guido's told me.
Wow.
At Dropbox by doing this.
Now, they fully admit it.
It was fully written for mypy, and it's got a very specific subset, and it's very targeted.
But that does tie into your whole, like, what happens if we make it so that, if you care, just type Python end to end for your code, and then pass it through something like mypyC.
And hit that target.
I mean, some people have done that with Cython, but Cython is very much...
It's kind of got its own little bit of syntax.
It's got its own syntax.
You've got to, like, do its style, you know.
Well, they've actually added type hint support for it.
Which is awesome, yeah.
Which is great.
But Cython is also typically targeted much lower constructs like C-level ints, right?
And void stars and structs and that kind of thing.
While mypyC is targeting a higher level, not such a C-level bridge like Cython, but very much specific.
This is just normal Python.
We just want Python faster.
Yeah.
So it's a slightly different opportunity from what Cython's been targeting all these years.
And done a good job at them.
Cython definitely deserves credit for what they've done.
Absolutely.
So there's a lot of possibilities.
I don't know if WebAssembly has to be here or not, but it seems like it could be.
I think it's definitely worth a consideration.
I think, as you...
Hopefully people can tell through the excitement in our voices.
I think both Michael and I obviously think it's a great thing.
And I think it's a very cool piece of tech.
And I like the motivation behind it.
And I think they seem to be driving it for the right reasons.
And I think it's definitely worth looking at.
I think it's just a question of what benefits will Python get as a community?
And will that be enough to cover...
Tick five boxes or tick two boxes?
Right, right, right.
Or 10 boxes even because we just don't know.
It's enticing enough that I really do hope someone gives it a solid go.
Yeah, I concur.
And one of my bits of excitement is around how it seems to let languages interoperate.
If you can get something to get down to WebAssembly, you can get it to play with other things that it might not, right?
If I can compile CPython to WebAssembly, I can now get it to do JavaScript-y things with JavaScript and work with other stuff and Rust.
If I can get it there, I can get it in the space as well.
There seems like it could be a cool integration layer.
Oh, most definitely.
If you look at the WebAssembly spec, what it actually specs out in the MVP,
is basically unassigned and assigned ints, both 32 and 64, floats and functions, plus imports at the module level.
But the key point is because they're specifying at the function level,
if you wrote something in JavaScript and had it compiled down to a WebAssembly function...
If you could export that function.
Exactly.
So now at the WebAssembly level, it's available.
So as long as your code, as long as Python knows how to work with WebAssembly code, it can do that.
And actually, there is a WebAssembly implementation called Wasmr, which I believe you talked about on Python Bytes.
Yes, we did talk about it on Python Bytes.
And Wasmr is super exciting.
Tell people about that.
Yeah.
It's like the reverse of what we're talking about in a sense.
Yeah, yeah, exactly.
So it's a WebAssembly implementation.
But one of the interesting things they've done is they've defined their own basic kind of C API.
And so what they're letting other languages that can do C API work is they allow you to actually use it like an extension.
So what Wasmr has is they actually have a C extension for Python that will actually let you load WebAssembly code into Wasmr.
And then make calls through Python into Wasmr itself to do execution on your behalf and then come back.
Kind of like what your idea was earlier, Michael, about could we somehow use a sub-interpreter to do backwards compatibility?
This is actually using kind of like almost a multiprocessing kind of like out through an extension call to have some WebAssembly get executed on your behalf and then come back into Python.
Yeah, it's really cool.
To me, when I saw it, I felt like it's a little bit like what Node.js did.
So JavaScript was stuck in the browser and it lived in the browser and it's a web thing.
But then Node.js came along.
All of a sudden, we could take this stuff and bring it to run on the desktop or on a server.
And it brought it.
So this lets us take anything that would run in WebAssembly and now bring it into your Python application on the server side.
And run it.
And that's just that's a pretty exciting, different take on this angle here.
Yeah, I mean, I think it's a very clever way to try to start that bridging of showing people the benefits of WebAssembly, but also just making it useful today.
Right.
Because like there's plenty of great stuff being written in JavaScript or any other language that can target WebAssembly, Rust.
And there's no reason why you can't reach for it through that mechanism.
So I think, once again, it acts even just at some levels of proof of concept to show what the possibilities are.
If as a technical community, all up, what would happen if all languages and tooling and all that started to actually start to tackle the WebAssembly as a target and try to actually work towards that as a common goal?
It's early days, but it's exciting to imagine what might happen.
It feels very utopian, amazing if we could have it.
And it's kind of cool and exciting because it seems not totally bonkers to actually aim for it.
So, yeah.
People have always said that JavaScript is the assembly language of the Web, but maybe WebAssembly actually is going to be what we get to.
This portion of Talk Python is sponsored by Microsoft and Visual Studio Code.
Visual Studio Code is a free, open-source, and lightweight code editor that runs on Mac, Linux, and Windows with rich Python support.
Download Visual Studio Code and install the Python extension to get coding with support for tools you love like Jupyter, Black Formatting, Pilot, pytest, and more.
And just announced this month, you can now work with remote Python code bases using the new Visual Studio Code remote extensions.
Use the full power of Visual Studio Code when coding in containers, in Windows subsystem for Linux, and over SSH connections.
Yep, that's right.
Auto completions, debugging, the terminal, source control, your favorite extensions.
Everything works just right in the remote environment.
Get started with Visual Studio Code now at talkpython.fm/Microsoft.
I think that pretty much covers it for WebAssembly.
I do like these two projects that are out there, and I want to see more.
I guess maybe we should throw a little love to Rust Python as well, which is a cool project.
And you mentioned it earlier, but its goal is to, let's see if we can rewrite CPython in Rust.
And there's a lot of options.
Like, what if we reimagined what CPython was supposed to do with some compatibility in mind?
Or, I don't know, something like, but for WebAssembly, right?
There's some options.
Yeah, and the only clarification I make is I don't think it's a target from CPython to Rust.
I think they're doing a full Python itself, re-implementation, right?
So it's not like they're taking CPython and slowly implementing bits of Rust, kind of like what Mozilla is doing with Firefox.
And it's kind of like an inside-out kind of growth of Rust.
They're doing it fully Rust from scratch.
Yeah.
I mean, with the amount of tooling and work that Rust is pulling into the WebAssembly world as something they very specifically care about,
it does potentially open that implementation if they manage to reach a level of compatibility that people are happy with to get us Python in WebAssembly, potentially.
Yeah, it's very exciting.
Awesome.
All right, well, let's talk about just a couple of other things while I got you stuck here on the Expo floor hall.
Sure.
We talked about the 2 to 3 thing.
Yep.
Let's just talk a little bit about sunsetting the whole Python 2 thing next.
Yes.
Where are we right now?
It is May.
Seven months from now, we're going to be officially at the sunset.
Like, what's the plan?
Is that just going to happen?
Is there something happening to, like, shepherd that?
The steering council is just starting to get ourselves out from the pile of open peps that we started off dealing with when we first got elected.
And so we're just starting to have conversations among ourselves of, okay, what do we think we can do if we can somehow help direct some energy in the world and such?
And so we've just started just, like, very much, I mean just, started having conversations with the PSF about seeing if we could potentially get some funding for, like, a PM to help us with the sunsetting of Python 2.7.
Because, like, if you go to the python.org website, it says Python 2, Python 3 everywhere.
But you know what?
Come January 1st, 2020, it just should say Python.
All the little, oh, two here, three there, all that should just go away because now it's just Python 3, which will just be Python.
Well, the biggest one is if I go search for a function that's in the standard library and I click on the result in Google, there's a high probability that says 2.7 or pull down the dropdown to get to the 3.7 or whatever.
Yeah, and how do we handle that, right?
Do we do it with redirects?
Do we just totally get rid of it?
What are our options?
I don't know.
But it's definitely something we should look into.
And I think we're hoping we can get some, basically, professional help to get that done.
Because, obviously, that's going to be potentially a slight slog and asking a bunch of volunteer core developers to go through the website and all our documentation and just remove every mention of 2.7.
I don't think that's going to go well.
Command F.
Yeah.
Put 2.7.
Type 3.7.
Let's really test VS Code's global search and replace.
The other thing, though, is there's going to be some decisions that have to be made.
And someone's going to have to stay on top of this, right?
This is very much going to be a detail-oriented thing to keep a massive to-do list of things to get done.
And once again, asking a single volunteer to try to act as the contact point coordinator for that is probably going to be way too much.
So I'm hoping this initial conversation will go somewhere and we're going to hopefully be able to get a PM or something to help us kind of make this happen.
Yeah, it sounds like a great plan.
And also, honestly, I guess it's kind of a nice first step to see what it's like for there to potentially be hired help to help Python Dev.
And who knows where that can lead.
That can lead to a lot of good places.
I mean, we saw the whole PyPI.org relaunch because there was a little funding brought in there.
And that had been kind of been chipped at for a long, long time.
And then, you know, six months later.
I've personally said that I think there's possibility, but we've not had those conversations yet.
Among even the steering council, let alone Python Dev all up, what that potentially could look like or mean.
But I think there's some potential opportunity there.
Yeah.
If this works out, everyone's amenable.
And honestly, once again, we can get the funding.
Yeah.
Minor thing, funding.
Yeah.
Money.
It's just a thing.
Just paper.
Come on.
Yeah.
All right.
And then you're on the VS Code team, specifically the Python side.
You guys probably made some announcements or have something going on here.
Anything you want to share?
Actually, it was kind of cool.
We've been working with the VS Code team for a while now to land some support for remote editing.
Actually, it was mainly driven by the VS Code team.
They basically talked to us about some of our needs to make sure they got addressed.
We helped test it for them because the Python extension is the number one extension of VS Code.
That doesn't come with it out of the box.
Yeah.
One of the things that drives me crazy, people say, I'm going to use some really subpar editor because I need something that's always available to me no matter what.
Even if I'm going to use SSH in over terminal.
So I'm going to choose a least common denominator option rather than maybe among all the tooling.
So what's really great is VS Code has developed a system, but it leaves them in the insiders build right now while they work out any kinks from the public announcement.
But basically, they've launched three extensions that let you use Windows 10's WSL support, Docker, both remote and local, and SSH.
And so basically what it does is it runs more or less a headless VS Code on the remote location of where your code is to get proper IntelliSense, paths, all that stuff that's normally really hairy to do on the translation side.
If your development platform is different from the development position of your code, they just basically run VS Code on that point.
And then you basically get a GUI front end on your actual desktop, which it's a really slick solution.
And I'm honestly really appreciative of the VS Code team for letting us actually announce that here at PyCon.
It was not a thing that they announced anywhere else.
We actually got to announce it here because VS Code team itself has been very supportive of us and the work we've done on the extension.
So thanks to them for that.
Yeah.
Well, that sounds pretty awesome.
I mean, that's part of the Electron.js suite aspect, right?
It's kind of already like two tier.
It's just now the tier is far, far away.
Yeah, exactly.
I mean, the analogy I use, and I think it's kind of, it feels a little like it cheapens it a little too much for the amount of work in the VS Code teams.
But it's almost like running an X11, right?
We've got the headless version running on the remote machine and you just get it on the other end.
Yeah, pretty cool.
So yeah, it's awesome.
I'm extremely happy, if for any other reason, that it closed out our top two feature requests on our issue tracker
that have been there since they joined the team and the extension moved over under Microsoft.
Yeah.
Now you can stop talking about it.
Yeah.
Now we just got to start with the next new number one and number two feature request.
Can you make it write my code for me?
Yeah.
No.
No, we don't.
I don't know if we want that.
No, probably not.
Probably not.
But people keep saying it's going to happen.
I don't know.
We'll see.
Yeah.
I actually had a prof in my master's program at CalPots, San Luis Obispo, who said, oh, yeah,
like in 10 years, code will be running itself.
And I hate to break it to you, Dr. Fisher.
It's 10 years now.
It didn't quite happen.
And yeah, I'm quickly approaching 20 and it still doesn't quite look like it's going to happen.
Yeah, there's a lot happening here at PyCon and a lot of people typing a lot of keyboards
doing cool stuff.
Yeah.
All right, Brett.
Well, thanks for coming back and following up this discussion because it was a lot of
fun.
And I think WebAssembly and Rust have some pretty amazing possibilities.
We'll see where it goes.
I think the future is bright if the community decides to make it so.
And so I'm optimistic and hopeful that it will.
And I'm really excited to see where things potentially end up.
All right, cool.
Well, thanks for being on the show and enjoy the conference.
Thanks, Michael.
You too.
Bye.
This has been another episode of Talk Python to Me.
Our guest on this episode was Brett Cannon, and it's been brought to you by Microsoft.
If you're a Python developer, Microsoft has you covered.
From VS Code and their modern editor plugins to Azure Pipelines for continuous integration
and serverless Python functions on Azure.
Check them out at talkpython.fm/Microsoft.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into
all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher 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.
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 really appreciate it.