#391: Pyscript powered by MicroPython Transcript

00:00 No.

00:00 Python announcement of 2022 was met with more fanfare than PY Script. This project announced at PyCon 2022, allows you.

00:07 To write Python files and run them.

00:09 In your browser in place of JavaScript or even with interactions between Python files and run them in your browser in place of JavaScript. There's just one catch. The runtime download was a nine megabyte WebAssembly file that made its use quite limited.

00:23 On this episode, we dive into some.

00:25 News that might change that calculus. The MicroPython and PyScript folks have been teaming up to get PyScript running in the browser on MicroPython. Yes, that's the embedded chip Python that.

00:37 You may have heard of.

00:38 And here's the good news. Micropython's WebAssembly is just 300 K to download and loads it under 100 milliseconds. Now that could unlock some real possibilities. We have Brett Cannon, Nicholas Tollervey, and Fabio Plager on the show to discuss. This is talk python me. Episode 391, recorded November 21, 2022.

01:12 Welcome.

01:12 To Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy. Follow me on Mastodon where I'm @mkennedy and follow the podcast using @talkpython, both on fosstodon.org. Be careful with impersonating accounts on other instances. There are many. Keep up with the show and listen to over seven years of past episodes at Talkpython FM. We've started streaming most of our episodes live on YouTube. Subscribe to our YouTube channel over at Talk Python/YouTube, to get notified about upcoming shows and be part of that episode. This episode is brought to you by 'The Local Maximum' podcast Over@localmaxradio.com and AWS Insiders podcast. AWS is changing fast. Listen in to keep up over at Talkpython.FM. AWS Insiders. Transcripts for this episode are sponsored by AssemblyAI, the API platform for State of the ART AI models that automatically transcribe and understand audio data at a large scale. To learn more, visit talk python FM Assemblyai.

02:16 Hey, guys. Welcome back to talk python me.

02:18 Thanks, Michael.

02:18 Hey.

02:19 Thank you, Michael.

02:19 Yeah. Fabio, Nicholas, Brett, it's really good to have you all here, and I know you are all very excited about this topic. Brett, I believe the last precovid Python, we did a live on the Expo floor show about WebAssembly. We did, yeah. Fabio, we recently talked about Pi Script, and Nicholas, you're right in there as well, working on WebAssembly highlight Python as well. So I know a lot of people know all of you, but maybe let's just kick it off with a quick round of introductions and background. Not too deep since all done before. Brad, let's go to you first.

02:53 Okay, keep it short. I am the dev manager in charge of the Python experience of VS Code, been a core developer for 19 years, been on the Python Steering Council since Guido's retirement. And I'll stop there.

03:05 Yeah, Fabio.

03:07 So I'm creating PyScript currently maintainer with Nicholas. I've been working with Anaconda for eight years now. Right now I'm tech lead for PyScript and been doing a lot of community stuff around Python for a long time as well.

03:23 Yeah, fantastic. PyScript was the big news out of PyCon last year, I think had a lot of people by surprise, and people were very excited about that, including myself.

03:32 Yeah, I'm very excited and, yeah, got a lot of attention for good and bad. Right.

03:39 I'm going to get some more attention today.

03:41 Yeah, hopefully.

03:43 Good. Deep.

03:44 Nicholas, welcome.

03:45 Hi.

03:46 So.

03:46 Yeah, I'm Fabios. I'm a principal engineer on the Pi Script team prior to joining Anaconda in the summer. I'd been a Python Easter for far too many years. And I can't remember before that I was a teacher, and before that I was a classically trained musician. And that probably explains my interest in Python in education and the activities that I still do.

04:11 That's me.

04:12 That's fantastic. You were involved with the BBC Microbit, right?

04:15 Yes, I was involved with the BBC, yeah, absolutely.

04:20 Yeah. That's awesome. We talked about that before. Okay, yeah. Well, let's talk about running Python in the browser. There have been some attempts before, and those attempts are still used in different places. I'm thinking of like, Brython and Sculpt and those types of things. Anyone who has seen the birth and death of JavaScript, that famous 15 minutes talk, which has got to be one of the most hilarious and yet insightful like educational foundations of the Web and JavaScript and what became Web assembly talks of all time is really great, and I think those kind of land in that realm. But since then, as we started, WebAssembly has allowed us to bring real runtimes, mostly things based on C or Rust, but older things based on C into the browser and run there. So who wants to introduce this whole idea of Web assembly quickly for those who don't necessarily know and sort of set the stage so people see where we're coming from?

05:18 All right, I'll take it. So you can kind of think of WebAssembly as almost portable CPU. It's technically an instruction set that basically is almost like assembly designed to just run anywhere. It's all abstracted, it's technically stack based, much like CPython's interpreter, for those of you who want to know insider baseball knowledge or insider football, but that's basically it. WebAssembly is really just portable target to compile stuff for that, more or less. You make a runtime work for that target and it gets run everywhere. There's more details we can get into in terms of WASM versus Waze and platformspecific stuff, but at the core base lowlevel thing underpinning all of our discussion today is WebAssembly, which is basically just a portable CPU target.

06:05 Yeah, okay, excellent. And CPython, I guess, as the name would very strongly indicate, although people might not know it's largely C at its core, it's not Python code. Some of the standard library is, but not at the heart. There's an insane switch statement while loop that is written in C. And so if we can get that into WebAssembly, then we can get Python the runtime into the browser.

06:30 Correct, Technically, as long as you can compile whatever language you want to WebAssembly, that's how we get it in. And traditionally the tool chains that have supported compiling data WebAssembly either statically compiled languages that use something like Clang as a build tool chain, which is typically fallen under C and C++, Rust because once again Rust is based off of claiming it for their compiler. As long as your language could use a tool chain that already had the support to compile down to WebAssembly as a CPU architecture or target, you were able to get some WebAssembly. So in CPython's case, because it's implemented, the key parts are in C that was able to be compiled down so that can run some WebAssembly. Nicholas work with micro Python, the same micro Python's written mostly I believe in C as well. And so basically that allowed both projects to basically just use a specific compiler with specific flags to just say instead of writing out X 64 assembly for my embar intel chip or 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 browser run for your life, right? It's really no different than JavaScript. It has the same permissions and liabilities and benefits of JavaScript, just different execution model.

