#391: Pyscript powered by MicroPython Transcript
00:00 No Python announcement of 2022 was met with more fanfare than PyScript.
00:04 This project, announced at PyCon, allows you to write Python files and run them in your browser
00:09 in place of JavaScript or even with interactions between Python and JavaScript.
00:15 There's just one catch. The runtime download was a 9 megabyte WebAssembly file.
00:20 That made its use quite limited.
00:22 On this episode, we dive into some news that might change that calculus.
00:27 The MicroPython and PyScript folks have been teaming up to get PyScript running in the browser on MicroPython.
00:34 Yes, that's the embedded chip Python that you may have heard of.
00:38 And here's the good news.
00:39 MicroPython's WebAssembly is just 300k to download and loads at under 100 milliseconds.
00:44 Now that could unlock some real possibilities.
00:47 We have Brett Cannon, Nicholas Toleve, and Fabio Plager on the show to discuss.
00:53 This is Talk Python to Me, episode 391, recorded November 21st, 2022.
00:59 Welcome to Talk Python to Me, a weekly podcast on Python.
01:15 This is your host, Michael Kennedy.
01:17 Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython,
01:22 both on fosstodon.org.
01:24 Be careful with impersonating accounts on other instances.
01:27 There are many.
01:28 Keep up with the show and listen to over seven years of past episodes at talkpython.fm.
01:34 We've started streaming most of our episodes live on YouTube.
01:37 Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming
01:43 shows and be part of that episode.
01:45 This episode is brought to you by the Local Maximum Podcast over at LocalMaxRadio.com
01:51 and AWS Insiders Podcast.
01:53 AWS is changing fast.
01:55 Listen in to keep up over at talkpython.fm/AWS Insiders.
02:01 Transcripts for this episode are sponsored by Assembly AI, the API platform for state-of-the-art
02:07 AI models that automatically transcribe and understand audio data at a large scale.
02:12 To learn more, visit talkpython.fm/assemblyai.
02:16 Hey, guys.
02:16 Welcome back to Talk Python to Me.
02:18 Thanks, Michael.
02:18 Hey.
02:19 Thank you, Michael.
02:19 Yeah.
02:19 Fabio, Nicholas, Brett, it's really good to have you all here.
02:22 And I know you are all very excited about this topic.
02:27 Brett, I believe the last pre-COVID PyCon, we did a live on the Expo floor show about WebAssembly.
02:35 We did.
02:36 Yeah.
02:36 Fabio, we recently talked about PyScript.
02:38 And Nicholas, you're right in there as well, working on WebAssembly, PyDyde, PyScript stuff
02:43 as well.
02:44 So I know a lot of people know all of you, but maybe let's just kick it off with a quick
02:48 round of introductions and background.
02:50 Not too deep since we've all done it before.
02:52 Brett, let's go with you first.
02:53 Okay.
02:54 Keep it short.
02:54 I am the dev manager in charge of the Python experience in VS Code.
02:58 Been a core developer for 19 years.
03:00 Been on the Python steering council since Guido's retirement.
03:04 And I'll stop there.
03:05 Yeah.
03:06 Fabio.
03:06 So I'm creator of PyScript, current maintainer with Nicholas.
03:11 I've been working with Franaconda for eight years now.
03:15 Right now, I'm tech lead for PyScript and been doing a lot of community stuff around Python
03:21 for a long time as well.
03:23 Yeah.
03:23 Fantastic.
03:24 PyScript was the big news out of PyCon last year.
03:26 That, I think, cut a lot of people by surprise and people were very excited about that, including
03:31 myself.
03:32 Yeah.
03:32 I'm very excited.
03:33 And yeah, got a lot of attention for good and bad.
03:36 Right?
03:36 Yeah.
03:37 Yeah.
03:38 Yeah.
03:38 I was going to get some more attention today.
03:40 Yeah.
03:42 Hopefully.
03:42 Indeed.
03:44 Nicholas.
03:45 Welcome.
03:45 Hi.
03:46 So, yep.
03:47 I'm a colleague of Fabio's.
03:49 I'm a principal engineer on the PyScript team.
03:51 Prior to joining Anaconda in the summer, I'd been a Pythonista for far too many years and
03:56 I care to remember.
03:57 Before that, I was a teacher.
03:59 And before that, I was a classically trained musician.
04:03 And that probably explains my interest in Python in education and the activities that I still
04:09 do in that sphere.
04:11 So that's me.
04:12 That's fantastic.
04:12 You were involved with the BBC Microbit, right?
04:15 Yes.
04:15 I was involved with the BBC Microbit.
04:18 It's fun.
04:19 Yeah.
04:20 Absolutely.
04:20 Yeah.
04:21 That's awesome.
04:21 And we talked about that before.
04:22 Okay.
04:23 Yeah.
04:23 Well, let's talk about running Python in the browser.
04:27 There have been some attempts before and those attempts are still, you know, used in different
04:32 places.
04:32 I'm thinking of like Brython and Sculpt and those types of things.
04:37 Anyone who has seen the birth and death of JavaScript, that famous 15-minute talk, which
04:42 has got to be one of the most hilarious and yet insightful, like educational foundations
04:48 of the web and JavaScript and, you know, what became WebAssembly talks of all time is really
04:55 great.
04:55 And I think those kind of land in that realm.
04:57 But since then, as we started, like, you know, WebAssembly has allowed us to bring
05:02 real runtimes, mostly things based on C or REST, but older things based on C, into the browser
05:08 and run there.
05:09 So who wants to sort of introduce this whole idea of WebAssembly quickly for those who don't
05:15 necessarily know and sort of set the stage so people see where we're coming from?
05:18 All right.
05:19 I'll take it.
05:19 So you can kind of think of WebAssembly as almost portable CPU.
05:24 It's technically an instruction set that basically is almost like assembly designed to just run
05:30 anywhere.
05:30 It's all abstracted.
05:32 It's technically stack-based, much like CPython's interpreter, for those of you who want to know
05:37 insider baseball knowledge or insider football.
05:40 But that's basically it.
05:42 WebAssembly is really just portable target to compile stuff for that more or less you make
05:48 a runtime work for that target and it gets to run everywhere.
05:52 There's more details we can get into in terms of WASM versus WASE and platform-specific
05:57 stuff.
05:58 But at the core base low-level thing underpinning all of our discussion today is WebAssembly,
06:03 which is basically just a portable CPU target.
06:05 Yeah.
06:05 Okay.
06:06 Excellent.
06:06 And CPython, I guess as the name would very strongly indicate, although people might not
06:11 know, is largely C at its core.
06:14 It's not Python code.
06:16 Some of the standard library is, but not, you know, at the heart, there's an insane
06:21 switch statement while loop that is written in C.
06:24 And so that, if we can get that into WebAssembly, then we can get Python, the runtime, into the
06:29 browser.
06:30 Correct.
06:30 Technically, as long as you can compile whatever language you want to WebAssembly, that's how
06:36 we get it in.
06:36 And traditionally, the tool chains that have supported compiling data WebAssembly, either
06:42 statically compiled languages that use something like Clang as a build tool chain, or which
06:49 typically has fallen under C and C++, Rust, because once again, Rust is based off of Clang
06:55 for their compiler.
06:56 As long as your language could use a tool chain that already had the support to compile
07:00 down to WebAssembly as a CPU architecture or target, you were able to get some WebAssembly.
07:06 So in CPython's case, because it's implemented, the key parts are in C.
07:10 That was able to be compiled down such that I can run some WebAssembly.
07:14 Nicholas's work with MicroPython the same.
07:16 MicroPython's written mostly, I believe, in C as well.
07:19 And so basically, that allowed both projects to basically just use a specific compiler with
07:25 specific flags to just say, instead of writing out X64 assembly for my EMB or Intel chip or
07:31 your ARM chip on your Mac, write me out some WebAssembly instead.
07:36 People's first impression when they hear this is like, oh my gosh, binary code executing the
07:41 browser, run for your life, right?
07:43 But it's really no different than JavaScript.
07:44 It has the same permissions and liabilities and benefits of JavaScript.
07:49 It's just a different execution model.
07:50 Yeah.
07:50 The same sound bolts as I was.
07:51 That's the core.
07:53 There are a lot of nuances that comes with how it is.
07:57 It's taught, right?
07:59 One, it's still in a very young phase, despite all the usage and acceleration.
08:04 Everybody's excited about it.
08:06 But as Brett said, it's mainly a portable CPU.
08:10 And it doesn't really come with the rest of what you would expect from an operating system,
08:16 and especially file system and things like this.
08:19 So there's a lot of extra work that the larger community is trying to add now to figure things
08:24 out.
08:25 Now, and the other small detail that I wanted to add is, yes, it's basically just like JavaScript
08:32 on the browser, with the exception that some APIs are not available.
08:36 For instance, access to DOM and other things like this.
08:39 Yeah, I was going to say, it's worth pointing out that what Fabio is saying about, it's not
08:44 like having an operating system.
08:45 There are projects.
08:46 You know, Brett mentioned Waze.
08:48 There's also nscript as well, which gives you abstractions of a file system and so on and
08:52 so forth.
08:52 Such that you could, and it's always important to be aware when a developer uses the word
08:57 just, but one could just compile CPython to WASM and it will just work in the browser.
09:04 But of course, to get that to happen, it takes a rather a lot of work and browser-based expertise
09:13 to actually get you to, for instance, the Python prompt in a REPL, as it were.
09:19 Right.
09:19 Which is why, you know, wouldn't it be fun if there was some sort of project that got
09:24 you to Python in the browser without having to do all of that boilerplate stuff?
09:27 Yeah, I wonder if we could find one of those.
09:30 Yeah.
09:30 One of the things we spoke about before, Brett, was so much of what comes with Python, the
09:36 batteries included, the standard library, assumes a slightly larger execution environment
09:42 than front-end browser code, right?
09:44 Like it assumes a file system.
09:46 It assumes that you can probably open a network socket.
09:48 These types of things, right?
09:50 And so one of the challenges here is, well, if you can compile it down, that doesn't mean
09:54 it's going to be permitted to just take some code and jam it in a web page and run it, right?
09:59 Yeah.
09:59 I mean, taking the CPU analogy, the next step, right?
10:02 Like when you compile something down to a CPU for like X64, that's great.
10:08 But how are you going to read a file system?
10:10 That doesn't exist to the concept of a CPU.
10:12 How do you make things show up on the screen?
10:14 How do you do lots of other things, right?
10:17 Like that's all implemented by your operating system, right?
10:19 It's the next layer above your CPU in terms of abstraction.
10:22 And WebAssembly only has the start of this concept in one area, which is Wazzy.
10:28 And in another area, it kind of just leans hard into the browser space.
10:32 And that's kind of what we call MScripten, right?
10:34 So generally the way all this plugs together is if you look at it from a browser perspective,
10:39 there's a tool called MScripten, E-MScripten.
10:42 And it's basically a kind of compiler front end that uses client to compile stuff to WebAssembly
10:48 and then has a bunch of shims into the browser to implement stuff like file access, as Nicholas pointed out,
10:55 and all these other things you can get in a rich web environment.
10:59 But it's provided by this project called MScripten.
11:01 And it's not quite an OS, but it's not nothing either.
11:06 It's this interesting kind of middle ground.
11:08 And it's project specific.
11:10 But then on the other side of all this, there's a project called Wazzy.
11:14 And this is what when you think of WebAssembly, you start hearing people talking about this compared to containers or edge compute
11:20 and all this kind of server scenarios where Wazzy acts like POSIX, right?
11:26 So it's not actually an implementation of an OS almost, kind of like what MScripten does,
11:30 but instead it's an actual abstraction over what you might expect an OS to provide you.
11:36 So in Wazzy's case, for instance, it is an implement file access.
11:40 It implements the function to call from WebAssembly that gives you the file access.
11:45 So in that case, what you have is you have a runtime.
11:47 And that runtime is actually what provides that level of OS that you need.
11:52 So if you've ever heard of things like WasmTime or WasmEdge or Wasmr, all of these are actually Wazzy runtimes that basically load up your WebAssembly,
12:01 inject into that code the functions that Wazzy specifies on how to read files
12:07 or how to print to standard out or read standard in, and then allow them to run in an abstracted fashion.
12:14 So it's almost half between MScripten and kind of an OS, but above WebAssembly.
12:21 But as you can notice, it's a weird little split here because there's the web part and the server part,
12:27 and this is where this whole discussion gets really interesting, right?
12:29 Because it's now we're starting to have discussions about abstraction layers
12:32 and which abstraction layers are provided where.
12:35 And this is kind of where WebAssembly's youth, to put it one way, really shines through in terms of showing that it's all still very much actively being developed,
12:45 which I'm sure Fabio and Nicholas have some very fun stories to tell you about with PyScript and trying to get this all working today.
12:51 But this is where this whole OS concept kind of ties in, right?
12:55 Where Wazzy's POSIX, right?
12:56 Just kind of abstractions that someone has to provide.
12:59 And then you have tools like Inscripten that try to kind of, specifically in the browser,
13:03 just go ahead and just lean hard in the browser specs that the W3C has given us and the browsers hopefully implement,
13:10 and just use those to implement those things that you would expect from an OS.
13:14 So it is, as you said, an interesting problem where from CPython's perspective and most Python implementations, right?
13:20 Historically, we've had a full operating system.
13:22 MicroPython's going to be the exception, which Nicholas, I'm sure we'll talk about.
13:25 But from a CPython perspective, PyPy, whatever, we're used to running on Windows, Linux, Mac, right?
13:32 Like full operating systems.
13:34 Like it jammed down into a tiny Raspberry Pi.
13:36 That doesn't happen anymore because you can't buy them.
13:38 They're unobtainable.
13:39 But yeah, but I mean, the key point is like a full OS, right?
13:44 Where we didn't have to concern ourselves about what was or was not available.
13:48 But in a WebAssembly case, right?
13:49 Like in the browser, if you use Inscripten, you only have available what Inscripten gives you.
13:53 In the Wazzy case, you only have what's been standardized by Wazzy and that the runtime you choose to use has actually implemented.
13:59 So we're in this interesting new kind of world where what you might expect from the standard library, for instance, in Python,
14:05 that's always been there, like threads aren't necessarily there.
14:09 So it actually goes back to an interesting perspective of what's Python the language versus the runtime of Python that you're using and what is provided by that.
14:17 We're kind of going back in time in a way of kind of this clear separation of language versus implementation.
14:23 And kind of what does that mean to us as a community and what's possible in this new space that is WebAssembly.
14:31 This portion of Talk Python to me is brought to you by the AWS Insiders podcast.
14:36 When was the last time you ordered a physical server to host your functions as a service, your latest API, or your most recent web app?
14:44 I remember the last time I did.
14:45 That was around the year 2001.
14:48 And yes, it was quite the odyssey.
14:50 Of course, we don't do that anymore.
14:52 We run our code in the cloud with near instant provisioning and unparalleled data centers.
14:57 And the most popular cloud provider is AWS.
15:01 But for all the ways that AWS has made our lives easier, it has also opened a massive box of choices.
15:08 Should you choose platform as a service?
15:10 Or maybe it's still VMs with IaaS.
15:12 What about your database?
15:13 Maybe you should choose a managed service like RDS with Postgres.
15:17 Or is DynamoDB better?
15:19 Maybe Aurora?
15:20 No, wait.
15:21 I hear good things about Amazon DocumentDB too.
15:23 And that's where the AWS Insider podcast comes in.
15:27 This podcast helps technology leaders stay ahead of Amazon's constant pace of change and innovation.
15:32 Some relevant recent episodes include Storage Wars Database Edition.
15:38 Macro Services or Macro Disaster.
15:40 And exploring computer vision at the edge with AWS Panorama.
15:44 They bring on guests to debate the options and the episodes are vibrant and fun.
15:49 So if you want to have fun and make sense of AWS, head on over to talkpython.fm/AWS Insiders.
15:56 Yes, I know you probably already have a podcast player and you can just search for it there.
16:01 But please use the link so that they know you came from us.
16:04 Thank you to the AWS Insider podcast for keeping this podcast going strong.
16:09 It's very exciting and very fresh.
16:15 Meaning that in a good and bad way, right?
16:18 It reminds me a little bit of what happened with Node.js, right?
16:22 People are like, look, we're writing all this advanced code and the browsers are getting really fast at running JavaScript.
16:27 Like, no, no, they're not.
16:29 Similar to Apple Silicon.
16:31 You're like, yeah, you can't take a phone and make that your fastest computer.
16:33 No, no.
16:34 And then somebody does.
16:35 You're like, wait a minute.
16:36 Look at this thing go.
16:37 Wow, you could have a server-side JavaScript, which I don't necessarily want to go touch.
16:41 But it's a similar transition that we could have Python in multiple places, right?
16:47 And it theoretically could run the WebAssembly version on the server as well for parity.
16:51 Or I don't know if that makes any sense.
16:53 But it's a similar transition in ways.
16:56 Maybe in the reverse direction than JavaScript.
16:59 Yeah, it actually has.
17:01 It's hard to predict as you are living through things, right?
17:04 But thinking about how Python became popular as most popular language without actually having a solid story for the most popular hardware today, which is tablets or mobile, like basically mobile phones and stuff.
17:21 And also not having a great story for the most popular virtualization software, which is the browser.
17:30 You know, imagining how Python will change with the WASM stories.
17:34 I find it very interesting because it basically introduces a series of concepts that we are not used to.
17:40 It's not just like run your environment there.
17:44 There's a whole packaging part of the process that we need to think about.
17:47 And how do we distribute that code?
17:49 And that opens up for things that we haven't been used to around optimizing space and building effective bundles of your environment where we can tree shake stuff and all of those funny things.
18:06 So I think for Python, it can be a very revolutionary moment where in five years from now, we're looking at a different ecosystem, hopefully bigger and better.
18:17 It did something on us to sort of adapt and change and make the most of the opportunities to the WASM presenters.
18:25 But as Brett and Fabio have said, it's a strange world in that it's not like I've got a libc and I know I'm going to be able to get to the file system and things like that.
18:35 There are these kind of shims and slightly different abstractions that may make Python feel like it's, I was going to say, a duck out of water.
18:45 Snake out of water?
18:46 I don't know.
18:46 You know what I mean?
18:47 It's not in its natural habitat.
18:48 Water moccasin.
18:49 But I think I'm pretty confident and bullish about the Python community and our ability collectively to find a way forward with this.
19:01 You know, we've got a beautiful language.
19:03 Let's bring it to WASM.
19:04 We do.
19:04 And many people love it.
19:07 And, you know, when people say, I love Python, they might mean the language.
19:11 But usually I think that's only a part of it.
19:13 Right.
19:13 Often that's the ecosystem and this whole broad.
19:16 Right.
19:16 All the packages and all the people on the projects.
19:18 And in that sense, like Python is very much empowered to make some really cool transitions there.
19:23 We don't have to always kick it back to the core devs for all the work.
19:26 Although, Brett, congratulations, I guess, on 3.11.
19:30 Right.
19:30 I mean, you guys, that's a big deal.
19:32 I only, I did a small amount, but I thank you.
19:36 It seems to have been taken very well.
19:38 The community seems to have picked it up faster than usual, which has been really fantastic.
19:43 Dependencies seem to have been ready for this and got wheels out early, which was great.
19:48 Because it made transitioning a lot easier.
19:49 So kudos and thanks to the community for putting in that effort to get stuff ready to go as of October.
19:54 So that when things launched and we were able to do that .0 release, people were able to just install it, download packages, and have the wheels ready to go.
20:02 And it went pretty smoothly.
20:03 Yeah, that's awesome.
20:04 Either of you, other guys, have any contributions to 3.11?
20:07 Yeah.
20:08 No, we are happy consumers.
20:10 Yes.
20:10 Exactly.
20:11 Exactly.
20:12 All right.
20:13 One other concept, which I really want to quickly throw out there and just get your thoughts on.
20:18 Don't want to go deep on this.
20:19 But one of the things that seems to me like an interesting benefit for WebAssembly is the interoperability with other languages.
20:27 Like WebAssembly can call WebAssembly.
20:28 So if somebody could compile their Rust or their C# or their, you name it, over to WebAssembly, you might be able to consume libraries in a broader way than you can now in Python.
20:40 What do you think about this?
20:41 Yes, or is this just Dreamit?
20:42 I think the answer is you could.
20:43 But I also refer the honoured gentleman to my esteemed colleague, Brett, to the earlier answer about this being relatively immature space as well.
20:51 I mean, to be honest with you, I used to be a .NET developer before I came to Python.
20:55 And the fact that .NET has this notion of the CLR, the common language runtime, to which C#, C++, Visual Basic, F Sharp, I and Python, I don't know, whatever compiles to.
21:06 It feels like it's a very similar space as you're implying, Michael, as to what.
21:11 Yeah, though the Blazor actually is like incredibly near with what they're doing, which is I haven't done anything with it, but it looks quite impressive.
21:20 There's a piece of tech we can quickly touch here.
21:22 Is there something, and I think it's actually on the page you're looking at right now if you're watching the live stream, it's right below the fold.
21:28 The important note, Wazzy is in transition.
21:30 The transition part is there is work towards something called the component model, specifically in Wazzy, which is defined more or less what you're talking about, Michael, which honestly feels like Korba for the new millennia.
21:43 To date myself, or at least date my PhD supervisor who did his PhD relating to Korba.
21:49 You said Korba, right?
21:50 I've not thought about that since like the year 2000.
21:52 But the thing here is the component model is a spec being worked on that's meant to be able for you to specify at the WebAssembly level kind of the API that your WebAssembly code exports, right?
22:05 I mean, for the Python audience, you can think of it as almost the CPython API, right?
22:09 It's kind of like what does CPython export out, and then what can you use from your extension modules?
22:14 It's a similar thing, except it's done at the WebAssembly level.
22:16 So you can just say like, okay, this function will return a string.
22:21 And then there's a definition of what a string is for WebAssembly.
22:24 So that when you say, oh, internally, I might use UTF-16, but a string in the WebAssembly component model context is UTF-8.
22:31 So you have to encode out to UTF-8.
22:33 And the other side, you go, oh, hey, I'm going to call this function.
22:35 Oh, it gives me a string.
22:36 I know that's going to come as UTF-8.
22:37 If you can keep using it that way, great.
22:39 If you have to change it to UTF-32 or something, you can.
22:41 But it's defining the seam of your WebAssembly module and what it looks like in terms of what it exposes to other people.
22:49 So that's that big dream you mentioned of people writing stuff in other languages that we can just consume directly from WebAssembly.
22:55 But there's obviously, as Nicholas pointed out, immature stuff in this community where we have to figure out how do we even expose that from the Python side, right?
23:04 Like, I don't even know technologically what we would do to make that work in terms of pulling another WebAssembly module.
23:10 Because honestly, it's basically like linking.
23:12 But we don't have that concept of linking in Python.
23:14 You just run an import statement.
23:16 There's no header, no definition of what's on the other side.
23:18 Exactly, right?
23:19 And that's exactly what the component model does, right?
23:21 It's an interesting position.
23:23 Actually, credit to Peter Wang, who you can save the love slash hate toots to later on this analogy.
23:29 But up to this point, right, a lot of the WebAssembly world has been these languages that are compiled, right?
23:34 Like the C and C++ and the Rust stuff, like where you just pull in all your code, you compile it, and it all just kind of works.
23:39 And it's very much set up in these worlds where, oh, yeah, it's statically compiled, whatever.
23:44 As you said, header files, it kind of comes together.
23:45 But we come from this world where people have poured all this time and energy to wrap all of this esoteric C, C++, Fortran even code, and give us this nice API in Python.
23:58 But once again, Python doesn't operate like C and C++ and Rust and all these other statically compiled languages where we have these concept of these interfaces, and they just load it, plug it right in.
24:07 And it just works like, no, we're going to import some Python code, and it's going to execute as part of import, right?
24:13 Like, I don't know how many people know that, but literally the way import works is it calls exec on your code, right?
24:19 Extension modules use some really crazy chips from glibc to pull in that data off that module, which we don't have in WebAssembly and stuff.
24:27 So there's a potential disconnect here at the moment.
24:30 And hopefully, as Fabio said, in five years' time, we can kind of work together to kind of work with the WebAssembly community to make this solve the problem.
24:37 But as of right now, that component model is not designed for us, the Python community.
24:42 It's designed more for the C, C++, Rust world.
24:44 And we're probably going to have to work with them to try to figure out how to make that work with us.
24:48 Because to be frank, we're bleeding edge in terms of a dynamic programming language with an interpreter as we are coming into this and not being a compiled language.
24:56 And I think we're going to be, I don't want to say bringing the WebAssembly world kicking and screaming.
25:00 I think they're just, we haven't fully introduced ourselves yet.
25:03 And I think they're going to come to get to know us, and we're going to start bringing in some new stuff.
25:07 So I don't think we're quite ready for this whole magic bringing in other WebAssembly stuff.
25:11 But hopefully, we can work with them to make that happen.
25:13 Because as of right now, it's not in the cards.
25:15 Yeah.
25:16 I'd like to make a comment on this one.
25:18 Because it actually is a topic of, we have the running joke inside the PyScript team where Antonio Cooney and I always argue about everything.
25:29 Or argue, discuss.
25:31 And this is a big topic of discussion.
25:34 Because Antonio is more lower level.
25:37 And very smart.
25:38 And I look at things more on the higher level side.
25:41 And I often tell, I really want to see Python working alongside with R or other languages for data science.
25:50 Or just, I would love my kids to be using Python to drive a gaming library in JavaScript on the browser or something like this.
25:57 And it's like, it's never going to work the way you want to.
26:00 Because you don't know how types are going to be translated into WASM for different languages.
26:06 And yada, yada, yada, yada.
26:08 But one bridge that we have right now is JavaScript.
26:12 And having proxy objects in JavaScript that relates to Python on the browser or Rust or things can be a possibility, too.
26:21 But in general, I think what I always end up saying to Antonio is like, we're kind of in creative mode right now or experimentation mode where we can try stuff.
26:34 And maybe it's not the right way.
26:35 And maybe it's not the right way, but it may work 90% of the time, which gets a lot of work done for a lot of people.
26:42 So in the meantime, we'll figure out the correct way and how different languages will actually talk to each other or what it means for WASM.
26:51 Anyway, I think it's interesting.
26:53 This is such an interesting conversation on so many levels because, you know, Brett mentioned Corbett, which is like this thing from way back when, before I was ever a software engineer.
27:03 Okay.
27:04 And Fabio is talking about how, you know, he has a high level view.
27:08 Antonio, you know, from PyPy has a very different perspective on this.
27:12 And I would say that, and also Fabio's pragmatism as well about what we need to get something to work because then we can do cool stuff with Python in the browser.
27:23 And basically what I'm saying is that you need both of those attitudes, the Antonio and the Fabio and bring them together because that's when interesting things happen.
27:30 And I'm not saying it's interesting watching these two have an interesting discussion in our morning standups or whatever.
27:35 But what I'm talking about is that that's the intellectually stimulating thing because you have two different perspectives.
27:41 And if like Fabio and Antonio are, they're excellent engineers and they can see and empathize with what the other person is talking about and adjust their position.
27:50 And then eventually we kind of zone in on various potential solutions, which kind of goes back to the Corbett thing, which is why I brought it up, is that, you know,
27:59 I remember meeting an old gray beard programmer when I was a young whippersnapper and he was, I can't remember, something had been announced and I was like, oh, this is amazing.
28:08 It's going to change the world in that way.
28:10 Young programmers.
28:10 And he was like, oh yeah, we were doing this in the seventies with punch cards or something like that.
28:15 And so once again, that sort of, we have this cyclical nature in the history of programming where, you know, we're, we're coming back to these kinds of archetypal solutions implemented in different ways.
28:27 And you can actually see perhaps that the whole was and wassy thing as yet another iteration of this, because we're rethinking what a computing platform is.
28:36 It's this virtualized thing and it's taken us maybe 20 or 30 years to get to that new space after lots of different experiments.
28:43 Right.
28:43 We're still going to be flapping around like headless chickens, trying to figure out how to make the damn thing work because all of this stuff keeps moving on.
28:50 And that's called progress folks.
28:52 But you know, this is why it's so interesting.
28:54 This is why I'm a software engineer is because I get to work with clever people on interesting problems that if we get it right, a bunch of 11 year olds in the school down the road from me are going to be able to build Python applications on a little device like this using PyScript.
29:13 And you know, that is something to work for.
29:16 Yeah, that's fantastic.
29:17 And if you don't like the tools.
29:19 And just for the podcast, a little device was the phone.
29:22 Yes.
29:22 Sorry, Fred.
29:23 By the way, we're not we're not paying Nicholas for every pitch on PyScript.
29:30 It's out of his heart.
29:32 He does an amazing job.
29:34 Let's talk about a little bit about MicroPython.
29:38 You know, MicroPython is amazing.
29:40 I recently sitting around my desk stuck Velcro to one of the hosts of my desk is one of these ESP feather 32s.
29:50 32 feathers.
29:51 I don't know how other.
29:52 Yes.
29:53 Those words.
29:54 Thank you.
29:56 device running Python connected to my Wi-Fi, syncing a bunch of stuff on the cloud and just had a little thing.
30:01 It blinks every now and then to tell me everything's cool.
30:03 It's it's doing its job.
30:05 And it just these are amazing.
30:06 And yeah, I mean, I know circuit Python is not identical to MicroPython, but they're very near and they've been brought closer together as well, which is great.
30:14 So if we download the entire CPython runtime over WebAssembly, it's not totally small, right?
30:20 It's about 11 megs.
30:22 Yeah.
30:22 Which we have fast computers.
30:24 But on the other hand, you wouldn't put it on like a public site that's there to load quick and be fast for SEO and all these things.
30:31 Right.
30:32 This portion of Talk Python to Me is brought to you by the Local Maximum Podcast.
30:39 It's an interesting and technical podcast that dives into trends in technology, stats and more.
30:44 But rather than tell you about it, let's hear from Max and Aaron about their show.
30:48 We are now on with Talk Python to Me.
30:52 Let's say hi to all the Python fans.
30:53 Hi, Python fans.
30:54 I'm Max Sklar.
30:56 I have actually done a lot with Python myself, so I am a fan of Talk Python.
31:00 Do you know Python, Aaron?
31:02 I took a course years ago, but I am a little rusty.
31:04 We are here today to talk about our podcast, The Local Maximum.
31:09 We've been on a roll lately with a new episode every week, and I wanted to share with you what we've been up to.
31:14 Here on The Local Maximum, we tackle subjects in software and technology,
31:18 topics as diverse as the philosophy of probability to Elon Musk's next move.
31:24 For Talk Python listeners, I want to highlight a couple of recent episodes of The Local Maximum.
31:28 In 248, for example, I found out about an open source library that maps the world into hexagons.
31:35 And some pentagons.
31:36 I had a discussion with an author about games and puzzles and another on a novel approach to doing the job search well.
31:41 We discussed the ramifications of AI-generated art.
31:44 Have we reached peak creativity, or is this just another Local Maximum?
31:49 So check out The Local Maximum podcast available on your podcast app.
31:55 But you do have this project called MicroPython.
31:57 Maybe tell us a bit about that.
31:58 That's smaller, right?
31:59 Okay.
31:59 So MicroPython is the wonderful creation of Damian George.
32:05 Damian is a physicist by training.
32:09 He once told me what his PhD thesis title was, and it's something like 11-dimensional.
32:14 And then he lost me.
32:15 But he was at Cambridge, and one of his hobbies or part of his background in his studies was working with robotics.
32:24 And he was part of the Australia team that entered the Robo World Cup for Americans.
32:30 That's soccer, as it were.
32:32 Which is rather appropriate, given the fact that the World Cup for Human Beings is happening right now.
32:38 But what he wants to do is write a scripting language so that they could very quickly update what was going on in these robots.
32:44 Okay.
32:44 And he learned a lot by doing that and then realized, well, actually, perhaps if I take the things that I've learned building this stuff to a proper scripting language, then that'd be a cool project.
32:58 And so he looked around thinking, well, what are cool scripting languages?
33:02 And arrived at Python.
33:03 Created an early version of MicroPython, put it on Kickstarter, thinking that he could sell a few boards, make a little bit of money, and, you know, MicroPython would be there.
33:14 Well, I think $100,000 plus later, and, you know, lots and lots of forders for boards later, MicroPython was, you know, has become this amazing success.
33:25 And the whole point of my...
33:26 Oh, no, I caught the car moment, right?
33:28 The dog that caught the car, like, here we go.
33:31 Yeah.
33:31 Yeah.
33:31 Well, it rather surprised Damien, to say the least.
33:35 But now MicroPython is designed to run in highly constrained environments.
33:40 So, for instance, I believe it can work with only 16K of RAM, for instance.
33:47 Clearly, when you're running it on your board, actual Python is running on the flash memory rather than the RAM, which is something different.
33:55 And Damien pulls an awful lot of tricks to actually make it work really efficiently.
33:59 But because he's a physicist, he knows how to do experiments.
34:03 And so that's what he does, literally.
34:05 He tries to work out, how can I get this big fat snake that's just eaten an elephant and squash it down into this small space so that we can still have a full re-implementation of Python 3 on something that maybe has 16K of RAM, like, I don't know, a microbit.
34:24 Unsurprising, I have a box of microbits on my.
34:26 Oh, yeah.
34:26 Beautiful.
34:27 And CircuitPython is a friendly fork of MicroPython by the wonderful folk at Adafruit.
34:32 So, you know, it's, I think it creates an interesting dynamic because MicroPython is perhaps the industry version, whereas CircuitPython provides a consistent API for all the Adafruit boards.
34:44 It's aimed at education.
34:46 They've got a whole bunch of sort of tutorials and support for that sort of stuff.
34:50 And they're forever bringing out incredible new devices, as I'm sure we've all picked up at PyCon, you know, the Circuit Playground Express.
34:56 Yeah, exactly.
34:57 Great conference band.
34:58 So that's MicroPython in a nutshell.
35:00 So what's it doing on Wazen?
35:02 Well, it's because 16 megabytes is rather a lot to try and download even today over a 4G network.
35:09 And these devices, subtitles here, this is a phone I'm holding up, are underpowered compared to the rather beefy MacBook sort of using to talk to you now.
35:18 And so the, one of the first things I did when I joined Anaconda was just see, well, what happened if you run it on a mobile phone?
35:26 And it took 16 seconds to get to Hello World, which is not an optimal kind of solution.
35:32 So what would work?
35:34 And very quickly, you know, I came to playing around with MicroPython and MicroPython is, you know, under 100 milliseconds to start up and get you to Hello World.
35:45 It's fast enough.
35:45 And you've got, so here's the interesting thing.
35:47 I'm interested to hear what Brett says here.
35:50 It's a full re-implementation of Python 3.
35:52 However, there are differences.
35:54 And so we get to Brett's rather interesting angle of, well, what is Python in the abstract and in the actual detail of implementation?
36:01 And we've kind of got this platonic Python, this ideal Python that doesn't actually exist.
36:06 And then you have all of these implementations of which, of course, the C, the CPython version is the, is the touchstone.
36:12 But MicroPython doesn't have all the APIs.
36:15 It doesn't have the full standard library.
36:17 And depending on the size of the device, it might not even support floating point numbers, for instance.
36:22 But it's Python.
36:23 It's the Python that we love.
36:25 You've still got indentation in the white space that annoys the C developers or whatever, you know, so it's good enough for me.
36:31 So we can compile this much, much, much smaller, more lightweight version to WebAssembly and do similar things.
36:39 But instead of downloading a whole huge thing, maybe it's a light little thing that still lets us write Python and do front end stuff in interesting ways.
36:47 Yeah.
36:48 All right.
36:48 When I talked about speaking back in 2019, I guess it was in Cleveland, we did touch on, well, if you're not going to be able to do all the Python things, how do you define like a standard Python?
37:00 There's, you know, and way back in Greek philosophy and the platonic Python, if you will.
37:06 Platonic idealist language.
37:08 The essence.
37:08 Yeah.
37:09 I mean, you're a philosopher, you know.
37:10 Oh, yeah.
37:11 The essence, like the core that, like, this is the little bit we circle and say, oh, Python does this.
37:17 Like, what is your thought on this micro invasion of Python in the front end?
37:21 Well, I have to be very clear on my bias here.
37:24 I'm somewhat notorious as having written the PEP that causes all accelerator modules written in C for CPython to have to have a Python equivalent specifically so that projects like MicroPython and PyPy weren't left behind from the standard library so that they could just work and not have to re-implement the C API for key things like the date time module.
37:44 So I have a massive bias in this statement, to be very clear.
37:47 So I am not representing necessarily the entire Python core development team or the steering council on this.
37:53 But for me, it has always been a separate concept of what the language is and what the reference implementation is, right?
37:59 Like, we may do development of the language using the CPython reference implementation.
38:05 And I am very specifically using the term reference implementation as a way to help make the language evolve.
38:12 But for me personally, they are two separate concepts.
38:15 These happen to be developed simultaneously and by the same group.
38:18 And it's mainly for convenience and just be able to work faster.
38:22 But I do view them as separate things.
38:25 And it does make sense, right?
38:26 Like, there are people on the Python core team who are way more into the esoteric bits of the language spec and how the language functions.
38:34 And some people just care about the eval loop that makes CPython run, right?
38:39 The big switch statement you mentioned earlier, Michael.
38:41 So for me, this is totally great.
38:43 Like, we have versions of the language specified in the language spec, which, to be fair, is not a spec from a, like, ECMA or ISO level standard.
38:55 But hopefully good enough for people to be able to follow to implement the language.
38:59 And to me, that is really what people are targeting.
39:02 I honestly, once again, major bias showing here.
39:05 I don't consider the Styron library part of the language.
39:07 The Styron library is a very key piece of functionality and a key convenience and potential differentiator for Python in some people's eyes.
39:17 But I do not consider it part of the language.
39:19 It is just something that we have developed over the years that has helped accelerate Python's growth.
39:25 Because back in the day, batteries had to be included because, guess what?
39:30 We didn't have PyPI.
39:31 Like, Vaults of Parnassus had little animated GIFs of a website where you downloaded zip files and you unzipped your stuff.
39:37 Everyone vendored everything because there was no installer.
39:40 There was no pip, right?
39:42 Like, showing my age in the Python community, right?
39:44 Like, we had to do the batteries included thing.
39:46 Did you un-UU encode it off of Usenet to get your package?
39:52 No, no.
39:53 I was not that far back into programming that, I mean, I used Usenet, don't get me wrong, but I was not coding at the time when Usenet was the way to Netfeed.
40:02 But, I mean, it was kind of just like, it's wherever it ends up.
40:05 You grab it and you put it in your project and you run with it, right?
40:07 There wasn't a central location for these things.
40:10 And so, to me, there's a very clear separation here.
40:12 And I personally view the Styron library as a thing that represents the time of when it was created.
40:18 But, to me, it has never been the language.
40:21 The language is what's in the language guide and more or less what's built in.
40:25 And that's kind of it.
40:28 The import statement brings all this wonderful stuff in for you, but that's not the import statement's part of the language.
40:33 But what you can import into it, unless it's like Dunder future, right, which is baked into the language definition, I don't consider that part of the language.
40:41 And I've said this controversially once on the former website that we all used to hang out on before Mastodon, where I actually said, like, the REPL, for instance, is not part of the language either, technically.
40:51 If you think about it, it's a wonderful tool.
40:54 And don't get me wrong, it definitely makes Python more useful.
40:56 But for me, personally, the REPL is not part of the language either.
40:59 It's just something we all ship because it's so useful to use and Python enables that kind of development process.
41:06 But so MicroPython saying it targets Python, I believe, technically 3.4 with extras means it is an implementation of Python for Python 3.4.
41:16 And that's great.
41:17 And whether it comes with everything that the standard library that CPython had for 3.4 is a positive, is a plus what it has.
41:23 But to me, that's not the language.
41:25 And to me, they're very clearly separate concepts.
41:27 It's just people get very spoiled when they just download CPython.
41:31 Well, my code doesn't work over here.
41:32 It's like, well, you can view CPython almost as a platform.
41:35 And this platform just doesn't have the same platform.
41:37 The same language, just different platform.
41:39 And to me, that's fine.
41:41 That just is what it is.
41:42 So it sounds like you're okay with the micro invasion.
41:44 Oh, yeah.
41:45 I care about the language, right?
41:46 If CPython is the way you get it, fantastic.
41:49 If you get some other way, that's also fantastic.
41:51 I personally care about the language.
41:52 And I mean, we all know the community that comes with the language more than the implementation.
41:57 And the fashion.
41:58 Don't forget the fashion.
41:59 And the fashion, yes.
42:00 No, go ahead.
42:01 I was going to say, before we pressed record, that was a running joke.
42:04 But bring us back to the serious conversation, Nicholas.
42:06 Brett Sandals.
42:07 So the more serious point I was going to make is that what Brett just said is actually easy to miss, but of vital importance.
42:16 Which is if you're coding with, say, for example, MicroPython, you can't expect your code to work with CPython and vice versa because of the differences in the platform, the wider platform ecosystem that you might have.
42:28 Mostly the behavior is the same, although there are some very subtle differences.
42:33 Yeah.
42:33 It's mostly the experiments I've been doing where I've been using Pyodide as the sort of the reference and MicroPython as the sort of the thing to compare.
42:43 I can just slot one in and slot the other out and PyScript sits on top of it.
42:48 And I can make things work as I want to.
42:51 When I'm testing Python things, there's a whole conversation, which I think I can see coming down the tube right now about how do you interact with the DOM and things like that.
42:59 We'll get to that when we get to it.
43:01 But it's mostly the same.
43:02 But folks should know that they are different.
43:05 And well, there you go.
43:07 I'm just flagging that.
43:08 I need to flag that.
43:09 Yeah, absolutely.
43:10 All right.
43:11 Quick question from the audience here.
43:12 Glenn says, do you think more stuff needs to be removed from CPython?
43:16 I mean, I know actually that was one of the things that the 3.11 release addressed was a bunch of modules were either removed or deprecated.
43:24 I think, Brett, we spoke about that a year ago or something, maybe, if I remember.
43:28 Yeah.
43:29 Christian and I came on maybe, yeah, almost a year ago.
43:33 Not to the day, but maybe to the month or October last year.
43:36 We came on here and talked about us removing modules from the standard library.
43:40 Yeah.
43:41 To directly talk about this, once again, personally, not speaking on behalf of any other group.
43:46 I think we, I've actually put myself back up for the Python steering council.
43:52 And one of the things I put in my self-nomination is I want to have a discussion about what the standard library is, which evolves around how do we want to evolve it, maintain it?
44:02 What would go in there today if we were to have guidelines?
44:04 Because we actually don't have guidelines on what should go in.
44:07 Historically, it's just been a core dev has gone, I want this in.
44:09 And people just kind of, in general consensus, go, okay.
44:12 Or honestly, I'm going to add this.
44:14 And they sometimes have added it because five or some odd core devs all agreed to it and just kind of goes in.
44:19 And they just didn't think to have a wider discussion.
44:21 Like, not going to go down details on that one.
44:23 Anyway, point is, it's not had any guidance to it.
44:27 And it's a discussion I want to have.
44:30 And I don't know if it's going to lead to a shrinkage of the standard library just because, once again, from a CPython perspective, there's compatibility to consider.
44:37 Right?
44:38 And we don't want to just rip stuff out.
44:39 But it is possible we might start deprecating more stuff, right, beyond what the dev batteries were.
44:44 Because the dev battery list was very conservative.
44:46 Basically, if almost anyone brought up any objection to something, we left it, whether we thought it was reasonable or not.
44:52 So I can very much see a future where we maybe have a list of like, yeah, this stuff's here, but don't really rely on it.
44:59 And obviously, MicroPython probably doesn't already ship that stuff now anyway.
45:02 But yeah, personally, I would love to see the standard library a bit smaller, if for any other reason that it just makes it easier to maintain.
45:09 Because there used to be, before the dev battery PEP, more modules than there are countries in the world.
45:14 So like, I think, 198.
45:15 So there's a lot of stuff in there.
45:18 And we can probably stand to shrink it.
45:19 And once again, it kind of makes it a little easier for other projects to not get pushback from people.
45:24 And like, well, where is this module?
45:26 It's in CPython.
45:27 It's like, well, we don't have it.
45:29 Well, why not?
45:30 It's like, if it's not there to begin with, it makes their lives a little easier to not have to try to support it and push back to people.
45:35 It's like, it just doesn't make sense for us as a platform.
45:38 Right.
45:39 And as we talked about before, some of these things being included came from a different time, for sure.
45:43 All right.
45:44 Well, I remember when I got one gopher lib.
45:47 So it's also worth noting.
45:49 But Archie, we're going to keep, we're sticking with Archie.
45:51 Sorry, go ahead.
45:52 No, no.
45:52 I was saying, those batteries have a cost.
45:55 And every time you have to run limited devices like MicroPython or the browser, like you realize that.
46:02 And then the question becomes, well, is that user base significant to the Python project to make a change on those?
46:10 Right.
46:10 Like, and that comes with conversation and evolution.
46:13 So I think probably.
46:15 It's always a trade-off.
46:16 You say, let's remove TKinter because it's a GUI from the mid-90s and nobody uses it.
46:22 And then everybody points out that the Turtle module mostly uses TKinter and teachers all over the world will scream, you know, and you've got a big problem.
46:33 So it's a Gordonian knot.
46:37 Sure is.
46:38 All right, let's bring in the third major project here, which we've touched on a few times.
46:43 But Fabio, tell us about PyScript.
46:45 What a cool project.
46:46 Cool.
46:46 Thank you.
46:47 Yes.
46:47 Where does it fit in this Pyodine, WebAssembly, MicroPython world?
46:52 What's the angle here?
46:54 I think it fits as a glue.
46:57 Well, pretty much like Python was glue for a lot of things.
47:00 Like the concept of PyScript was really, you know, realizing that a lot of, most of the technology for Python to run the browser is there.
47:08 And it's been there for years now.
47:10 And what we're missing is the easiness to just use it without being, you know, without having to spend hours or days looking for how to import things or, you know, the JavaScript side of it, what it means on the browser, as a web dev to start using Python.
47:29 So the idea was really like, like, can we call it?
47:32 Because it's one thing to have WebAssembly.
47:35 Sorry, it's one thing to have WebAssembly see Python.
47:38 It's another to build meaningful things in the browser with that as a piece.
47:42 Right.
47:42 And so PyScript kind of gives you a framework to write Python code in the browser based on this WebAssembly.
47:48 Right.
47:49 Correct.
47:49 It's not a framework.
47:50 It's a platform.
47:51 And we fully expect people to write Pythonic frameworks on the platform that is PyScript to do whatever funky stuff they want to do in the browser, their business.
48:02 And, you know, I know that I trust the Python community will come up with something that we can't even begin to imagine now.
48:09 But the thing to do is remember that PyScript is that sort of platform layer rather than a framework.
48:16 But in that platform, what we're looking at is perhaps pluggable runtimes and a bare minimum of APIs and heuristics and ways of working such that you can start to build your frameworks on top of this and make the funky stuff.
48:29 Michael, like you said, that's useful for folks.
48:32 Well, OK.
48:32 Well, so we might have Pyodide, which is a more full featured version.
48:37 Might we have MicroPython for a fast, speedy version?
48:40 Yeah.
48:41 And there are other projects as well that are coming up and or other languages, too.
48:48 Right.
48:48 So that's definitely in the.
48:51 But that'd be interesting.
48:52 Exactly.
48:53 There was a big announcement that got thrown in here.
48:55 We'll go this way.
48:56 We'll go with Simon Wilson, who was on the previous show about Mastodon, previous episode.
49:01 And he has a toot, which, by the way, I don't know, Brett, you said toot as well earlier, but they just the button on there used to say toot until like last week.
49:10 They just call it publish now.
49:11 I think they're downplaying the toot, but it's going to live on.
49:13 The toot said huge Python WebAssembly news tucked away in this post from Anaconda here.
49:18 When you apply MicroPython to WASM in its default configuration, something new and exciting emerges.
49:23 With a total size of 300 kilobytes, this new runtime builds instantly and starts executing MicroPython logic in less than 100 milliseconds.
49:32 That means the cost of running MicroPython on the web is now equivalent to serving up a large hero image.
49:38 This is awesome, you guys.
49:39 Where are we going with this?
49:40 Whenever you meet Damien, you buy him a beer is pretty much what I would suggest.
49:44 Although not too many.
49:46 Once in sober.
49:51 Yeah, this is fantastic.
49:52 Because if we do have a really small runtime, then all of a sudden you could.
49:56 So when people saw PyScribe and Fabio, they're like, oh my gosh, could we replace JavaScript with Python?
50:01 And the answer was sometimes, but not in general, right?
50:05 Yeah.
50:05 Yeah.
50:06 Not practically.
50:06 This is Paul Everett, who's been around the Python ecosystem for a lifetime and is really great.
50:13 And we were talking about that and Python for web during PyCon.
50:18 And he often comes up with this distinction between the app web versus the content web, where in terms of content web, you need things to load immediately.
50:29 And you're mostly wanting to show content rather than a full-blown application.
50:34 And I think he still thinks Python is not going to be a reality for the content web.
50:40 I think this brings it really, really, really close.
50:44 And you can have basically Python running for content, but also the amount of possibilities around education, around exploration in real time and stuff like this is tremendous.
50:56 And if we can actually, as a community, gather and understand how we want to build layers on top of other things, I think we can come up with really interesting solutions.
51:07 And let me explain.
51:09 MicroPython, for instance, doesn't have a JavaScript interface, right?
51:15 So if we could have a module, maybe it's the Pyodide one that we strip out or we develop a new one where we can explore that Python to JavaScript interface and make it available for all the interpreters.
51:29 And it's just like a package and you can install it.
51:32 We open up a new channel or the whole packaging story for Python on the browser.
51:39 And if we can figure that out in a way that, you know, we can just install packages and doesn't matter the interpreter because it all end up like being WASM, then I think we can build a very strong ecosystem where if you need more complicated things, you run with your full CPython and WASM interpreter.
51:58 Otherwise, you can just use MicroPython.
52:01 But I think right now is the time where we start doing those things.
52:06 Coming from the Anaconda world, there's one view of like, what does Python computation mean, right?
52:12 Often that means kind of notebooks and data science and like scientific computing.
52:17 And there's a big desire to sort of move that to the front end and just say, let people run that on their computers and they can do kind of like notebook things on the front end.
52:27 But there's a whole other side of the web that says, I want to build Gmail, but not in JavaScript on the front end.
52:34 But I want that interactivity or I want maps or I want, you know, most modern highlight dynamic single page app type of web apps.
52:43 But I want to write that in Python.
52:45 That to me feels like that's almost the dividing point of like, well, we want the Pyodide runtime where it's rich and we can just straight grab Matplotlib and run with it or Pandas versus I'm willing to give up a lot to not write JavaScript.
53:00 You know what I mean?
53:01 If I've got to only use a few packages and I could still write Python end to end, that makes me super happy.
53:06 As you said, like we can augment the things that Python can do.
53:10 Like if we all of a sudden have access to the browser APIs for geolocation or other things, then you can write very interesting applications that is just Python or, you know, even a mobile and stuff like this because WebAssembly can run on mobile as well.
53:25 So, yeah, the competition between all the arguments framing PyScript versus JavaScript, I think they really missed the point where it is augmenting both ecosystems.
53:37 Like right now, we now can use D3 in Python and vice versa.
53:42 JavaScript developers can use NumPy or Pandas.
53:45 It's a win-win, to be honest.
53:46 Yeah.
53:47 One of the things I think maybe people when they hear this don't necessarily know, and I forget which is maybe the best one to look at.
53:54 But not only can you run Python code in the browser with PyScript, but you can hook JavaScript events and then you can change DOM elements.
54:01 This was the JavaScript DOM interaction layer you were talking about before, right?
54:05 Yeah.
54:05 Yes.
54:06 And actually to what Nicholas was saying about the difference between that we want to really sell the point that PyScript is a platform.
54:16 We're currently working on plugins where we want developers to actually write Python code to add custom elements to the DOM as well, right?
54:26 And not use any JavaScript.
54:27 I hope we can get it in this next release, but for sure before the end of the year, we are allowing that.
54:34 And it's going to be a huge improvement in how what people can do with PyScript and actually how can people extend the platform creating new frameworks.
54:43 So are you envisioning or are you at least aiming for, if not fully envisioning, something like PyView or PyReact or like some of these traditional front end frameworks, but a Python equivalent?
54:56 Nicholas?
54:57 That's a loaded question.
54:58 I think.
54:59 A Pyangular?
55:00 No, just kidding.
55:01 Pangular.
55:02 I think that it makes a great story if you're a journalist that Python's going to come up and eat JavaScript's lunch in the browser.
55:12 That's a false dichotomy.
55:13 That's a great way of getting clickbait and things.
55:17 If you want to write, you know, app, web-based app stuff, and you're familiar with JavaScript and React, you know, just use the tools that empower you to write the stuff that you want.
55:30 But for the quartet of us in this conversation, we're all Pythonistas.
55:34 We all appreciate the aesthetic of that language and the way it works.
55:40 And so I would go back to the difference between a platform and a framework point from earlier on, which is it's going to be fun to trust the community, our remarkable community, and see what interesting things, what itches that they scratch.
55:55 So that they create fun stuff and feedback to us, ways in which we can improve the PyScript offering, because this is a story that's going to keep going.
56:03 You know, software is never finished.
56:06 But I think that one thing I hope, and if I'm honest with you, this is really why I joined Anaconda, was to help think about these things.
56:16 Exactly the question that you've just asked, Michael, you know, what about all of these kind of things of building apps with Python in the browser?
56:22 Well, what I found is that I need to dig a bit lower to do some more cool PyScript-y things, and then dig a bit lower to look at perhaps what the runtimes are doing and blah, blah.
56:30 And here I am messing around with, with MicroPython now, but hopefully I want to sort of surface, as it were, and get back to what I thought I was going to be doing, which is thinking about these sorts of things.
56:41 And what I really hope to do, or what I really hope to see from the Python community as well, is engagement in frameworks that will empower people.
56:50 And I'm thinking of the educational sphere as well here, because let's face it, I don't know if you've ever faced 30 teenagers on a Friday afternoon and somebody's introduced you as Nicholas, a coder who's going to teach you about Python.
57:03 There's nothing more intimidating than that.
57:05 And let me tell you, print hello world doesn't cut the mustard.
57:09 Okay.
57:09 This is not exciting for them.
57:11 But if we can make something.
57:14 I want to build this thing.
57:15 I saw an Unreal Engine 5 in Python.
57:17 Exactly.
57:18 Exactly.
57:19 Exactly.
57:19 But if we could make it so that they can do the equivalent of, you know, the MySpace.
57:25 Hi, hi, Nan.
57:26 I'm on the internet.
57:27 You know, within two minutes, you've got a website, you know, you've got a very quick way of getting onto a mobile phone or tablet, which let's face it, for today's teenagers, that's their primary computing device.
57:36 Yeah.
57:37 And I've been in classrooms where, you know, kids can't type.
57:39 It's not because they don't know what a keyboard is.
57:41 They use a keyboard every day, but they just use their thumbs like this with it.
57:44 And when you give them an actual mechanical keyboard.
57:45 We're really bad.
57:47 We are dinosaurs using these keyboards now, right?
57:50 Okay.
57:51 We're going to evolve massive thumbs or something, but it's that sort of a situation.
57:55 Okay.
57:56 We've got to be aware of what these platforms are that folks are using that may be outside of our kind of age group and usage and help them both do things with Python.
58:05 You're touching on a very important part of the PyScript vision.
58:08 And it's really not about the current Python community user base.
58:15 Like it actually is how can we democratize programming and Python and everything.
58:22 And so we really want to be thinking about who's not thinking about coding at all.
58:27 Like people that would love to use programming language as a tool for them to do things.
58:32 And they can't either because, you know, time or because it's too complicated to get Python working or all of that.
58:39 That's a pluggable.
58:41 And I'm going to quote Peter again, because we are talking and welcome back, Nicholas.
58:46 Peter at some point mentioned something like, you know, system design with plugins from the beginning is kind of indication of the developers not really knowing what they're doing or not really knowing what it should do, which, you know, sometimes is a negative connotation.
59:02 But for PyScript is definitely intentional because we want to we want the community to be able to create their own things.
59:09 And we don't it's really greenfield.
59:12 So I don't know what they're going to be doing.
59:14 I want to allow them to do crazy things and surprises.
59:17 You know, like two months last DjangoCon, Patrick came up with this experiment of running Django on either PyScript or Pyodide.
59:28 And I my first question was, why?
59:29 Right.
59:30 But then who cares?
59:32 Like it's the web is inside the web inside the web.
59:35 Exactly.
59:36 Like inception all the way down.
59:38 So that's the whole point.
59:41 I can we want to make it funny, accessible and a hacker, a hacker space, a safe hacker space.
59:46 Yeah, it's such awesome.
59:47 Congratulations to you guys on this.
59:49 When will we see something that we outside that don't want to grab onto an in-flight open source project,
59:56 but like a release equivalent of this?
59:59 Is there some some time frame, some thought about when that's out?
01:00:03 Because this is the right time to drop from the call.
01:00:06 OK, so I can tell I can certainly tell you what the state of play is right now.
01:00:13 And you can extrapolate when you may see sort of things like microprice.
01:00:17 Because PyScript, proper PyScript is undergoing active development.
01:00:22 I didn't want to try and plug in new runtimes, new interpreters, whilst the sand underneath me was shifting, as it were.
01:00:30 So I created a very small and simple test harness version of PyScript that I've called, surprisingly enough, micro PyScript.
01:00:37 That is going to be thrown away.
01:00:39 Its sole purpose was to allow me to just poke these things with a stick and see what happens.
01:00:44 And I'm still using that to, for instance, figure out how we can do MicroPython DOM connectivity and interactions as well.
01:00:51 That's literally what I've been doing all day today is reading articles I needed to do to make that happen.
01:00:58 So, yeah, that's going to unlock so much.
01:01:00 Once the DOM is in play, then all of a sudden it's on.
01:01:03 Yeah, everything else is.
01:01:04 Yes, exactly.
01:01:05 Exactly.
01:01:05 Once that's in place, what I imagine will happen is Nicholas is going to be spending a lot of time with the main code base and pairing with people who know it a lot better than I currently do, because it's been maybe a couple of months since I've last looked at it.
01:01:21 And it's changed a lot since then.
01:01:23 And we'll integrate that work.
01:01:25 So I expect, and this is a finger in the air, and remember, the right answer is when it's ready.
01:01:32 But I imagine it's going to be kind of springtime.
01:01:35 Springtime.
01:01:36 First, third of next.
01:01:38 Would you say maybe in April?
01:01:39 Like April 19th, 20, 21st?
01:01:42 I'm not going to mention any dates because you're just going to hold me to it, aren't you?
01:01:46 I'm not going to mention any dates.
01:01:48 I'm just teasing you.
01:01:49 I'm not holding you to that.
01:01:50 I hear that, you know, conference wear is very real.
01:01:55 So we can promise for PyCon.
01:01:56 No problem.
01:01:57 Yeah, I hear a good place to announce new JavaScript packages is Salt Lake City in April.
01:02:03 So Brett, I'm going to give you the final word here maybe to like put one more thought into this before we wrap up our show.
01:02:09 Nicholas talked about, and Fabio also talked about like how do we, you know, this could be an empowering thing for other people, right?
01:02:15 Like if for kids in education and whatnot, if you look at a lot of education is Chromebooks.
01:02:21 You know what runs great on Chromebooks?
01:02:23 The web.
01:02:23 Also VS Code in the browser.
01:02:26 Like there's, is there some thought of like interesting pure web development environments, runtime environments, like end-to-end things that could be done?
01:02:35 We actually announced that for VS Code in our last release.
01:02:38 If you go read our release notes, we actually have an extension that will load up into VS Code.dev, which is an actual website, not the name of a product.
01:02:45 You literally go to VS Code.dev.
01:02:47 It'll load up VS Code in the browser.
01:02:48 And there's a Python extension by my teammate Dirk that uses Wazzy and the CPython build where you have a REPL.
01:02:55 You can run code from your workspace wherever it's loaded, right?
01:03:00 It doesn't have to be on disk.
01:03:01 It can come from GitHub.
01:03:02 Anywhere VS Code can read files from.
01:03:04 It can load and be seen by Python interpreter itself.
01:03:08 So that's all working.
01:03:09 And just this past week, it's not out yet, to be very clear.
01:03:13 Dirk got debugging working using Wazzy and a very cool trick that everyone can see.
01:03:18 It's very Unix-y.
01:03:19 I don't want to spoil it.
01:03:21 It's going to be open source, so it's not a trade secret or anything.
01:03:23 But it's way easier to read about it than trying to explain it on a podcast.
01:03:26 But we got debugging working as well.
01:03:28 So we are trying to work towards a complete development story such that, once again, for beginners, for learners, for the education market,
01:03:38 to at least have a baseline Python experience where you can write code, read code, read files, debug.
01:03:46 Like, what you would want to have when you're facing down that classroom of 30 kids that Nicholas has shown is very scary to at least have something you can have them all just pull up.
01:03:55 I do want to add two other things to this, though, is actually kind of call to actions for the community around all this.
01:04:02 One is I don't think we've all started to think about the opportunities here beyond what we've talked about, right?
01:04:08 There's more to this than just what we have in the browser.
01:04:10 And it's one of these rising tides lifts all shifts.
01:04:13 So it's not that I want to take away from what Pryscript's done and all this wonderful stuff in the browser.
01:04:18 But I think if we can get more WebAssembly stuff kind of going, it helps cause everyone to try to look into this more, which will lead to more Pryscript engagement.
01:04:24 So I think there's some use cases we haven't really tackled yet in the community where if you just stop and look about where's things really oriented towards JavaScript as a platform and go like, oh, you know what?
01:04:35 We might build these Python here now.
01:04:37 For instance, you could probably, and I haven't had time to test this, but I see zero reason why this couldn't work.
01:04:42 You could probably start writing GitHub Actions in Python now.
01:04:45 Because guess what?
01:04:46 It runs on Node.
01:04:46 And Node can run WebAssembly.
01:04:48 So we could totally take either Nicholas's MicroPython build or we could take the CPython build and totally just have as part of a GitHub Action as the first step in the JavaScript, load Python.
01:04:59 And then suddenly just say, call this function.
01:05:01 And suddenly all your stuff's going through Python.
01:05:04 Because guess what?
01:05:05 At that point, GitHub Actions is all totally driven via standard out and some special formatting in it.
01:05:09 So you could totally just do that.
01:05:11 And I think Nicholas wants to interject with something.
01:05:13 Yeah.
01:05:13 It's worth pointing out that Damien, who has done a lot of work on getting MicroPython to work with WASN, clearly he knows the code base and things like that.
01:05:21 MicroPython, if you look very carefully at the WebAssembly port, you'll notice that there are conditionals that check whether it's running in Node or in a browser.
01:05:30 So go knock yourself out.
01:05:32 Try that.
01:05:32 I've not tried it.
01:05:33 I've clearly been busy doing other things.
01:05:35 But folks might want to have a go at using.
01:05:38 I mean, I feel like we should award a prize or something.
01:05:41 You win a thumbs up or something like that if you can get a GitHub Action running MicroPython.
01:05:46 Yeah.
01:05:46 I mean, that's fantastic, right?
01:05:48 Like, I think there's opportunities here we just haven't even touched yet that the community can totally just lean into that we haven't had opportunity to be able to do before.
01:05:55 The other thing I want to lean into here that we've talked about languages versus platforms and all this, the one key thing across all of this story is Python the language.
01:06:04 So this is going to sound a little weird, but I want to push people to write more Python code.
01:06:08 And the reason I phrase it this way is we've historically as a community done great about this, but we will reach for that Rust code or that C code or whatever to write that little bit a little faster.
01:06:18 But when you do that, well, right now, Fabio and Nicholas shed a tear because that makes it that much harder to make that run in PyScript, right?
01:06:25 And same for anyone else who wants to do this WebAssembly thing, right?
01:06:28 Anytime you write anything in something other than Python, it's harder to get running, right?
01:06:32 Somewhere else.
01:06:33 Now, you mentioned the 3.11 release, Michael.
01:06:36 My hope here is now that we've got that nice little performance boost there, that's going to motivate people who are primarily targeting CPython at the moment to write more code in Python and reach for the C code and the Rust code less.
01:06:48 Because, once again, that stuff can get brought over today.
01:06:51 There is nothing you have to do to make this work, right?
01:06:54 Like, you can load pure Python wheels in PyScript.
01:06:57 You can do that on WebAssembly, right?
01:06:59 It just runs.
01:07:00 So if we can kind of nudge the community back towards running more Python and leaning less on the accelerator code that we have historically written for these kind of platforms, or do both, right?
01:07:11 Like, if you can at least prototype in Python and keep that running, and then write the accelerator code behind the scenes, right?
01:07:16 Like, you can have multiple wheels, including a pure Python wheel, right?
01:07:19 Like, coverage.py, we all know, does this exact thing so that it works no matter where you are.
01:07:23 Same thing for this case, right?
01:07:26 Like, if you can get the pure Python wheel out there, then it's going to be usable everywhere.
01:07:29 And so that's kind of a baseline target I hope the community kind of leans into more than we have in the last few years, where, yeah, write your Python code even more than you may have before, because it's usable in more places.
01:07:43 That's really great advice.
01:07:44 And it's not done getting faster, right?
01:07:46 The faster CPython team is still making a bunch of steps.
01:07:49 So it's much faster now, but there's still, there's 3.11, 3.13, or 3.12, 3.13, the one that's going to be.
01:07:55 Yeah, exactly.
01:07:56 Like, it's going to keep going.
01:07:57 I don't know how much faster 3.12 may or may not be.
01:08:00 I think there's some plans for 3.12 that are really foundational.
01:08:04 So the bump might not be quite as big as 3.11, but 3.13, if the foundation lays in 3.12, we'll hopefully get the bump.
01:08:11 So, yeah, hopefully you'll keep getting those wins going forward, right?
01:08:15 And I know Damien's still working on MicroPython to make it faster and smaller and better and all that stuff.
01:08:20 So it's not just a CPython thing out of there.
01:08:21 Like, the whole, everyone's always trying to make Python run better on all these platforms.
01:08:25 So key thing, though, is the common bottom layer of all these platforms is actually Python itself.
01:08:31 So if we can target that more as a community, we'll actually be able to get more use out of the code and for what people have produced in more places.
01:08:38 And once again, help Nicholas when he faces down that class of 30.
01:08:41 Yes, you can.
01:08:44 You can create Call of Duty.
01:08:46 Okay.
01:08:46 Thank you, Brett.
01:08:47 That's great thoughts.
01:08:48 And it also points out I should pay more attention to those release notes when they come up in my VS Code.
01:08:52 I'm like, oh, new one, out of the way.
01:08:54 Maybe I'll read them.
01:08:54 All right.
01:08:56 You guys, thank you so much for all the work on this.
01:08:59 This is super exciting.
01:09:01 And yeah, I'm looking forward to hearing about it in spring or whenever it's ready.
01:09:06 Brett, Fabio, Nicholas, thanks for being here.
01:09:07 It's been great.
01:09:08 Thanks, Michael.
01:09:09 Thank you, Michael.
01:09:09 That was great.
01:09:10 Thank you, Michael.
01:09:13 This has been another episode of Talk Python to Me.
01:09:16 Thank you to our sponsors.
01:09:17 Be sure to check out what they're offering.
01:09:19 It really helps support the show.
01:09:20 AWS is the lead cloud for developers.
01:09:23 But with over 250 services, it's an overwhelming set of choices.
01:09:29 That's where the AWS Insiders podcast comes in.
01:09:32 Their job is to help you make sense of all those AWS options.
01:09:35 Listen to an episode at talkpython.fm/AWS Insiders.
01:09:40 Listen to the Local Maximum podcast.
01:09:42 Learn about topics as diverse as the philosophy of probability and Elon Musk's next move.
01:09:49 Just search for Local Maximum in your favorite podcast player.
01:09:52 Want to level up your Python?
01:09:54 We have one of the largest catalogs of Python video courses over at Talk Python.
01:09:59 Our content ranges from true beginners to deeply advanced topics like memory and async.
01:10:03 And best of all, there's not a subscription in sight.
01:10:06 Check it out for yourself at training.talkpython.fm.
01:10:09 Be sure to subscribe to the show.
01:10:11 Open your favorite podcast app and search for Python.
01:10:14 We should be right at the top.
01:10:15 You can also find the iTunes feed at /itunes, the Google Play feed at /play,
01:10:20 and the direct RSS feed at /rss on talkpython.fm.
01:10:24 We're live streaming most of our recordings these days.
01:10:28 If you want to be part of the show and have your comments featured on the air,
01:10:31 be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
01:10:35 This is your host, Michael Kennedy.
01:10:37 Thanks so much for listening.
01:10:39 I really appreciate it.
01:10:40 Now get out there and write some Python code.
01:10:42 Thank you.
01:10:43 Thank you.