#235: Python in your Browser with Skulpt Transcript

00:00 Do you dream of a day when you can write Python in the browser rather than using JavaScript?

00:04 This is no pipe dream. There are several ways to write Python that run in the browser already.

00:09 One of the leaders here is Sculpt. This is not just an experiment. Real,

00:12 powerful web applications with rich client-side code, Python code, are out in the wild and built

00:18 with Sculpt today. We dig into it with Meredith Loof and Albert-Jan Nyberg on this episode.

00:24 This is Talk Python to Me, episode 235, recorded September 26th, 2019.

00:29 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem,

00:48 and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy.

00:53 Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via at Talk Python.

00:59 This episode is brought to you by Linode and Tidelift. Please check out what they're offering

01:04 during their segments. It really helps support the show. Welcome to Talk Python to Me.

01:08 Hello, great to be here.

01:09 Hi, thank you.

01:10 Yeah, it's great to have you both. And Meredith, welcome back. We talked about your cool project,

01:15 Anvil, about two years ago, wasn't it, on the show?

01:18 Gosh, yeah. November 2017. Feels like a lifetime ago.

01:21 Yeah, in Anvil years.

01:22 Oh, yes. Well, startup time operates. It's like dog years, only more intense.

01:25 Yeah, yeah, absolutely. And nice to have you here, Albert. So I kind of want to start the

01:30 conversation here. We're going to talk about Python in the browser with Sculpt. So I want to start the

01:36 conversation with just each of you talking about your involvement in the project. I know you both

01:41 have done various things to keep it rolling and work on it day to day. So tell us about it. Albert,

01:47 you want to go first?

01:47 I started using Sculpt because of a very bad decision I made a few years ago. Eight years ago,

01:55 I think. We had the idea that we wanted to write cloud validation and server-side validation in the

02:01 same language, so we'd only have to write them once. And our backend at that point was in C Sharp,

02:07 and the frontend was in JavaScript. And the only thing we could run in both ends was Python.

02:14 So we ended up with Sculpt.

02:15 That's a funny path, right? I wouldn't think if you combine JavaScript and C Sharp that you end up

02:21 with Python.

02:21 Yeah. I wouldn't advise anybody to do this. It did put me in this position where we found Sculpt in this

02:30 slightly disheveled state because the original author had sort of left it. And we ran into problems,

02:36 and I started fixing them. And yeah, it slowly grows.

02:39 Yeah. Who was the original author? Was that Brad Miller?

02:41 No. Scott. I've forgotten his name.

02:44 Yeah. So Sculpt is not totally new. I was looking through some of the docs and stuff. I certainly

02:50 saw 2011 here and there. And that actually would put the timeframe almost exactly the timeframe that

02:56 you're talking about, Albert.

02:56 Yeah. The original author started off as this. He was really frustrated with JavaScript,

03:02 and he liked Python a lot. So he's like, how hard can you do it?

03:05 Famous last words.

03:06 Yeah. No, but he's like an amazing software engineer because he got such a long way. He

03:11 got the compiler and the parser and everything. And, you know, he got the sizable chunk working,

03:18 but then abandoned it. There was other stuff to do, probably. And we found it in that state,

03:23 and we just took it from there.

03:24 Great.

03:25 Ask your next question because I'm going to come in at the point of the story where I actually come in.

03:29 Yeah. I was going to say, so Albert, what's your relationship to the project today? I know that

03:33 you're doing a lot of like overseeing issues and merging PRs and things like that. Are you leading

03:39 the project or are you working with someone else who is?

03:41 The official leader is Brad Miller. Okay. He took the main ownership over, but two or three in the line

03:49 of the people I contributed most. And, you know, I feel this thing where if people do issues or pull

03:56 requests, I always feel obliged to act on them. So I do. Yeah. There's no official split of task here.

04:03 Sure. Sure. Marith, tell us about your involvement.

04:05 So I came to Sculpt a little bit later. It would have been, oh, I guess sometime around 2015.

04:11 So I came to Sculpt via Anvil, which if you haven't heard of it, it's a tool for building

04:17 full stack web apps with nothing but Python. So Python in the browser, Python on the server,

04:21 function calls from one to the other. It's all very nice, but obviously to achieve that vision,

04:26 you need to run Python in the web browser as well. So we launched out on a little Safari of Python

04:33 options for running Python in the web browser. And I was actually already familiar with Sculpt from

04:39 some educational work we had done as part of an outreach workshop at the University of Cambridge,

04:46 where my co-founder Ian and I did our PhDs. And so it was the closest tool to hand. Actually,

04:53 when we looked around, we realized it was in fact, the best tool for building a new way to drive web

04:59 environments with Python. Because as we'll probably discuss later, a lot of the other approaches,

05:03 they think very JavaScript-y, and Sculpt thinks very Python-y, and then makes whoever's embedding

05:10 it in the web page do the work, which is, as far as I'm concerned, the right way around.

05:14 Yeah, if you want to bring Python to the browser, right, it should be as Pythonic as possible. And then

05:19 then you make it work, right?

05:20 That's the idea. Yes. Well, that's certainly Sculpt's idea. And certainly Anvil's idea.

05:26 So I jumped in then, I sort of announced my arrival with a major pull request turning Sculpt's

05:35 fundamentally JavaScript-like model, which is to say that it had to execute all at once and then be

05:40 finished, into this asynchronous model where you could write blocking Python code, and then the

05:46 JavaScript runtime, it could sort of hand control back to the JavaScript runtime for a little bit. And then

05:50 when some asynchronous operation had completed, like going to the server for something or getting

05:54 some user entry, it could resume your Python code exactly where it was. And from there, I've become,

06:02 like Albert, one of the more active contributors on the project. And as Albert said, there isn't really

06:09 division of tasks. We all just jump in wherever it is that we see efforts in need of things. So I do a lot

06:17 of work on the compiler. I do sort of a cleanup of bugs that people find in Sculpt, typically while

06:25 using Anvil in advanced ways. And of course, the reason I'm here...

06:29 You're like, wait, that should work in Python, right? But it's not.

06:32 Yes, absolutely. You know, like any non-core Python implementation, there are going to be

06:37 divergence bugs where CPython does one thing and we do the other, and we need to run in and fix those.

06:42 And of course, most recently, Albert and I did the big upgrade of Sculpt from the Python 2.7

06:49 grammar to the Python 3.7 grammar, which opens the door to us moving to an actual Python 3 world in

06:56 Sculpt, getting in under the wire for the end of life for Python 2.

06:59 Yeah, beautiful. Yeah. So heck, you've got months to spare, at least one.

07:03 Days, whole days, Michael.

07:06 Whole days. It's so much time.

07:08 It's good, though.

07:09 Yeah, it's got to feel good because, yeah, it was 2.7 or even 2.6 for quite a while. So it's great to see

07:15 making progress.

07:16 Yeah.

07:16 That's awesome.

07:16 Updating the grammar to 2.7 was one of my first big projects in Python.

07:21 And that was only one step, and that took me, I think, a summer of coding.

07:26 Just looking at the way that Sculpt creates the JavaScript or the JavaScript stuff is implemented