07:50 Yes, the same sound bulbs as JavaScript.

07:52 That's the core. There are a lot of nuances that comes with how it is.

07:58 It's taught, right. One, it's still in a very young phase despite all the usage and acceleration, everybody is excited about it. But as Brett said, it's mainly a portable CPU and it doesn't really come with the rest of what you would expect from an operating system, and especially like file system and things like this. So there's a lot of extra work that the larger community is trying to add now to figure things out. And the other small detail that I wanted to add is yes, it's basically just like JavaScript on the browser, with exception that some APIs are not available, 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 like having an operating system. There are projects Brett mentions. WASM is also in scripts as well, which gives you abstraction to a file system and so on and so forth, such that you could always important to be wary when a developer uses the word just. But one could just compile deep Python to WASM and it will just work in the browser. But of course, to get that to happen, it takes rather a lot of work and browser based expertise to actually get you to, for instance, the Python prompt in a repl, as it were.

09:19 Which is why wouldn't it be fun if there was some sort of project that got you to Python in the browser having to do all of that boilerplate stuff?

09:28 Yeah, I wonder if we could find one of those. Yeah, one of the things we spoke about before Brett was so much of what comes with Python, the batteries included. The standard library assumes a slightly larger execution environment than front end browser code, right? Like it assumes a file system, it assumes that you can probably open a network socket, these types of things. Right. And so one of the challenges here as well, if you can compile it down, that doesn't mean it's going to be permitted to just take some code and GM at a web page and run it, right?

09:59 Yeah.

09:59 I mean, taking the CPU and the next step, right? Like when you compile something down to a CPU for like x 64, that's great, but how are you going to read a file system that doesn't exist to the concept of a CPU? How do you make things show up on the screen? How do you do lots of other things? That's all implemented by your operating system? Right? It's the next layer above your CPU in terms of abstraction. And WebAssembly only has the start of this concept in one area, which is Wazzy, and another area it kind of just leans hard into the browser space and that's kind of what we call them scripting. Right? So generally the way all this plugs together is if you look at it from a browser perspective, there's a tool called Em scripton emscripton and it's basically a kind of compiler front end that uses claim to compile stuff. To WebAssembly and then has a bunch of shims into the browser to implement stuff like file access, as Nick was pointed out, and all these other things you can get in a rich web environment. But it's provided by this project called Inscriptin and it's not quite an OS, but it's not nothing either. It's this interesting kind of middle ground and it's project specific.

11:11 But then on the other side of all this, there's a project called Wazzy. And this is why when you think of WebAssembly, you start hearing people talking about this compared to containers or edge compute and all this kind of server scenarios where Wazzy acts like POSIX, right? So it's not actually an implementation of an OS, almost kind of like what inscription does, but instead it's an actual abstraction over what you might expect an OS to provide you. So in Waze's case, for instance, it is an implement file access, it implements the function to call from WebAssembly that gives you the file access. So in that case, what you have is you have a runtime. And that run time is actually what provides that level of OS that you need. So if you've ever heard of things like WASM time or WASM edge or wasmar. All of these are actually Wazzy runtimes that basically load up your WebAssembly inject into that code. The functions that Wazzy specifies on how to read files or how to print to standard out or read standard in, and then allow them to run in an abstracted fashion. So it's almost half between Emscripton and kind of an OS, but above WebAssembly. But as you can notice, it's a weird little split here because there's the web part and the server part. And this is where this whole discussion gets really interesting, right? Because now we're starting to have discussions about abstraction layers and which abstraction layers are provided where and this is kind of where webassembly's use to put it one way really shines through in terms of showing that it's all. Still very much actively being developed, 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, where Wazzy's POSIX, right? Just kind of abstractions that someone has to provide. And then you have tools like Inscription that try to kind of specifically in the browser, just go ahead and just lean hard in the browser specs that the debris has given us and the browsers hopefully implement and just use those to implement those things that you would expect from an OS. So it is, as you said, an interesting problem where from C's Python's perspective and most Python implementations, right, historically we've had a full operating system Micro Python is going to be the exception, which Nicholas, I'm sure we'll talk about, but from a CPython perspective, PyPI whatever, where you say running on Windows, Linux, Mac, right?

13:33 Like it jammed down into a tiny raspberry Pi. That doesn't happen anymore because you can't buy them, they're unobtainable.

13:42 The key point is like a full OS, right, where we didn't have to concern ourselves about what was or was not available. But in a WebAssembly case, right, like in the browser, if you use Em scrpting, you only have available what emscripting gives you. In the Wasm's, you only have what's been standardized by Waze and that the runtime you choose to use has actually implemented. So we're in this interesting new kind of world where what you might expect from the standard library, for instance, in Python that's always been there, like threads aren't necessarily there. 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. We're kind of going back in time in a way of kind of this clear separation of language versus implementation 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:37 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? I remember the last time I did that was around the year 2001 and yes, it was quite the odyssey. Of course, we don't do that anymore. We run our code in the cloud with near instant provisioning and unparalleled data centers. And the most popular cloud provider is AWS. But for all the ways that AWS has made our lives easier, it has also opened a massive box of choices. Should you choose platform as a service? Or maybe it's still VMs with IAAS. What about your database? Maybe you should choose a managed service like RDS with Postgres. Or is DynamoDB better?

15:19 Maybe Aurora?

15:20 No, wait. I hear good things about Amazon document DV Two, and that's where the AWS Insider podcast comes in. This podcast helps technology leaders stay ahead of Amazon's constant pace of change and innovation. Some relevant recent episodes include Storage Wars, Database Edition, Microservices or Macro Disaster and exploring computer vision at the Edge with AWS Panorama. They bring on guests to debate the options and the episodes are vibrant and fun. So if you want to have fun and make sense of AWS, head on over to talk Python.

15:54 AWS Insiders yes, I know you probably.