07:33 for even something like a print hello world, there's like a lot of stuff going on in JavaScript

07:38 there that it's kind of got to set up the environment. So yeah, I can imagine changing and making those

07:43 changes took some work.

07:44 That question cuts to the core of one of the biggest design questions for every Python in

07:50 the browser implementation, which is essentially, are you trying to do the minimum possible to

07:57 allow you to write Python in a JavaScript world? And, you know, Transcript, for example, is an

08:06 example of a project that really does take that approach. It translates Python to JavaScript code that

08:11 looks very much like the Python code. And the price it pays for that is that it's somewhat loose on the

08:18 Python semantics. And the way you interact with the page is certainly not Pythonic at all, if you

08:23 want to do any IO.

08:24 Right.

08:25 And Sculpt is right the way at the other end of the spectrum, where you say, I don't care how much work

08:32 the JavaScript has to do around here, I am going to deliver a Python-y experience to the user and

08:39 allow them to be interactive and allow them to think about the outside world as a Python

08:44 programmer would, you know, as something you can print to, as opposed to something where you get

08:49 some document object and then get some HTML element, and then you do some translated DOM manipulation on

08:55 it and jump out a window.

08:56 Exactly, exactly. Like what? I was trying to avoid all this. Now I'm back, right?

08:59 At the beginning here, I do want to throw out something real quick for you, Marith, because

09:04 a lot of these attempts to do this kind of stuff, what I feel like it results in, and

09:10 you tell me if your experience is like this maybe, is it results in like a minimum proof

09:15 of concept feeling, you know, like, oh yeah, so I technically could do NumPy here in this

09:22 example, or I technically could do like this Python thing and Rust a little bit, but it's

09:27 actually anything real and interesting is kind of like beyond it, right? It kind of sounds like

09:31 you're describing that maybe with transcript a tiny bit. But the reason I bring this up

09:36 is your use case, we're using Sculpt with Anvil. Those are massive applications doing

09:41 complete end-to-end application Python, much of which I would say 80% of which is in the

09:48 front, in the browser. You're building single page applications with a UI with Python.

09:53 That's the point. So if you want to take a step back and ask if you're trying to put Python

10:00 in the front end, what exactly are you trying to accomplish? And sometimes, you know, somebody

10:07 might think, oh well, you know, I like Python, I want to hack around with a compiler, that's

10:11 fine, you know, I'm going to do this as a hobby. But if you want to actually use it, then you need

10:16 to know what it is you're trying to do. And especially Python people tend to be back-end

10:23 or data or sysadmins or systems programmers. We will look at the web and go, that is ridiculous.

10:31 Like the bar that you have to meet to build a full web application is way too high. To build an

10:37 application on the quote-unquote traditional stack, you need to know like HTML and JavaScript and CSS and

10:42 Python for the back-end and SQL for the database and then React and then Redux and then Webpack and then

10:46 Bootstrap and then SAS and I've run out of fingers to count on, but there's more.

10:50 And Nginx and Microwisgee and Ansible and...

10:54 Oh god, yes, make it stop. Right. And some people look at that and the most acute pain points they can

11:01 see are to do with the JavaScript ecosystem. They go, these JavaScript frameworks are out of control.

11:06 If we could only replace JavaScript with a nicer language, we would solve this problem.

11:12 And actually, I think that's missing the point slightly. I'm firmly convinced that the problem

11:17 with the web is not actually JavaScript. The problem with the web that makes it so difficult

11:22 to program is that there are so many layers of which JavaScript is just one. So if you take a typical

11:28 web application, right, your data is going to start as rows in a database. You're going to transform

11:33 those into objects, say Python objects in your server-side code. Then you're going to transform

11:38 those into JSON on HTTP endpoints with get, post, put, delete, silly, simple set of verbs.

11:43 And then you're going to transform those into JavaScript objects in the client. And then you're going to transform

11:48 that into HTML DOM and you're going to transform that into pixels with CSS. All of those layers come with a

11:54 big impedance mismatch and you grow all sorts of hairy frameworks, right?

11:58 Orms to turn database rows into Python objects are the least of your problems, right? It's the

12:04 JavaScript frameworks that are the biggest and hairiest of these translation layers. And so that's where

12:09 people go, oh, JavaScript must be the problem. But if you just swap JavaScript out for Python,

12:14 you haven't actually reduced the number of times you need to translate your data from

12:18 one representation into another, and you haven't reduced the complexity of your application. And I

12:23 think that's fundamentally what gives you that kind of proof of concept feeling about something like

12:28 transcript. Because you build some code with transcript and you go, yay, I've written some Python and it

12:32 runs in the web browser. But actually, to interact with the outside world, that Python has to do

12:40 things every bit as unpleasant as what your JavaScript would have had to do. And so you haven't actually

12:47 got yourself to the Pythonic nirvana that you were chasing. And obviously, on a large scale,

12:52 this is what we're trying to solve with Anvil, because we're trying to give you an environment

12:57 where you really can just write a Python function on the server and then just write some Python code on

13:01 the client and just call that function and just make some text appear on the screen by manipulating

13:06 a Python object. That's a very large full stack conception of it. But even in the small, I think

13:12 Sculpt has this one right as well. Because Sculpt is widely used outside Anvil. It's used in educational

13:19 environments. It's used in a game that you just showed us before this call. What was it, Code Combat?

13:26 Code Combat at CodeCombat.com.

13:28 Until we were prepping for this call, I didn't even know it used Sculpt. It's always great to find your code

13:32 being used in strange places like that. But it's used a lot in educational contexts.

13:37 If you're teaching someone, you can't afford to let them touch the JavaScript API because they will run

13:42 away screaming. You've got to give them a Python experience if you're teaching them.

13:45 And so those are the values with which Sculpt gets imbued from all directions.

13:50 If you look at Sculpt, Sculpt treats the browser as a platform to run things on it. And CPython treats

14:01 C and the operating system as a platform to run Python on. And from Sculpt, there's almost no way to touch

14:10 the environment. It's up to the person writing the extensions in JavaScript.

14:15 The integration layer, right? The person who says import Sculpt, import the Python, take the

14:21 Python code and bang them together to create app.

14:24 If you want to have something to happen in the browser, you will have to write some JavaScript

14:27 code and you will have to write that in a way that you can call it from Sculpt. And you can't,

14:31 there's no native stuff. We used to have eval in JS eval in Sculpt. I removed that a while ago because...

14:39 Thank you! That's good.

14:42 Well, it's actually a security risk because all these tools are running users' code and

14:48 storing that in databases. And it's better that they don't execute JavaScript that they write

14:54 themselves. That's probably true. It's generally true when it's straight JavaScript and if it's

14:59 embedded within a Python app, it's probably also true. There's a side security rant I could go on all

15:03 day about this. Part of this problem with having all these layers in the web stack is that what you get

15:08 is programming languages with the source code for others programming languages embedded in them,

15:12 right? What you typically ship a client is HTML with JavaScript embedded in it, which generates

15:18 actually more HTML sometimes with JavaScript embedded in it. And CSS embedded in that HTML inside the