15:58 Already have a podcast player and you can just search for it there, but.

16:01 Please use the link so that they.

16:03 Know you came from us.

16:04 Thank you to the AWS Insider podcast for keeping this podcast going strong.

16:12 It's very exciting and very fresh, meaning that in a good and bad way, right? It reminds me a little bit of what happened with NodeJS, right. People are like, look, we're writing all this advanced code and the browsers are getting really fast at running JavaScript. Like, no, they're not similar to Apple silicone. Like, you can't take a phone and make that your fastest computer. No. And then somebody does, wait a minute, look at this thing go, wow, you could have a server side JavaScript, which I don't necessarily want to go touch, but it's a similar transition that we could have Python in multiple places, right. And it theoretically could run the WebAssembly version on the server as well for parity or I don't know if that makes any sense, but it's a similar transition in ways maybe in the reverse direction than JavaScript, but somewhat like that.

16:59 Yeah, it's hard to predict as you are living through things. Right. 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, and also not having a great story for the most popular virtualization software, which is the browser. Imagining how Python will change with the WASM stories, I find it very interesting because it basically introduces a series of concepts that we are not used to. It's not just like run your environment there. There's a whole packaging part of the process that we need to think about and how do we distribute that code. 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 treeshake, stuff and all those funny things. 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:16 It incumbent on us to sort of adapt and change and make the most of the opportunities that we have presenters. But as Brett and Fabio said, it's a strange world in that it's not like I've got a lib C, and I know I can't be able to get to the file system and things like that. There are these kind of shims and slightly different abstractions that may make Python feel like it's, as I said, duck out of water, snake out of water. I don't know. You know what I mean? It's not in its natural habitat, watermarkers.

18:51 But I think I'm pretty confident and bullish about the Python community and our ability collectively to find a way forward with this. We've got a beautiful language. Let's bring it to Ireland.

19:05 Many people love it. And when people say, I love Python, they might mean the language, but usually I think that's only a part of it, right? Often that's the ecosystem and the whole broad all the packages and all the people on the project. And in that sense, like, Python is very much empowered to make some really cool transitions there. We don't have to always kick it back to the core devs for all the work. Although, Brett, congratulations, I guess, on 311, right?

19:31 That's a big deal.

19:33 I did a small amount, but thank you. It seems to have been taken very well. The community seems to have picked it up faster than usual, which has been really fantastic. Dependencies seem to have been ready for this and got wheels out early, which was great because it made transitioning a lot easier. So kudos. And thanks to the community for putting in that effort to get stuff ready to go as of October, so that when things launched and we were able to do that zero release, people were able to just install it, download packages and have the wheels ready to go and pretty smoothly.

20:03 Yeah, that's awesome. Either of you other guys have any contributions to 311?

20:07 Oh, yeah.

20:08 We are happy consumers.

20:10 Yeah, exactly.

20:12 All right. One other concept I really want to quickly throw out there and just get your thoughts on. I don't want to go deep on this, but one of the things that seems to me like an interesting benefit for WebAssembly is the interoperability with other languages, like WebAssembly can call WebAssembly. 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. What do you think about this? Yes. Or is this just dream?

20:42 I think the answer is you could, but I also refer to the honorable gentleman, to my esteemed colleague Brett earlier answer about this being ready for the imagebook space as well. To honest with you, I used to be a net developer before I came to Python. And the fact that Net has this notion of the clr, the common language runtime to which C#, C++, Visual Basic, F#, Iron Python, I don't know, whatever compiles. So it feels like it's a very similar space as you're implying. Michael yeah, the blazer actually is like.

21:13 Incredibly near 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:23 I think it's actually on the page you're looking at right now. If you're watching a live stream, it's right below the fold. The important note, Wazzy is in transition. The transition part is there is work towards something called the component model, specifically in Wazzing, which is defined more or less what you're talking about. Michael which honestly feels like CORBA for the new millennia. To date myself, or at least date my PhD supervisor who did his PhD relating to coreba.

21:49 You said korba, right? I've not thought about that since, like, the year 2000. Okay.

21:55 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. I mean, for the Python audience you can think of, it is almost the CPython API, right? It's kind of like what does CPython export out and then what you can use from your extension modules. It's the similar thing, except it's done at the WebAssembly level. So you can just say, like, okay, this function will return a string, and then there's a definition of what a string is for WebAssembly. So that when you say, oh, internally, I might use UTF 16, but a string in the WebAssembly component model context is UTF eight. So you have to encode out to UTFA. On the other side, you go, oh, hey, I'm going to call this function oh, it gives me a string. I know that's going to come as UTF eight. If you can keep using it that way, great. If you have to change it to UTF 32 or something, you can. But it's defining the theme of your WebAssembly module and what it looks like in terms of what it exposes to other people. So that's that big dream you mentioned of people writing stuff in other languages that we can just consume directly from WebAssembly.

22:56 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? I don't even know technologically what we would do to make that work in terms of pulling another webflowing module, because honestly, it's basically like linking, but we don't have that concept of linking a Python. You just run an important statement.

23:16 There's no header, what's on the other side.

23:18 Exactly. Right. And that's exactly what the component model does. Right. It's an interesting position, actually, credit to Peter Wang, who you can send the Love Hate to later on this analogy. But up to this point, a lot of the web semi world has been these languages that are compiled, right, like the C and C++ and the rest stuff like where you just pull in all your code, you compile it, and it kind of works. And it's very much set up in these worlds where, oh yeah, it's compiled whatever, as you said, header files. It kind of comes together. But we come from this world where people have poured all this time and energy to wrap all of this esoteric C, C++, Fortran, then code, and give us this nice API in Python. 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 loaded plug it right in. It just works like, no, we're going to import some Python code and it's going to execute as part of import, right? Like, I don't know how people know that, but literally the way important works is it calls exec on your code, right? Extension modules use some really crazy chips from G Lib C to pull in that data off that module, which we don't have in WebAssembly stuff. So there's a potential disconnect here at the moment. And hopefully, as Bobby said, in five years time, we can kind of work together to kind of work with the web submitting community to make this a solved problem. But as of right now, that component model is not designed for us, the Python community. It's designed more for the C, C ++ Rust World, and we're probably going to have to work with them to try to figure out how to make that work with us. 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. And I think we're going to be, I don't want to say bringing the WebAssembly world kicking and screaming. I think they're just we haven't fully introduced ourselves yet, and I think they're going to come to get to know us and we're going to start bringing some new stuff. So I don't think we're quite ready for this whole magic, bringing other WebAssembly stuff, but hopefully we can work with them to make that happen because as of right now, it's not in the cards.

25:15 Yeah, I like to make a comment on this one because it actually is a topic of we have the running joke inside the PyScript team where Antonio Koony and I always argue about everything, discuss. And this is a big topic of discussion because Antonio is more lower level and very smart and I look at things more on the higher level side. And I often tell I really want to see Python working with alongside with R or other languages for data science, 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. And he's like, it's never going to work the way you want to because you don't know how types are going to be translated into WASM for different languages and yada, yada, yada. But one bridge that we have right now is JavaScript and having proxy objects in JavaScript that relates to Python on the browser or Rust or things can be a possibility too. But in general, I think what I always end up saying, Tony, is like, we're kind of in creative mode right now, or experimentation mode, where we can try stuff 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, right? 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. Anyway. I think it's interesting.

26:53 Yeah, this is such an interesting conversation on so many levels because Brett mentioned Cobalt, which is like this thing from way back when, before I was ever a software engineer. Okay. And Fabio is talking about how, you know, he has a high level view. Antonio, you know, from PyPI, has a very different perspective on this. And I would say that and also Fabio's Pragmatism as well, about we need to get something to work because then we can do cool stuff with Python in the browser. 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. I'm not saying it's interesting watching these two have an interesting discussion in our morning stand ups or whatever, but what I'm talking about is that that's the intellectually stimulating thing, because you have two different perspectives. And if like Fabian Antonio are they're excellent engineers and they can see and empathize with what the other person is talking about and adjust their position. And then eventually we kind of zone in on various potential solutions, which kind of goes back to the Cobal thing. Which is why I brought it up, is that I remember meeting an old Greybeard programmer when I was a young whippersnapper, and he was I can't remember some thing had. Been announced. And I was like, this is amazing. It's going to change the world in that way. Young Programmers. And he was like, oh, yeah, we're doing this in the 70s with punch cards or something like that. And so, once again, we have this cyclical nature in the history of programming where we're coming back to these kind of archetypal solutions implemented in different ways. And you can actually see perhaps that the whole WASM and WASI thing as yet another iteration of this. Because we're rethinking what a computing platform is. 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, 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. And that's called progress, folks. But this is why it's so interesting. 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 eleven 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. And, you know, that is something to work for.

29:16 Yes, that's fantastic. And if you don't like the Tools.

29:19 Or just for the podcast, a little device with the Phone.

29:22 Yes, sorry.

29:23 Spread.

29:24 By the way, we're not paying Nicholas for every pitch on Pyscript. It's out of his heart.

29:32 He does amazing job.

29:35 Let's talk about a little bit about MicroPython.

29:38 MicroPython is amazing. I recently sitting around my desk stuck velcro to one of the hosts of my desk is one of these ESP feather 32's, thirty two Feathers. I don't know how. Feathers.

29:53 Those words.

29:55 Thank you. Device running python connected to my WiFi, seeking a bunch of stuff on the cloud and just a little thing that blinks every now and then to tell me everything's cool. It's doing its job. And these are amazing.

30:08 I know Circuit Python is not identical to Micro Python, but they're very new and they've been brought closer together as well, which is great. So if we download the entire C python runtime over WebAssembly, it's not totally small, right?

30:20 It's eleven, Max.

30:22 Yes. Which we have fast computers. 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, right?

30:35 This portion of talk Python to me is brought to you by the Local Maximum Podcast. It's an interesting and technical podcast that dives into trends in technology, stats and more. But rather than tell you about it, let's hear from Max and Aaron about their show.

30:49 We are now on with talk Python to me. Let's say hi to all the Python fans.

30:53 Hi.

30:54 Python fans.

30:55 I'm Max Guard. I have actually done a lot with Python myself. So I am a fan of Talk Python. Do you know Python Aaron?

31:02 I took a course years ago, but.

31:03 I am a little rusty.

31:05 We are here today to talk about our podcast, The Local Maximum. 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. Here on The Local Maximum, we tackle subjects in software and technology topics as diverse as the philosophy of probability to Elon Musk's next move for Talk Python listeners, I want to highlight a couple of recent episodes of The Local Maximum. In 248, for example, I found out about an open source library that maps the world into Hexagons and some Pentagon. I had a discussion with an author about games and puzzles, and another on a novel approach to doing the job search.

31:41 Well, we discussed the ramifications of AI generated art. 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 Micro Python. Maybe tell us a bit about that. That's smaller. Right?

31:59 OK, so MicroPython is the wonderful creation of Damien george. Damien is a physicist by training. He once told me what his PhD thesis title was and it's something like eleven dimensional. And then he lost me. But he was at Cambridge and one of his hobbies, or part of his background in his studies was working with robotics. And he was part of the Australia team that entered the Robo World Cup for Americans. That's soccer, as it were, which is rather appropriate given the fact that the World Cup for human beings is happening right now. 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. Okay? And he learned a lot by doing that and then realized, well, actually, perhaps if I take the things that I've learnt building this stuff to a proper scripting language, then that would be a cool project. So he looked to our own thinking, well, what are called scripting languages, and arrived at Python, 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 MicroPython would be there. Well, I think 100,000 plus dollars later, and, you know, lots and lots of boards for boards later, MicroPython has become this amazing success. And the whole point I know I.

33:26 Caught the car moment, right? The dogs, I caught the car like here we go.