15:23 JavaScript. And the JavaScript ecosystem is something where you could not remove the eval-like qualities

15:30 of it because it's baked into the whole system from top to bottom. And again, Sculpt has that luxury

15:36 because the browser is being treated like a runtime environment, not like something that should be

15:42 protruding into your living space.

15:43 This portion of Talk Python to me is brought to you by Linode. Are you looking for hosting that's fast,

15:50 simple, and incredibly affordable? Well, look past that bookstore and check out Linode at

15:54 talkpython.fm/linode. That's L-I-N-O-D-E. Plans start at just $5 a month for a dedicated server with a gig of RAM.

16:03 They have 10 data centers across the globe. So no matter where you are or where your users are,

16:07 there's a data center for you. Whether you want to run a Python web app, host a private Git server,

16:12 or just a file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network,

16:19 24/7 friendly support, even on holidays, and a seven day money back guarantee. Need a little help with

16:24 your infrastructure? They even offer professional services to help you with architecture, migrations,

16:29 and more. Do you want a dedicated server for free for the next four months? Just visit talkpython.fm/linode.

16:36 Now, before we get too far into this, I kind of want to do a survey of the other options. You've

16:41 mentioned Transcript and we've talked about Sculpt and there's some other ones. And I also want to ask

16:46 you the question, it probably is a slightly skewed audience here, does Python even belong in

16:55 the front end. Did you see Russell Keith McGee's, either of you, his talk about black swans at the

17:02 most recent PyCon 2019? We skimmed it very briefly before this recording, so not really.

17:07 I'll summarize because, you know, a ton of the listeners also won't have heard it. So basically,

17:12 he gave a talk, I think it was the opening keynote at PyCon 2019 in the US. And he said, look, Python is

17:19 great. We love Python, but there are real challenges that could threaten its great rise and super popularity,

17:27 which is wonderful for everybody involved in it. But what is the most popular type of computer these days?

17:34 It's a phone and a tablet. Does Python run there? No. If I'm a new developer and I want to have,

17:40 you know, some program I create and I want to share it with my friends, how do I package up a Python app

17:45 and share it? Right? If the answer is you pretty much, you know, it's super hard or you can't, then

17:51 maybe the choice is, well, I'll go write some other language. Right? And one of them that he said was,

17:56 if I need to learn JavaScript anyway to write web applications and I could do it in Node, why would

18:03 I bother learning Python if I'm just getting started anyway? Because I'm going to have to learn

18:07 JavaScript. So let me just learn one and go from there. So he was making the case that the lack of

18:13 Python in the browser, it could cause a serious sort of drain of the enthusiasm and newcomers to the

18:20 whole language. So what do you guys think? Python belong in the front end? I mean, obviously,

18:24 you're doing a lot of work to put it there. But where do you see this?

18:28 I have a rant. So, Albert, if you want to jump in first, you have about five seconds.

18:32 I, at the moment, can't advise a website to go right there front end in Python, unless you're

18:41 using Anvil. Sculpt won't be your friend because it will make you work really hard to do that.

18:47 Yeah. And this is more of a broader question, not is like today to answer, right?

18:52 Does it belong there? Yeah. I think eventually we will find a way to properly put it there,

18:59 but we aren't there yet. Okay. Meredith, you had something to say about this,

19:03 you indicated. I'm afraid, and this is where I have to tread very carefully because I'm on a Python

19:08 podcast, but I am not a Python partisan. We, I can hear the in-drawn breath, we picked up Python for

19:17 Anvil because it is the language of education. It is the world's first programming language for people

19:25 who are trying to teach new people to code because it is friendly, because it is easy to comprehend,

19:32 because it is easy to pick up. And the web, which is our target platform, is the very opposite of that

19:39 in so many ways. And we wanted to bring those virtues to the web. And as it happened, Python looked the

19:48 likeliest tool for us to pick up and try to ram through that barrier. I am not wedded to Python

19:54 being the choice of technology that produces this. It just seemed like the best shot for exactly what

19:59 we were doing at the time. I don't think Python has any God-given right to rule the development world.

20:05 I think it has to stand or fall on its own two feet and on its own merits. And I think we as a community

20:13 should be chagrined at the idea that a Pythonic experience is not available for web development.

20:21 That the values that Python is the torch bearer for in the programming language community aren't

20:28 available on so many of these platforms that are the popular development platforms.

20:33 Yeah. Python, the language itself is merely a delivery mechanism. And I don't want to get

20:38 tribal about whether that is the way to deliver the web. As it happens, it's the loose solution we've

20:43 chosen. But I don't think Python belongs on the web. I think Pythonic values belong on the web.

20:48 Very interesting. And like you said, just choosing, just replacing the syntax of JavaScript with the

20:54 syntax of Python might not necessarily make that difference, right? So let's also talk a little bit

21:01 about the history because I think it'll be interesting. There's some newcomers and some

21:07 projects that have been there a long time. So Sculpt has been around for a while, at least since 2011.

21:14 What are some, we talked about Transcript. What are some of the others? Either of you take it.

21:21 At this point, I have to plug a blog post written by my colleague, Sean Taylor Morgan, because he just gave

21:27 a talk at PyCon UK walking through exactly the answer to your question. So hopefully that link's going to be

21:33 appearing in the show notes. Okay.

21:35 But the broad swing of these things is it's a thing people have tried. There are a bunch of different

21:42 ones. I don't actually know the order of when they came up, but there is Sculpt, which we're talking about a lot.

21:49 There is Transcript, which is a Python to JavaScript compiler that produces JavaScript code that looks

21:56 very much like the Python code. So pretty concise, but at the cost of not exactly the right semantics.

22:01 It's also because it's compiled to JavaScript. You don't run the Python. In Sculpt,

22:19 you can use our very limited debugger to actually pause Python at a certain point and look at variables. And this debugger lives in the Python runtime on your

22:37 browser. And with Transcript, it doesn't run. It runs the JavaScript and you write Python.

22:45 Right, right. Yeah. So it seems like with Sculpt, looking at it, it basically creates a

22:50 little runtime environment. It creates the modules variables and it little switch to run all the code and things like that. And it does seem like it's creating

23:01 a little execution environment for your Python. And it just continues to run there. Yeah.

23:05 Brighton is exactly the same. I don't want to say that. Transcript is, I think,

23:10 is reasonably new and the guy's doing a great job. But he's making modern Python compilable to JavaScript. And Brighton is an older project, but does a similar job.

23:28 Yeah, there's a big difference there, of course, in that Transcript is ahead of time compiled to

23:32 JavaScript. Brighton is actually compiled in the browser. So Brighton is a project that lets you

23:37 write script tags like you write in your HTML script tags, script type equals text, JavaScript. You can

23:42 write script type equals text, Python and write Python code everywhere you'd run JavaScript. And then

23:49 there is a library that you load into your browser and it will then search through your document and

23:55 translate all of, translate the Python as the page loads. So it's, it's kind of this, it's a sort of

24:03 middle ground. It's not dynamic, but you couldn't do like an interactive write some code, hit enter and