33:31 Yeah. Well, it rather surprised, Damien, say the least. But now Micropyton is designed to run in highly constrained environments. So for instance, I believe it can work with only 16 k of Ram, for instance. 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. And Damian pulls an awful lot of tricks to actually make it work really efficiently. But because he's a physicist, he knows how to do experiments. And so that's what he does, literally. 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 reimplementation of Python Three on something that maybe has 16k of ram like, I don't know, a microbit. Unsurprising. I have a box of microbits on my beautiful and circuit. Ciircuit Python is a friendly fork of MicroPython by the wonderful folk at Adafruit. So I think it creates an interesting dynamic because Micro Python is perhaps the industry version, where a circuit Python provides a consistent API for all the Ada boards. It's aimed at education. They've got a whole bunch of tutorials and support for that sort of stuff, and they're forever bringing out incredible new devices, as I'm sure we've all picked up at PyCon. The circuit playground.

34:56 Exactly.

34:57 Great conference back. So that's micro python in a nutshell. So what's it doing on WASM well, it's because 16MB is rather a lot to try and download even today over a 4G network. 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. And so one of the first things I did when I joined Anaconda was just see what happened if you run it on a mobile phone and it took 16 seconds to get to Hello World, which is not an optimal kind of solution. So what would work? And very quickly, I came to playing around with MicroPython, and MicroPython is under 100 milliseconds to start up and get you to Hello World. It's fast enough and you've got so here's the interesting thing. I'm interested to hear what Brett says here. It's a full reimplementation of Python Three. However, there are differences. 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, we kind of got this Platonic Python, this ideal Python that doesn't actually exist. And then you have all of these implementations, of which, of course, the CPython version is the touchstone. But MicroPython doesn't have all the APIs, it doesn't have the full standard library, and depending on the size of the device, it might not even support floating point numbers, for instance. But it's Python. It's the Python that we love. You still got indentation in the white space that annoys the C developers or whatever. So it's good enough for me.

36:31 So we can compile this much smaller, more lightweight version to WebAssembly and do similar things. 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. 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 or way back in Greek philosophy and the Platonic Python, if you will, platonic ideal language the essence. Yeah, I mean, you're a philosophy, the essence, the core. That this is the little bit we circle and say all Python does this. 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. 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 Micro, Python and Python weren't left behind from the standard library so that they could just work and not have to reimplement the C API for key things like the date time module. So I have a massive bias in this statement, to be very clear. So I am not representing necessary the entire Python core development team or the steering council on this. But for me, it has always been a separate concept of what the language is and what the reference implementation is, right?

38:00 We may do development of the language using the CPython reference implementation, and I'm very specifically using the term reference implementation as a way to help make the language evolve. But for me personally, they are two separate concepts. They just happen to be developed simultaneously and by the same group and it's mainly for convenience and just be able to work faster. But I do view them as separate things and it does make sense, right? 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, and some people just care about the evaluate that makes CPython run, right. The big switch statement you mentioned earlier, Michael. So for me, this is totally great. 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, but hopefully good enough for people to be able to follow, to implement the language. And to me, that is really what people are targeting. I honestly, once again, major bias showing here. I don't consider the Stern library part of the language. The stern library is a very key piece of functionality and a key convenience and potential differentiator for Python in some people's eyes. But I do not consider it part of the language. It is just something that we have developed over the years that has helped accelerate Python's growth. Because back in the day, batteries were not batteries had to be included because guess what? We didn't have PyPI like vaults of parnassus had little animated gifs of a website where you downloaded zip files and you unzipped yourself, everyone Vendered everything, because there was no installer, there was no pip, right? Like showing my age in the Python community. Right.

39:44 We had to do the batteries included thing.

39:46 Did you encoded off of usenet to get your package?

39:52 No, but I was not that far back into programming that I mean, I used now that don't get me wrong, but I was not coding at the time and use that. That was the way it was kind.

40:03 Of just like it's wherever it ends up, you grab it and you put it in your project and you run with it. Right? There wasn't a vocation.

40:10 So to me, there's a very clear separation here. And I personally view the standard library as a thing that represents the time of when it was created. But to me, it has never been the language. The language is what's in the language guide and more or less what's built in. And that's kind of it. The important statement brings all this wonderful stuff in for you, but that's not the important statement part of the language, but what you can import into it. Unless it's like Dunder future, which is baked into the language definition. I don't consider that part of the language. And I've said this controversially once on the former Web site that we all used to hang out on before mastodon, where I actually said, like, the reptile, for instance, is not part of the language either. Technically, if you think about it, it's a wonderful tool. And don't get me wrong, it definitely makes Python more useful. But for me, personally, the repl is not part of the language either. It's just something we all ship because it's so useful to use. Python enables that kind of development process.

41:06 So MicroPython saying it targets Python, I believe, technically, three four with extras means it is an implementation of Python for Python 3.4. And that's great. And whether it comes with everything that the Syrian library that see Python had for three four is a positive, is a plus what it has. But to me, that's not the language, and to me, they're very clearly separate concepts. It's just people get very spoiled when they just download CPython and go, well.

41:31 My code doesn't work over here.

41:32 It's like, well, you can use CPython almost as a platform, and this platform just doesn't have the same platform. Same language, just different platform. And to me, that's fine. It just is what it is.

41:42 So it sounds like you're okay with the Micro invasion. Oh, yes.

41:45 I care about the language. Right? If CPython is the way you get it fantastic. If you get some other way, that's also fantastic. I personally care about the language. And, I mean, we all know the community that comes with the language more than the implementation and the fashion.

41:58 Don't forget the fashion and the fashion.

41:59 Yes.

42:00 No, go ahead. I was going to say before we pressure Cord that was a running joke. But bring us back to the serious.

42:05 Conversation, Brett samples. 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, which is, if you're coding with, say, for example, Micro Python, 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. Mostly behavior is the same, although there are some very subtle differences. But, yeah, it's mostly the experiments I've been doing where I've been using Pyidide as the reference and MicroPython as the thing to compare. I can just slot one in and slot the other out, and pyscript sits on top of it, and I can make things work as I want to. 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. We'll get to that when we get to it, but it's mostly the same. But folks should know that they are different and well, there you go. I'm just flagging that. I need to flag that.

43:09 Yeah, absolutely. A quick question from the audience here.

43:13 Do you think more stuff needs to be removed from CPython? I mean, I know actually that was one of the things that the 311 release addressed was a bunch of models were either removed or deprecated before. I think, Brett, we spoke about that a year ago or something, maybe, if I remember.

43:29 Yes, Christian and I came on maybe almost a year ago. Not the day, but maybe to the month, October last year, 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, I've actually put myself back up for the Python Steering Council. 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. What would go in there today if we were to have guidelines? Because we actually don't have guidelines on what should go in. Historically, it's just been a core device gone. I want this in, and people just kind of in general consensus go, okay. Or honestly, I'm going to add this, and they sometimes have added it because five or some odd cordevs all agreed to it and just kind of goes in, and they just didn't think to have a wider discussion. Like not going to go down details on that one. Anyway, point is, it's not had any guidance to it, and it's a discussion I want to have. And I don't know if it's necessarily going to lead to a shrinkage of the standard library, just because, once again, from CPython perspective, there's compatibility to consider.

44:37 Right.

44:38 And we don't want to just rip stuff out. But it is possible we might start deprecating more stuff right, beyond what the dead batteries work, because the dead battery list was very conservative. Basically, almost anyone brought up any objection to something, we left it whether we thought it was reasonable or not. So I can very much see a future where we maybe have a list of like, yeah, this stuff is here, but don't really rely on it. And obviously Micro Python probably doesn't really shift that stuff now anyway.

45:03 But yeah, personally, I would love to see the style library a bit smaller, if for any reason, then it just makes it easier to maintain because there used to be, before the dead battery pep, more modules in there are countries in the world, so, like I say 198. So there's a lot of stuff in there and we can probably stand to shrink it. And once again, it kind of makes it a little easier for other projects to not get pushback from people and like, well, where is this module in CPython? Well, we don't have it. Well, why not, 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's. Like it just doesn't make sense for us as a platform.

45:38 Right.

45:38 And as we talked about before, some of these things being included came from a different time. For sure. All right, well, I never want to.

45:46 Go for a living, so it's also.

45:48 Worth noting we're sticking with Archie. Sorry, go ahead.

45:52 No, I was saying those batteries have a cost, and every time you have to run limited devices like Micro Python or the browser, you realize that. And then the question becomes, well, is that user base significant to the Python project to make a change on those? And that comes with conversation and evolution.

46:14 So I think probably it's always a trade off. You say, let's remove Tk into because it's a Gui from the mid ninetys and nobody uses it, and then everybody points out that the Tk module mostly uses Tk into and teachers all over the world will scream and you've got a big problem.

46:35 It's a Gordonian knot.

46:37 Sure is. All right, let's bring in the third major project here, which we touched on a few times. But Fabio, tell us about pyscript. What a cool project.

46:46 Cool. Thank you. Yes.

46:47 Where does it fit in this Piodide WebAssembly, micro Python world. What's the angle here?

46:54 I think it fits as a glue. Well, pretty much like Python was glue for a lot of things. Like the concept of fire. Script was really realizing that a lot of most of the technology for Python to run the browser is there. And it's been there for years now. And what we're missing is the easiness to just use it without having to spend hours or days looking for how to import things or the JavaScript side of it, what it means as a web dev to start using Python. So the idea was really like, can.

47:32 We because it's one thing to have WebAssembly, so it's one thing to have WebAssembly CPython, it's another to build meaningful things in the browser with that as a piece. Right.

47:43 Kind of gives you a framework to write Python code in the browser based on this WebAssembly, right?

47:49 Correct.

47:49 It's not a framework, it's a platform. And we 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. And I know that I trust the Python community will come up with something that we can't even begin to imagine now. But the thing to do is remember that pyscript is that sort of platform layer rather than a framework. But in that platform, what we're looking at is perhaps plugger 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. Michael, like you said, that's useful, folks.

48:32 Okay, so we might have Pyodide, which is a more full featured version. We have MicroPython for a fast, speedy version.

48:41 And there are other projects as well that are coming up, or other languages too, right?

48:50 Definitely in the interesting. Exactly.

48:53 There was a big announcement that got thrown. Here we'll go. This way we'll go with Simon Wilson, who was on the previous show about Mastodon previous episode. 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. They just call it published now. I think they're downplaying the toot, but it's going to live on toot said huge Python WebAssembly news tucked away in this post from Anaconda here. When you apply micro Python to WASM in its default configuration, something new and exciting emerges. With a total size of 300 KB, this new runtime lids instantly and starts executing MicroPython logic in less than 100 milliseconds. That means the cost of running micro Python on the web is now equivalent to serving up a large hero image. This is awesome, you guys. Where are we going with this?

49:40 Whenever you meet Damien, you buy him a beer is pretty much what I would suggest, although not too many.

49:51 Yes.

49:51 This is fantastic, because if we do have a really small runtime, then all of a sudden you could when people saw PyScript Fabio, they're like, oh, my gosh, can we replace JavaScript with Python? And the answer was sometimes, but not in general, right?

50:05 Yeah, practically. This is Paul Everett, who's been around the Python ecosystem for a lifetime and is really great, and we were talking about that in Python four web during Python. 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 and you're mostly wanting to show content rather than a fullblown application. And I think he still thinks Python is not going to be a reality for the content web. I think this brings it really, really, really close. And you can have basically Python running for content, but also the amount of possibilities around education, around exploration, real time and stuff like this is tremendous. 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. And let me explain MicroPython, for instance, instance, doesn't have a JavaScript interface, right? So if we could have a module, maybe it's the Piodide one that we ship out or we develop a new one where we can explore that Python to JavaScript interface and make it available for all the interpreters and it's just like a package and you can install it. We open up new channel or the whole packaging story for python on the browser. And if we can figure that out in a way that we can just install packages and doesn't matter the interpreter because it will end up like being Wasm, then I think we can build a very strong ecosystem where if you need more complicated things, we run with your full CPython and wasm interpreter. Otherwise you can just use MicroPython. 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? And often that means notebooks and data science and scientific computing. And there's a big desire to sort.