24:09 run it thing with Brighton like you can with, with Sculpt. So I'd say like Brighton Transcript are both

24:19 sort of aimed at like, I would just like to do a straight swap out of my JavaScript for my Python

24:24 in this code. And Sculpt is actually in a different part of the design space next to projects like

24:31 PyPy.js and Pyodide, where you take a Python runtime and put it into the browser.

24:37 Okay, so there's PyPy.js. And I've covered that before on the show quite a while ago. My

24:43 understanding it could be outdated was that project is not really active anymore. Is that accurate? Do you

24:49 know? No, I actually worked on that. It isn't active anymore. Ryan from Mozilla started that and

24:57 I investigated it quite heavily because this gives you the whole of Python. This gives you like a

25:03 full reference implementation of Python in the browser. But compiling PyPy.js is something special.

25:11 I've never tried it, but it's awesome. But it turns out it's like 12 to 15 megabytes of very,

25:19 very, very dense ASM.js that outputs it. Yeah. Yeah, it takes a few seconds to put a browser to understand.

25:25 So it's the PyPy, P-Y-P-Y comes from the PyPy project, which is the compiled version alternative to

25:33 CPython, right? So it basically, as you said, the ASM.js bit is, well, let's take that C code and compile

25:39 that to JavaScript and then just download it, which is pretty large.

25:44 It's even more fun than that. So PyPy is a Python interpreter that's written in Python,

25:49 which itself feels like a little bit of a contradiction. Because if you had a Python

25:54 interpreter written in Python, wouldn't you need another interpreter to interpret it? And then you'd

25:57 just be like double stacking. But what it's actually, how PyPy is actually done is that it's written in a

26:03 subset of Python called RPython, which can be translated effectively to machine code. And so there is an

26:10 RPython to native code compiler.

26:14 It's actually RPython compiles to C and not to native.

26:18 And then that compiles to native. Yeah.

26:20 So, okay, C and then to thing. And then you stick the C code in through in script.

26:26 But PyPyJS, you can actually run, you can actually compile the JIT compiler. So what you get is you

26:34 write Python in your browser, and then PyPyJS interprets that. And it jits C code to the

26:42 ASM C code jitter that jits that. And that jits to the JavaScript. And the JavaScript is also,

26:49 of course, a JIT environment. Yeah.

26:51 It's like this two stage rocket every time you press run.

26:55 It's a magnificent engineering achievement, but it's like getting an elephant to fly. The most

27:00 impressive thing is that you did it. Yeah.

27:02 Yeah. No. And it's actually, it's faster than CPython.

27:05 PyPy.js is faster than CPython.

27:08 Yes.

27:08 Oh, Lordy. Right. Okay. Yes.

27:11 Well, that's because PyPyJS, if you've ever run PyPy on your machine compared to CPython,

27:17 PyPy is massively faster. So it's so much faster that even compiled to JavaScript, it's a little

27:23 bit faster than CPython. But the problem is that you never notice that performance is a performance

27:29 gain with PyPyJS because it's a 15 megabyte JavaScript download. And then the browser takes

27:36 a synchronous process to read all that JavaScript. That to me sounds like the weak point of PyPyJS is

27:44 you've now given the browser this huge amount of source code to go jitting and processing in and of

27:51 itself. My experience with PyPy has been like small stuff is fast, but I tried to get my websites to run

27:57 under and it was actually slower. I don't know. There must've been something going on there. Anyway,

28:02 that was a little bit older and that's in a hibernation. And then-

28:05 Well, because Mozilla have moved on to Pyodide, which is a much more sensible implementation. The

28:10 same thing for the modern web.

28:11 Yeah. Well, tell us about Pyodide. I mean, I covered it actually not long ago,

28:14 but not everyone's heard that episode.

28:16 Right. Well, in which case I'm going to tread very carefully because I will be much less expert than your

28:21 previous guest, but it's a full CPython implementation with a whole bunch of common data science native

28:30 libraries that include native code like NumPy and Pandas all compiled to WebAssembly.

28:36 So it's really impressive to use. It's like part of the iodide project, which is just kind of like a

28:41 Jupyter notebook, except all executing your browser, not having to go back to a server.

28:46 And again, if you load up the sample page and run a few lines of Python code,

28:51 there will be this period of grunting and straining while your computer downloads this blob of WebAssembly

28:58 that is the compiled CPython in WebAssembly with all these libraries attached.

29:05 But once it then gets up and running, then you have this amazing data manipulation environment

29:11 right in your browser and you can do things like using NumPy right in your browser. And that's the

29:16 only Python in the browser technology that can pull that trick off.

29:19 It is pretty impressive. And I definitely think in this use case, if you're going to bundle up the C code,

29:24 bundling it to WebAssembly is a way better place to bundle it than to bundle it to JavaScript, which is

29:29 then turned around and like, it's like shipping source versus shipping the app.

29:33 You know, it's just so much easier to run it that way.

29:35 But parsing WebAssembly is so much easier than parsing JavaScript.

29:41 Right. It's meant for machines to read. Yeah.

29:43 Not for humans. No.

29:44 No.

29:45 Even though some JavaScript gets pretty obfuscated, but still.

29:49 It's not reading characters and parsing it as a abstract syntax tree probably.

29:53 So yeah, this is an interesting project. I don't know where it's going to go.

29:57 I think in order for this type of thing to work, probably there's two things that need to happen.

30:02 One, we need really good CDN support so that you get the WebAssembly CPython once ever,

30:09 and then it's just from cache or something like that.

30:14 The other is a smaller CPython. Do you need to ship the whole standard library and all these things?

30:19 Like, is there a way to have smaller Python that you can then embed?

30:23 Right.

30:24 Certainly, you're not going to run an e-commerce site off that WebAssembly Python interpreter. It's just got too much startup latency.

30:30 Yeah, absolutely.

30:32 The future of a CDN global Python interpreter that people can rely on being fast because everyone will have loaded it once.

30:39 It's a very attractive future, but it's a long way away from now.

30:43 The fact that Mozilla is making this stuff means that there are definitely people at Mozilla thinking about this very hard.

30:51 So it's definitely, I don't think it's impossible, very likely even, that it will happen.

30:57 Oh yeah, and we'll be sitting there waving pom-poms when it happens.

31:00 Yeah, that would be cool. To be honest, like what I would rather see than a CDN is Mozilla ship the WebAssembly binary with Firefox and have Chrome ship the same thing, you know, Python 3.7 or 3.8 or whatever, and just update it.

31:15 Browsers update frequently. Just update that on release.

31:18 That would be awesome, but I think that they would have to, they're probably not going to pick winners like that.

31:23 You know, we as a community would have to demonstrate that that would be grabbed with both hands before we can persuade a big browser platform like that to ship it.

31:32 Of course, they did it with JavaScript, right?

31:34 So, I mean, there was no other choice, but they do ship a JavaScript runtime in there.

31:38 I think that's more than enough on the alternatives, and we'll probably hear from folks.

31:43 They can put messages in the comments on the show page like, oh, did you hear about some name that I can't even imagine, a project that I didn't know about, right?

31:51 So, check that out as well.

31:52 I feel like we've done a pretty good job of covering Sculpt and its positioning in terms of its features and things like that and sort of compare and contrast.

32:02 Maybe the next thing that we could talk about is how do I get started?

32:06 So, I'm a web developer.

32:08 I want to do something with Python.

32:12 I'm going to choose Sculpt to do it.

32:13 Maybe a couple of things.

32:15 What are the use cases where that makes sense?

32:18 And then what are the steps to get started?

32:20 So, I'd say by far the most common use case is if you're building an application where you want your user to write Python.

32:27 So, Anvil is an obvious example here.

32:30 But there's also something called Trinket for whom Albert's done some work, which is a nice education-focused environment where you can, you know, bring up, write some Python code, you know, do a turtle, draw some graphics, and have that just run.

32:44 So, for them, something like Sculpt was an easy choice because they could edit in the browser, just run it right there in the browser.

32:50 Things like CodeCompat.

32:52 Yeah.

32:52 Trinket is really nice.

32:54 You get here and it gives you like a wonderful little editor with autocomplete and it gives you a canvas or whatever.

33:01 Oh, do they have autocomplete now?

33:03 Hurrah!

33:03 I'm pretty sure they did.

33:04 Let me double-check that before I...

33:06 No, no, they have.

33:07 It's based on Jedi.

33:08 Yeah, yeah, it's all there.

33:09 It's super nice.

33:10 It even goes object dot thing and it even autocompletes that.

33:14 It's really nice.

33:15 It's not just autocompleting the characters.

33:16 If you want to see a proper autocomplete implementation with Sculpt, you do have to look at Anvil, though.

33:21 Yes, of course.

33:23 What Trinket does is they send your Python to the server and then let Jedi look at it.

33:31 And Jedi gives you then the list of completions and then we set up.

33:35 I see.

33:36 So they remote out the autocomplete.

33:38 Yes.

33:38 Okay.

33:39 And the problem with that is, of course, if you're doing high-velocity typing, you have the latency of you to the server to back.

33:44 And that is going to seriously cramp your style if you're writing code in a hurry.

33:48 So the Anvil autocompletor is actually built on top of Sculpt.

33:52 We grabbed the Sculpt like parser and compiler.

33:55 And so what we do is if you hit tab in Anvil, we replace your cursor with like a random symbol.

34:00 And then we parse your module into an abstract syntax tree and then walk over it in JavaScript in the web browser.

34:08 And then by the time we've walked down through several modules, you know, noticing all the variables that are in scope along the way,

34:14 by the time we hit that magic symbol that represents your cursor, we know what's in scope.

34:18 And then we know what we can offer for autocomplete.

34:20 That's super cool.

34:21 Having a compiler that is easy to start hacking around with and that exposes like primitives, like the abstract syntax tree and like the parser in the browser is a really great tool if you want to start messing around with compilers.

34:36 Again, if you want to start building things, to go back to your original question, what would be the best use of Sculpt?

34:43 Really, it's if you're developing something where you want someone to be writing Python as part of using the thing you're building.

34:49 Yeah, so Anvil is a real good example because you're a development environment to run the result of that on your own custom cloud.

34:57 Trinket is nice because Trinket is a pretty cool IDE, not IDE, editor in the browser.

35:03 It's got some IDE features and sort of a visual output component.

35:06 You had started to mention code combat as well, I think.

35:08 Yeah, and again, that's, I mean, you only showed it to us shortly before this call.

35:13 But this idea that, you know, you write some Python code and then it runs interactively as your characters do things.

35:20 Again, Sculpt was a really good fit for that because writing code into this thing is how you use it.

35:26 Yeah, exactly. The way you play the game is you fill out, it says you're in this dungeon, you need this character to navigate the maze and then build a fence to keep the creatures out or whatever.

35:36 And so you write that out in code with little bits of autocomplete and it just runs that Python to see if you won the game or not or won the level.

35:43 This portion of Talk Python to Me is brought to you by Tidelift.

35:48 Tidelift is the first managed open source subscription, giving you commercial support and maintenance for the open source dependencies.

35:55 You use to build your applications.

35:57 And with Tidelift, you not only get more dependable software, but you pay the maintainers of the exact packages you're using, which means your software will keep getting better.

36:06 The Tidelift subscription covers millions of open source projects across Python, JavaScript, Java, PHP, Ruby, .NET, and more.

36:13 And the subscription includes security updates, licensing, verification, and indemnification, maintenance and code improvements, package selection and version guidance, roadmap input, and tooling and cloud integration.

36:26 The bottom line is you get the capabilities you'd expect and require from commercial software.

36:31 Yeah, so that's a good example.

36:40 Yeah, so that's a good example.

36:42 What else is out there?

36:43 The uses of Sculpt prove pretty much that it is very much in this interactive sphere.

36:50 My original project where I did the client-side validation is actually where we run Python in a much more sort of JavaScript-y way.

36:59 But again, Sculpt is not meant for that because it just makes you work way too hard to get stuff done.

37:05 Right.

37:05 So it's probably not a great use case to say, I'm doing AngularJS and that's all great, but I actually want these functions instead written in Python because I just can't bear to do them in JavaScript.

37:16 Yeah.

37:18 Get yourself a transcript for that as quickly as possible.

37:20 It will be great.

37:21 Probably.

37:22 Yeah.

37:22 Anvil is much more used for things like Anvil and Trinket, Code Combat.

37:27 There's a bunch of online courses.

37:29 So there's a couple of MOOCs that use Anvil.

37:33 Some of the other contributors are people who run university courses or build online courses and interactive textbooks with Anvil.

37:42 Okay, cool.

37:43 Yeah, we'll link to some of those in the show notes.

37:44 Yeah, so I think, Meredith, you hit a really...

37:47 It's really clearly on the head saying that the use case is if you need people to create Python as part of using your project.

37:56 And every one of the examples that we've seen so far is one of those.

38:00 Maybe somebody else has done something out there with it that you don't do that and it's not obvious because you're not typing Python.

38:06 You're just running an app.

38:08 I don't know, but who knows?

38:10 So it sounds like the project is pretty good.

38:13 And certainly of all these use cases, I would say Anvil is the most holistic.

38:19 And that's the reason I called it out because you're building entire app ecosystems with this.

38:25 Also, Code Combat is a pretty rich app where it's something kind of amazing.

38:30 But maybe we could talk about the limitations of what people should be aware of in trying to use it.

38:37 The biggest ones we've talked about already, which is that, you know, if you're going to be integrating it into a web application where the rest of it is built using HTML and JavaScript and frameworks and so on,

38:47 you're going to be doing a lot of work to expose those into your Python runtime.

38:52 So it's not good for like, you know, quick integratings of bits of Python into traditional development.

38:59 Obviously, none of the packages that require C like NumPy, you're going to be able to do in Sculpt because it's in JavaScript.

39:05 We get the occasional question on the issues like, oh, I tried to import C strings or C string IO.

39:13 And I was like, yeah, it's not going to work.

39:16 Sorry, that's not going to work.

39:17 So I ported string IO.

39:19 And I think I'm from the pure Python implementation.