52:19 Of move that to the front end.

52:21 And just say, let people run that on their computers and they can do kind of like notebook things on the front end. 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, but I want that interactivity, or I want maps, or I want most modern, highly dynamic, single page app type of web apps, but I want to write that in Python. That to me feels like that's almost the dividing point of like, well, we want the Piodide 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, you know what I mean? If I've got to only use a few packages and I can still write Python end to end, that makes me super happy, right?

53:06 As you said, we can augment the things that Python can do. 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 even mobile and stuff like this, because WebAssembly can run on mobile as well. So, yeah, the competition between all the arguments framing Python versus JavaScript, I think they really miss the point where it is augmenting both ecosystems right now. We now can use D 3 in Python and vice versa. JavaScript developers can use NumPy or Pandas. It's a win win, to be honest.

53:47 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, but not only can you run Python code in the browser with Pythect, but you can hook JavaScript events and then you can change Dom elements. This was the JavaScript to Dom interaction layer you're talking about before, right?

54:05 Yes, yes. And actually to what Nicholas was saying about the difference between we want to really sell the point that PY Script is a platform where 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. And not use any JavaScript. I hope we can get it in this next release, but for sure, before the end of the year, we are allowing that, and it's going to be a huge improvement in what people can do with PY Script. And actually, how can people extend the platform at creating new frameworks?

54:43 So are you envisioning or are you at least aiming for, if not fully envisioning, something like Py Vue or Py React or like some of these traditional fertile frameworks, but a Python equivalent?

54:56 Nicholas that's a loaded question. I think a Py angular I was kidding.

55:03 I think that it makes a great story, if you're a journalist, that Python's going to come up and eat JavaScript lunch in the browser. That's a false dichotomy. That's a great way of getting clickbait and things. If you want to write web based app stuff and you're familiar with JavaScript and React, just use the tools that empower you to write the stuff that you want. But for the quartet of us in this conversation, we're all Python Easter, we all appreciate the aesthetic of that language and the way it works. 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 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. You know, software is never finished, 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. Exactly the question that you just asked Michael. What about all of these kind of things of building apps with Python in the browser? Well, what I found is that I need to dig a bit lower to do some more call pyscripty things and then dig a bit lower to look at perhaps what the run times are doing and blah, blah. And here I am messing around with my 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. 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. 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. There's nothing more intimidating than that, let me tell you. Print. Hello, world. Doesn't cut the mustard. Okay? This is not exciting for them, but if we can make something, I want.

57:14 To build this thing I saw on Unreal Engine Five in Python.

57:17 Exactly. Exactly.

57:20 But if we could make it so that they can do the equivalent of the MySpace, hi, NAN, I'm on the Internet within two minutes. You've got a website, you've got a very quick way of getting onto a mobile phone or tablet, which, let's face it, the state's teenagers, that's their primary computing device. And I've been classrooms where kids can't type because they don't know what a keyboard is. They use a keyboard every day, but they just use their thumbs like this with it. And when you give them an actual mechanic we are dinosaurs using these keyboards now, right? Okay.

57:51 We're going to evolve massive thumbs or something. But it's that sort of a situation, okay, 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.

58:05 You're touching on a very important part of the PyScript vision, and it's really not about the current Python community user base. It actually is. How can we democratize programming and Python and everything we really want to be thinking about, who's not thinking about coding at all? Like people that would love to use programming language as a tool for them to do things and they can't, either because of time or because it's too complicated to get Python working or all of that. That's a plugable. And I'm going to quote Peter again, because we are talking. And welcome back, Nicholas.

58:47 Peter at some point mentioned something like system design with plug ins from the beginnings. Kind of indication of the developers not really knowing what they're doing or not really knowing what it should do, which sometimes is a negative connotation, but for PyScript is definitely intentional because we want the community to be able to create their own things and it's really greenfield. So I don't know what they're going to be doing. I want to allow them to do crazy things and surprises.

59:20 Last Djangocon Patrick came up with this experiment of running Django on either PyScript or Pyodide, and my first question was why? Right, but then who cares if the.

59:33 Web is inside the web? Inside the web.

59:36 Exactly.

59:36 Like, inside all the way down.

59:39 That's the whole point. We want to make it funny, accessible, and a safe hacker space.

59:46 Yeah, it's such awesome market. Congratulations, you guys, on this. When will we see something that we outside that don't want to grab onto an inflight open source project, but like a release equivalent of this? Is there 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:09 Okay.

01:00:10 I can certainly tell you what the state of play is right now. And you can extrapolate when you may see sort of things like micropython. Because PyScript, proper PyScript is undergoing active development, I didn't want to try and plug in new runtimes, new interpreters whilst the sand underneath me was shifting, as it were. So I created a very small and simple test harness version of pyscript that I've called, surprisingly enough, micro pyscript that is going to be thrown away. Its sole purpose was to allow me to just poke these things with a stick and see what happens. I'm still using that to, for instance, figure out how we can do MicroPython Dom connectivity and interactions as well. That's literally what I've been doing all day today, is reading I needed to do to make that happen.

01:00:58 It's going to unlock so much once the Dom is in play, then all of a sudden it's on.

01:01:03 Yeah, everything else is yes, 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, and it's changed a lot since then. And we'll integrate that work. So I expect and this is a finger in the air, and remember, the right answer is when it's ready. But I imagine it's going to be kind of springtime first, say maybe in.

01:01:38 April, like April 19.

01:01:43 I'm not going to mention any dates because you're just holding to it.

01:01:46 I'm not going to mention anything.

01:01:48 I'm just teasing you. I'm not holding you to that.

01:01:51 I hear that conference where is very real so we can promise for Python. No problem.