39:22 But and there's like so many stuff that Python is known for, right?

39:27 Oh, I want to parse in CVS or I want to parse CSV or I want to do this thing.

39:32 And it's like, no, sorry, that's all written in C.

39:35 Not going to happen.

39:36 So is it not going to happen because it's a lot of work and you guys can't get to it?

39:41 Or is it not going to happen because it doesn't make sense to happen, right?

39:44 So if someone's out there and they really want the CSV package module to be part of it, like could they drop in to source slash lib and add a .csv?

39:54 Yeah, yeah.

39:54 Or csv.py or whatever?

39:56 Yeah, 100%.

39:58 And a lot of the, this is so many times my answer on the issues.

40:03 Like, you know, if you really need it, like I will help you and explain where stuff fits in and how you should write, you know, external modules.

40:11 There's some help files around that as well.

40:14 But it's just where for active developers, maybe five, there's just no time for us to spend on stuff like that.

40:25 And there's also, I mean, depends on their motivation, right?

40:28 If, you know, some of those developers are in education and they're not trying, they're not focusing on like the NumPy use case.

40:34 And of course, with Anvil, our answer to that question is always, well, that's okay.

40:38 The server side stuff is just a function call away.

40:40 So go do your deep numerical processing on the server and make one function call and do it.

40:46 So, yeah, there's not a lot of pressure.

40:48 Yeah.

40:49 When somebody desperately needs a thing, it tends to materialize.

40:52 Way back in early in my contribution to Sculpt, Sculpt acquired a working Datetime module because we needed it.

40:58 And so we pulled over the pure Python implementation from PyPy, actually.

41:03 Yeah.

41:03 I was thinking about PyPy.

41:05 How much of the stuff could just be sort of brought over from that world?

41:08 A remarkable amount, but quite often it turns out that it's using, so that was a thing for

41:13 with Datetime.

41:14 I ended up fixing up bits of the compiler because of the slightly, some of the slightly exotic

41:19 things that PyPy's implementation of Datetime was using.

41:21 Okay.

41:21 Sculpt is the best example of this 80-20 rule.

41:26 Due to sort of sheer number of people trying stuff, we've built this 20% that 80% of the

41:35 people use.

41:35 But as soon as you use anything from the standard labor, as soon as you let a seriously senior

41:43 Python engineer touch Sculpt, like line three, they'll be like, hey, why doesn't this work?

41:48 We're like, yes.

41:49 Well, let me tell you about this.

41:52 It's a very long story why it doesn't work.

41:56 From personal experience, I'd said that the senior Python engineer problem has got noticeably

42:01 better over the time that we've been involved with Sculpt, which is probably not coincidental,

42:06 given that that's a demographic and will attract slightly more than Sculpt's other users.

42:10 But yeah, you'll usually find in any, if you're porting any given thing from the standard library,

42:16 you'll usually find some corner case in the compiler you need to fix up.

42:19 But you know, for some of us, that's our idea of a fun weekend.

42:22 That's right.

42:22 Guess what case I added this weekend.

42:24 No, that's pretty cool.

42:26 So it does sound like if people really wanted to, there's a lot of organization and at least

42:33 willing to accept people adding more Python standard library support if people wanted to write it.

42:40 Oh, absolutely.

42:40 Bring it on.

42:41 More contributors are always welcome.

42:44 Yeah, yeah.

42:44 So you guys take PRs and all that, huh?

42:46 Yes, indeed.

42:46 You'll most likely find Albert or possibly me commenting on it.

42:50 Yeah, super.

42:50 Yeah.

42:51 And I also operate on the thing that as long as it doesn't break the tests and add functionality,

42:57 there's a high likely that I will merge it.

43:00 Because a lot of times I'm of the opinion it's better in than out.

43:04 And like if it's part of Sculpt, people will start using it.

43:07 And if there are problems with it, we'll find them and fix them later on.

43:10 Sure.

43:10 So let me ask you a quick question about that.

43:12 If I suppose I want to have the JSON module in there.

43:18 And I think right now, the JSON module inside there says something to the effect of this empty module is here to throw an exception if you try to import JSON or something like that.

43:28 Yeah.

43:29 This empty package.

43:30 Yeah.

43:30 Yeah.

43:30 That's what it does.

43:31 And that's actually an improvement, right?

43:33 Because now instead of just going, we don't know what JSON is when you try to import it, it goes, actually, JSON is not implemented, right?

43:39 Yeah.

43:40 Suppose I want to go and write that.

43:43 Do I write Python code or do I write JavaScript code?

43:47 Or do I write combinations thereof?

43:49 Like what skill set do I need to make that happen?

43:51 The choice is yours.

43:52 You can add things to the Sculpt standard library either with a .py file or a .js file or with a .py file that imports a module from .js.

44:03 Again, it's very much like Python with native C modules.

44:07 It's the same principle.

44:08 Obviously, writing it in .js is an awful lot more verbose.

44:11 But if you were doing JSON, that would probably be the way forward because you could grab all of the built-in JSON support in the browser.

44:18 The first two letters are about JavaScript.

44:20 Yeah.

44:21 In JSON, right?

44:22 Yeah.

44:23 So that would be the place to do it.

44:24 Okay.

44:24 Good to know, though.

44:25 Go ahead, Albert.

44:25 There is actually a JSON implementation for Sculpt.

44:28 It's just not in the standard lib.

44:30 Oh, okay.

44:30 I see.

44:31 There's somebody that did it.

44:33 I have somebody at Trinket that has it.

44:35 This is the eternal problem of open source tools and people that develop it.

44:40 There's never enough time.

44:42 This is probably several lists of things that I have to do for Sculpt.

44:47 And this is definitely on one of those lists.

44:49 But I never import JSON in Sculpt.

44:53 Yeah.

44:53 So I never run into this.

44:55 I always forget to add it, but we should.

44:57 Oh, please do.

44:58 Yes.

44:58 We have users who'd be made happy by that.

45:00 Okay.

45:01 I've made a note to bug you after this call.

45:02 Give me that implementation.

45:04 Correct.

45:05 Yeah.

45:06 Okay.

45:06 It sounds really interesting.

45:08 I do have one other question.

45:10 I'll contribute really quick.

45:11 How precisely 100% CPython compatible does something have to be before you're willing to accept it?

45:18 Could it be some subset, like if I implemented JSON, but it only did some of the things that's in the standard library?

45:25 Would that be okay?

45:26 Or does it have to be all or nothing?

45:28 Right?

45:29 Like every possible use case of CPython has to be accepted?

45:33 Or what are your thoughts around that?

45:34 I'll have said it better in than out.

45:36 Because if that thing is accepted with stubs for the things that don't work, then it's much more likely to get fixed up than if we stood on a molehill of purity and said, no, not unless it's complete.

45:48 It's like, fine.

45:49 I've got to go up my life.

45:50 There is a caveat to that, though.

45:51 If you're adding to the compiler, we will usually say this is not how it works in CPython.

45:59 So we shouldn't introduce this.

46:02 And this is because we have a few of those things in Sculpt.