01:01:57 I hear a good place to announce new JavaScript packages is Salt Lake city in April. So I'm going to give you the final word here, maybe to put one more thought in this before we wrap up our show. Nicholas talked about, and Fabio also talked about how do we this could be an empowering thing for other people, right, for kids in education. And whatnot if you look at a lot of education as Chromebooks? It runs great on Chromebooks, the web. Also VS Code in the browser, is there some thought of like, interesting, your web development environment, 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, if you go read a release notes, we actually have an extension that will load up into VSCode Dev, which is an actual website, not the name of a product you literally go to vs Code Dev, they'll load up in the browser. And there's a Python extension by my teammate Dirk that uses Waze and the CPython build, where you have a repl. You can run code from your workspace wherever it's loaded, right? It doesn't have to be on disk. It can come from GitHub anywhere. Vs Code can read files from it can load and be seen by Python interpreter itself. So that's all working. And just this past week, it's not out yet. To be very clear, dirk got Debugging working using Wasi and a very cool trick that everyone can it's very Unique C. I don't want to spoil it. It's going to be open source, so it's not a trade secret or anything, but it's way easier to read about it and try to explain it on a podcast. But we got Debugging working as well. So we are trying to work towards a complete development story such that, once again, for the for beginners, for learners, for the education market to at least have a baseline Python experience, where you can write code, read code, vote, read files, debug. 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. I do want to add two other things to this, though, is actually kind of call to action for the community around all this. One is I don't think we've all started to think about the opportunities here beyond what we've talked about. Right? There's more to this than just what we have in the browser. And it's one of these PyScript ties list all shifts. So it's not that I want to take away from what PyScripts done, all this wonderful stuff in the browser, 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 PyScript engagement. 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 are things really oriented towards JavaScript as a platform and go like, oh, you know what, we might build these Python here. Now, for instance, you could probably and I've had time to test this, but I see zero reason why this couldn't work. You could probably start writing GitHub actions in Python now because guess what? It runs on node and node can run WebAssembly. So we could totally take either Nicholas 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, and then suddenly just say, call this function and suddenly all your stuff is going through Python. Because guess what? At that point, get up actions is all totally driven via standard out and some special formatting in it. So you could totally just do that. And I think Nicholas wants to interject with something.

01:05:13 Yes. It's worth pointing out that Damien, who has done a lot of the work on getting MicroPython to work with, was clearly he knows the codebase and things like that.

01:05:22 MicroPython, if you look very carefully at the WebAssembly port, you'll notice that there are conditionals that check whether it's running a node or in a browser. So go knock yourself out. Try that. I've not tried it. I've clearly been busy doing other things. But folks might want to have a go at using I feel like we should award a prize or something if you win a thumbs up or something like that. If you can get a GitHub action running micropython.

01:05:46 Yes. I mean, that's fantastic, right? 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 been able to do before. 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. So this is going to sound a little weird, but I want to push people to write more Python code. And the reason I phrase it this way is we've historically, as a community have 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. But when you do that well, right now, Fabio, Nicholas shed a tear because that makes it that much harder to make that run in PyScript. And same for anyone else who wants to do this WebAssembly thing, right. Anytime you write anything in something other than Python, it's harder to get running right somewhere else. Now, you mentioned the 3.11 release, Michael. My hope here is now that we've got that nice low 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, because once again, that stuff can get brought over today. There is nothing you have to do to make this work, right? Like you can load pure python wheels in PyScript. You can do that on WebAssembly, right? It just runs. So we can kind of nudge the community back towards running more Python and leaning less on the accelerator code that we've historically written for these kind of platforms. Or do both, right? Like, if you can at least prototype in Python and keep that running and then write the accelerator code behind the scenes, you can have multiple wheels, including a Pure Python wheel. Like coverage.py, we all know, does this exact thing so that it works no matter where you are. Same thing for this case, right? If you can get the Pure Python wheel out there, then it's going to be usable everywhere. 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 you write your Python code even more than you may have before because it's usable in more places.

01:07:43 That's a really great advice. And it's not done getting faster, right? The faster CPython team is still making a bunch of steps, so it's much faster now, but there's.

01:07:55 Yes, exactly. It's going to keep going. I don't know how much faster 312 may or may not be. I think there's some plans for 312 that are really foundational, so the bump might not be quite as big as 311, but 313, if the foundation lays in 312 will hopefully get the bump. So, yeah, hopefully you'll keep getting those wins going forward. Right? And I know Damien's Constant is still working on Micro Python to make it faster and smaller and better and all that stuff. So it's not just a CPython thing either.

01:08:22 Everyone's always trying to make Python run better on all these platforms. So key thing, though, is the common bottom layer of all these platforms is actually Python itself. 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 produce in more places. And once again, Help Nicholas, when he faces down that class of 30, gets damaged.

01:08:44 Yes. You can create Call of Duty. Okay.

01:08:46 Thank you, Brad.

01:08:47 That's a great thoughts. And it also points out I should pay more attention to those release notes when they come up in my Vs code. Like, oh, no, one out of the way. Maybe I'll read them.

01:08:56 All right, guys, thank you so much for all the work on this. This is super exciting and yeah, I'm looking forward to hearing about it in spring or whenever it's ready.

01:09:06 Brett.

01:09:06 Fabio. Nicholas. Thanks for being here. It's been great.

01:09:08 Thanks, Michael. Thank you, Michael. It was great.

01:09:10 Thank you, Michael.

01:09:13 This has been another episode of Talk python to me. Thank you to our sponsors. Be sure to check out what they're offering.

01:09:19 It really helps support the show.

01:09:21 AWS is the lead cloud for developers, but with over 250 services, it's an overwhelming set of choices as to where the AWS Insiders podcast comes in. Their job is to help you make sense of all those AWS options. Listen to an episode at Talkpython.FM/awsinsiders listen to the local Maximum podcast. Learn about topics as diverse as the philosophy of probability and Elon Musk's next move. Just search for local maximum in your favorite podcast player.

01:09:53 Want to level up your Python? We have one of the largest catalogs of Python video courses over at Talkpython. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription in sight. Check it out for yourself at training.talkpython.FM. Be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the itunes feed at /itunes, the GooglePlay feed at /Play, and the Direct rss feed at Rss on talkpython.FM.

01:10:25 We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.FM/YouTube this is your host, Michael Kennedy. Thanks so much for listening.

01:10:39 I really appreciate it.

01:10:40 Now get out there and write some Python code.