46:06 And maybe for Anvil, it's not such a big problem.

46:10 But I know I think for Anvil, it is a big problem.

46:13 Oh, yeah.

46:14 If you have a user that uses it, you're maintaining this wrong implementation of CPython forever.

46:20 Yeah, yeah.

46:20 I was thinking more of like at the module level and not at the language compiler level, sure.

46:25 At the grammar level, we are very strict.

46:28 And we actually use the grammar definitions from the real CPython just imported in to drive the Sculpt parser.

46:38 At the compiler level, work very hard to be a strict subset.

46:42 And there may be some things we don't support.

46:45 But like, for example, we're in the middle of our Python 3 move and we don't have async yet.

46:50 You know, it will syntax error out if you try and do that.

46:52 But everything we do support in the compiler is, to the best of our ability, a strict subset of CPython.

46:59 All right.

47:00 Perfect.

47:00 Yeah.

47:00 Let's maybe round this out with two quick topics on Sculpt here.

47:05 So you started by talking about adding Python 3.7.3 support, which is great.

47:11 That's one of the major new things.

47:13 What are the other new things that are maybe worth highlighting real quick?

47:16 One of the really interesting things about the Python 3 grammar migration,

47:20 is that Sculpt does not have enough developer resources to fork ourselves into a Python 3 and Python 2 version.

47:28 And thanks to projects like Anvil and Trinket and all the others, we have a ton of Python 2 code in production.

47:37 Right?

47:38 Right.

47:38 Anvil's users have written a bunch of Python 2 code in the browser.

47:43 They've written the only code they could at the time, and it was Python 2, right?

47:46 And on the day we upgrade, they are quite reasonably going to wake up and expect their code to work as normal.

47:51 And so one of the biggest challenges of this Python 3 migration was that we actually did it while keeping compatibility with the Python 2 stuff that we already supported.

48:04 And we did this with bits of old grammar imported.

48:08 So there is a mode where it will accept the print statement rather than just the print function and that kind of thing.

48:15 And there's switches coming through the standard library for, you know, am I behaving like Python 2 or am I behaving like Python 3?

48:21 And that's one of the things about this migration that I'm most proud of, because it allowed us to move to a place where we can start, you know, moving forwards and filling out the standard library and keeping up with the fact that it's 2019 without breaking all the code that's already in production.

48:39 Yeah, that's super. And you've heard that from other projects as well, like NumPy dropping Python 2 support, Django dropping Python 2 support.

48:47 It's like now we're free to work on going forward and not double implementing everything.

48:52 Yeah, I guess we're still a generation behind that. We're at the point where we want to add Python. We need Python 3 compatibility, but we can't let go of our Python 2 users yet.

49:02 Not yet, yeah.

49:03 And the pain that they went through is what, you know, we will be maintaining parallel implementations of a bunch of the standard library.

49:09 And, you know, a whole bunch of flags in the compiler for some time yet.

49:12 And that is pain that was inevitable from the moment the Python 3 non-backwards compatible announcement was made, that every project that's supporting this is in some way, shape or form going to have to go through this caught between two stools moment.

49:27 But speaking of so much better than the alternative.

49:31 Yeah, absolutely. I mean, it's extra tricky for you because your platform runs their code.

49:36 It's not like, well, you just leave Python 2 on your server and you just run your Python 2 stuff there.

49:42 Nobody's going to touch your server.

49:44 But with Anvil, someone's going to touch your server because it's your job to make it run and update it and things like that.

49:50 Right. So this is challenging on your end.

49:53 Certainly, we were the most vocal people going for this compatibility approach.

49:57 But, I mean, people like Trinket, again, right?

49:59 Definitely. For Trinket, it was not an option to have two sculpts and load two of them.

50:07 Like one for new Trinket and one for old Trinkets.

50:10 That was never an option.

50:14 So from their perspective, it was like, if we're ever going to move to Python 3, it has to be in the same code base.

50:23 And that's a consequence of the way the sculpt is built, right?

50:25 Because the way you interact, you build the environment that your user's Python code can interact with,

50:32 means that the JavaScript form support that makes that happen has to talk to sculpt.

50:37 And it has to talk to pieces of sculpt APIs that will evolve as sculpt evolves.

50:43 And so if you tried to interact with some sculpt two fork and sculpt three at the same time,

50:49 you would rapidly lose your marbles.

50:51 So, yeah, for all these projects that have, you know, yes, sure, there are commercial people expecting the code behind their products,

50:59 shipping lots of money to still work tomorrow morning.

51:01 But equally with Trinket, right, there are a whole bunch of teachers and kids

51:04 expecting the thing that worked yesterday to work tomorrow.

51:06 Right. And maybe even textbooks with printed stuff that is super hard to update.

51:10 Yeah.

51:11 That says, go here and type this into that website and it'll work.

51:14 And it's our responsibility as platform maintainers to ease the passage.

51:17 Yeah, for sure.

51:18 All right. Final topic.

51:19 And Meredith, you know, I've spoken about this and some of the stuff here is a little surprising to me

51:24 or I didn't realize it or whatever.

51:25 So I think it's interesting.

51:27 But I'll give you the first word on this.

51:29 It seems to me like a lot of the energy around some of the stuff we talked about.

51:34 Pyodide is in the WebAssembly space.

51:36 And certainly any of the ASM.js and Scriptum solutions should go down the WebAssembly direction.

51:44 But what about Sculpt?

51:45 Does it make sense to have a WebAssembly version of Sculpt?

51:49 Is that something you all are thinking about?

51:51 What's the story there?

51:52 I don't think that we would write the compiler in WebAssembly or make a compiler that compiles a compiler in WebAssembly.

52:01 So what might happen is that we might support, you know, libraries that are written in WebAssembly

52:09 or some of like the big switch statement that Sculpt produces might be in WebAssembly.

52:17 But the biggest problems there is that the interop between JavaScript and WebAssembly is,

52:24 from what I understand, mostly via post message.

52:27 So very, yeah, very slow, slow.

52:29 Not in Sculpt world, nothing is slow quickly.

52:33 So Sculpt is quite slow by itself.

52:37 No, it's not the problem that it's slow.

52:38 The problem is that Sculpt requires that switch statement to be pretty synchronous.

52:43 And so waiting for a function call that would, you know, you would have to put that in suspensions.

52:50 I don't see there's no obvious path for Sculpt to move to WebAssembly, although given enough time and it might happen,

52:59 stuff might happen in that space.

53:01 But I sooner see it as external libraries being written in WebAssembly.

53:06 Okay.

53:07 I think that's exactly right.

53:09 For as long as you have to, like, use a knife and fork and oven gloves to communicate between WebAssembly and JavaScript,

53:16 then it's going to not make a lot of sense for something like Sculpt to be in WebAssembly.

53:24 But the idea of native libraries is very appealing.

53:27 And there are, again, Mozilla taking the lead on a lot of this, there are a whole bunch of rumblings about improving the interop story between WebAssembly and JavaScript.

53:38 And if that arrives further down the line, then it could start to make more sense for us.

53:43 It would be an interesting development around the core hot loop of, you know, process each bytecode.

53:50 And also, it might be a way to bring in the C libraries, right?

53:54 You could ship that as a WebAssembly instead of a C implementation, for example.

53:58 Yeah, exactly.

53:59 Okay.

54:00 Yeah.

54:00 Honestly, it was surprising to me when we first spoke, right, what I was referring to,

54:04 is that the interop was so limited between WebAssembly and JavaScript.

54:07 I figure, like, it's probably just passing a pointer.

54:10 It's all the same, right?

54:11 Kind of like PyObject pointers or whatever, right?

54:14 I guess not.

54:15 I think the hype about, I think there's, the WebAssembly is clearly, right,

54:19 that is the opening of the door to browser-side runtimes that are not shackled to the JavaScript

54:26 way of doing things, by which I don't just mean JavaScript the language, but I mean that

54:29 whole stack I was ranting about earlier.

54:31 And there's a whole bunch of people who see the light behind that door and are getting very

54:37 excited.

54:38 But the door is not all the way open yet.

54:40 There's still a lot you have to do and a lot you would have to do to deploy, really,

54:45 any non-JavaScript-shaped thing into the browser in a way that's not like a native game engine.

54:53 Sure.

54:53 Right.

54:54 Where it's entirely contained within WebAssembly, right?

54:57 Something like that.

54:58 Something like Anvil is, like, 90% interop, right?

55:00 The reason you're writing that Python code in the browser is to drive visual elements on

55:06 the browser.

55:06 And so, actually, I would be unsurprised if, you know, even if we put in all that enormous

55:13 amount of work in the current state of things, it wouldn't necessarily even improve performance.

55:17 But that stuff is coming, and I think the world is moving in the right direction.

55:22 We just have to hang on.

55:23 Yeah, sounds good.

55:23 All right.

55:24 Well, thanks for that.

55:24 Okay.

55:25 I think we've probably used up all the time that we have to talk about Sculpt and this Python

55:30 in the browser world.

55:32 Well, let me ask you really quickly here, each of you, the two questions at the end of

55:36 the show I always ask.

55:37 Albert, we'll go with you first.

55:38 If you're going to write some Python code, what editor do you use?

55:41 PyCharm.

55:42 PyCharm.

55:42 Right on.

55:42 These days, of course, a lot of the time I use Anvil's built-in editor, but PyCharm is

55:47 still the gold standard, right?

55:49 It's, you know, when I'm writing my autocomputer, it's their autocomputer I have my enemies eyes

55:52 on.

55:53 How does it work over here?

55:55 Dang, that's nice.

55:55 All right, let's do that.

55:56 I agree.

55:57 Cool.

55:58 Cool.

55:58 And then reverse order, notable PyPI package that maybe folks don't know about, but you've

56:05 ran across.

56:05 You're like, this is amazing.

56:06 I should tell people about package X.

56:08 Right?

56:09 Postal.

56:09 Like, just transforming user input into valid postal addresses for basically anywhere on

56:16 Earth.

56:16 It's one of those things that the task that will drive you wild, except you can just pip install

56:22 it and then somebody has solved this whole scary problem for you.

56:25 It's awesome.

56:26 It downloads enormous quantities of data, but it's awesome.

56:30 Python bindings for lib postal for fast international address parsing and normalization.

56:35 Oh, it sounds great.

56:36 Albert?

56:36 I'm going to falter on this question, to be brutally honest, because I've not been a Python

56:42 developer for as long as I've been a Sculpt developer.

56:44 I kind of went the wrong way around.

56:47 I started as a JavaScript developer and then learned Python because of Sculpt.

56:52 Well, I think that's like kind of the reality of it, right?

56:55 Like you think of the core developers as being super Python developers, and they are, but

57:00 a lot of their day to day, I think, is to write C code, you know, to make Python go.

57:05 And for you, it's you've got to write JavaScript to make Sculpt go, right?

57:08 Well, my day job is actually in Python.

57:10 I pip install and all this stuff, but I don't pick packages that often.

57:13 So I don't have any interesting new packages to display.

57:17 I'll throw one out for you that people might not know about.

57:19 HTTPX.

57:21 Have either of you heard of that one?

57:22 Oh, well.

57:22 So you may have heard of something called Request.

57:25 You've heard of that, right?

57:25 Uh-huh.

57:27 Yeah, everyone has.

57:28 So this is a 100% API compatible thing with Request, but it adds on HTTP2 support.

57:37 It adds on async and await support.

57:40 It has some cool intermediate like background parallel work for like doing a whole bunch of

57:45 like requests and stuff.

57:47 There's a bunch of sort of modern HTTP support on top of the Request API.

57:52 Sweet.

57:53 Yeah, it's pretty cool.

57:54 That's a good one.

57:55 I love the async and await stuff.

57:56 I can't wait to add that to Sculpt.

58:00 Yeah.

58:01 That'll be super.

58:02 Yeah.

58:03 One of the wonderful things about opening that grammar thing.

58:05 Now, all we need to do is just get that into the compiler and we have the technology.

58:09 I am so excited for what happens next.

58:11 That's super cool.

58:12 And I think async and await pairs super well with JavaScript anyway.

58:15 And I think it's even coming to the new version of JavaScript if it's not already here.

58:19 Yeah, it is.

58:20 Definitely.

58:20 Sweet.

58:21 All right.

58:21 Thank you all for being here.

58:23 I'm going to give you one more chance for a final call to action.

58:26 People want to get involved with Sculpt.

58:27 Either contribute to it, use it.

58:28 What do you guys say?

58:30 What should they do?

58:30 Come find us on GitHub.

58:31 Sculpt.

58:32 S-K-U-L-P-T.

58:34 All right.

58:35 Super.

58:35 Albert?

58:35 Yeah, I don't have much to add to that.

58:37 You know, try it on the website, sculpt.org.

58:40 Super.

58:40 All right.

58:41 Well, thank you both for being here.

58:42 It's great to chat with you.

58:43 All right.

58:43 Bye-bye.

58:44 This has been another episode of Talk Python to Me.

58:48 Our guests on this episode were Meredith Loof and Albert Jan Nyberg.

58:52 And it's been brought to you by Linode and Tidelift.

58:55 Linode is your go-to hosting for whatever you're building with Python.

58:59 Get four months free at talkpython.fm/linode.

59:03 That's L-I-N-O-D-E.

59:05 If you run an open source project, Tidelift wants to help you get paid for keeping it going strong.

59:10 Just visit talkpython.fm/Tidelift, search for your package, and get started today.

59:16 Want to level up your Python?

59:18 If you're just getting started, try my Python Jumpstart by Building 10 Apps course.

59:23 Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.

59:31 And of course, if you're interested in more than one of these, be sure to check out our Everything Bundle.

59:36 It's like a subscription that never expires.

59:38 Be sure to subscribe to the show.

59:40 Open your favorite podcatcher and search for Python.

59:42 We should be right at the top.

59:43 You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.

59:52 This is your host, Michael Kennedy.

59:54 Thanks so much for listening.

59:56 I really appreciate it.

59:57 Now get out there and write some Python code.

59:59 I'll see you next time.