« Return to show page
Transcript for Episode #235:
Python in your Browser with Skulpt
01:08 Panelists: Hello, great to be here. Hi, thank you.
01:10 Michael Kennedy: Yeah, it's great to have you both and Meredydd, welcome back. We talked about your cool project, Anvil, about two years ago, wasn't it, on the show?
01:18 Panelists: Gosh, yeah, November 2017, feels like a lifetime ago.
01:21 Michael Kennedy: Yeah, in Anvil years.
01:22 Panelists: Oh yes, well start-up time operates, it's like dog years only more intense.
01:25 Michael Kennedy: Yeah, yeah, absolutely. And nice to have you here, Albert. So I kind of wanted to start the conversation here. We're going to talk about Python in a browser with Skulpt. I want to start the conversation with just each of you talking about your involvement in the project, I know you both have done various things to keep it rolling and work on it day to day, so tell us about it. Albert. you want to go first?
02:22 Panelists: Yeah, I wouldn't advise anybody to do this. It had put me in this position where we found Skulpt in this slightly disheveled state because the original author had sort of left it. And we ran into problems and started fixing them and yikes, it slowly grows.
02:39 Michael Kennedy: Yeah, who was the original author, was that Brad Miller?
02:42 Panelists: No, Scott, forgotten his name.
02:46 Michael Kennedy: Yeah, so Skulpt is not totally new. I was looking through some of the docs and stuff. I certainly saw 2011 here and there and that actually would put the timeframe almost exactly the timeframe that you're talking about Albert.
03:05 Michael Kennedy: Famous last words.
03:07 Panelists: Yeah no, but he's like amazing software engineer because he got such a long way, he got the compiler and the parser and everything. And he got a sizable chunk working, but then abandoned it, there was other stuff to do probably, and we found it in that state and we just took it from there. Ask your next question because I'm going to come in at the point in the story where I actually come in.
03:29 Michael Kennedy: Yeah, I was going to say, so Albert, what's your relationship to the project today? I know that you're doing a lot of overseeing issues and merging PRs and things like that. Are you leading the project or are you working with someone else who is?
03:41 Panelists: The official leader is Brad Miller, who took the ownership over, but two or three in the line who have contributed the most and I feel this thing where if people do issues or pull requests I always feel obliged to act on them so I do. There's no official split of task here.
04:03 Michael Kennedy: Sure, sure, Meredydd, tell us about your involvement.
05:14 Michael Kennedy: Yeah, if you want to bring Python to the browser right, it should be as Pythonic as possible and then you make it work, right?
06:29 Michael Kennedy: You're like, "Wait, that should work in Python, right, but it's not."
06:32 Panelists: Yes, absolutely, like a non-core Python implementation there are going to be diversion bugs where CPython does one thing and we do the other and we need to run in and fix those. And of course most recently Albert and I did the big upgrade of Skulpt from the Python 2.7 grammar to the Python 3.7 grammar, which opens the door to us moving to an actual Python 3 world in Skulpt, getting in under the wire for the end of life for Python 2.
06:59 Michael Kennedy: Yeah, beautiful, heck, you've got months to spare, at least one.
07:04 Panelists: Days, whole days, Michael.
07:06 Michael Kennedy: Whole days, it's so much time.
07:08 Panelists: It feels good though.
07:09 Michael Kennedy: 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 making progress, that's awesome.
07:16 Panelists: Updating the grammar to 2.7 was one of my first big projects in Python and that was only like one step and that took me a summer of coding.
08:56 Michael Kennedy: Exactly, exactly, you're like, "What, I was trying to avoid all this, now I'm back, right?" At the beginning here, I do want to throw out something real quick for you Meredydd because a lot of these attempts to do this kind of stuff, what I feel like it results in, and tell me if your experience is like this maybe, is it results in like a minimum proof of concept feeling. You know, like yeah, I technically could do NumPy here in this example or I technically could do this Python thing in Rust a little bit, but it's actually, anything real and interesting is kind of beyond it, it sounds like you're describing that maybe with Transcrypt a tiny bit, but the reason I bring this up is your use case where you're using Skulpt with Anvil, those are massive applications doing complete end-to-end Python, much of which I would say 80% of which is in the browser, you're building single page applications with a UI with Python.
10:50 Michael Kennedy: And Nginx and uWSGI and Ansible.
13:27 Michael Kennedy: Code Combat at codecombat.com.
14:16 Michael Kennedy: The integration layer, right, the person who says, "Import Skulpt, import the Python, take the Python code and bang 'em together to create app."
15:45 Michael Kennedy: This portion of Talk Python to Me is brought to you by Linode. Are you looking for hosting that's fast, simple, and incredibly affordable? Well, look past that bookstore and check out Linode at talkpython.fm/linode, that's L-I-N-O-D-E. Plans start at just five dollars a month for a dedicated server with a gig of ram. They have 10 data centers across the globe so no matter where you are or where your users are there's a data center for you. Whether you want to run a Python web app, host a private Git server or just a file server, you'll get native SSDs on all the machines and newly upgraded 200 Gigabit network, 24/7 friendly support even on holidays and a seven day money back guarantee. Need a little help with your infrastructure? They even offer professional services to help you with architecture, migrations and more. If you want a dedicated server for free for the next four months, just visit talkpython.fm/linode. Now before we get too far into this I kind of want to do a survey of the other options. You've mentioned Transcrypt and we've talked about Skulpt and there's some other ones, and I also want to ask you the question, it probably is a slightly skewed audience here, but does Python even belong in the front end, right? Did you see Russell Keith-Magee's, either of you, his talk about black swans at the most recent PyCon 2019?
17:04 Panelists: We skimmed it very briefly before this recording, so not really.
18:28 Panelists: I have a rant, so Albert, if you want to jump in first, you have about five seconds. I, at the moment, can't advise a website to go write their front end in Python unless you're using Anvil. Skulpt won't be your friend because it will make you work really hard to do that.
18:47 Michael Kennedy: Yeah, and this is more of a broader question, not is today the answer, right?
18:52 Panelists: Does it belong there, yeah. I think eventually we will find a way to properly put it there, but we aren't there yet.
19:01 Michael Kennedy: Okay, Meredydd, you had something to say about this you indicated.
19:04 Panelists: I'm afraid, and this is where I have to tread very carefully because I'm on a Python podcast, but I am not a Python partisan. We, I can hear the indrawn breath, we picked up Python for Anvil because it is the language of education, it is the world's first programming language for people who are trying to teach new people to code because it is friendly because it is to comprehend, because it is easy to pick up. And the web, which is our target platform is the very opposite of that in so many ways and we wanted to bring those virtues to the web. And as it happened, Python looked the likeliest tool for us to pick up and try to ram through that barrier. I am not wedded to Python being the choice of technology that produces this. It just seemed like the best shot for exactly what we were doing at the time. I don't think Python has any God-given right to rule the development world. I think it has to stand or fall on its own two feet, on its own merits, and I think we, the community should be chagrined at the idea that a Pythonic experience is not available for web development. That the values that Python is the torchbearer for in the programming language community aren't available on so many of these platforms that are the popular development platforms. Python, the language itself is merely a delivery mechanism and I don't want to get tribal about whether that is the way to deliver the web. As it happens it's the solution we've chosen, but I don't think Python belongs on the web, I think Pythonic values belong on the web.
22:45 Michael Kennedy: Right, right, so it seems like with Skulpt looking at, it basically creates a little runtime environment, like it creates the modules variables and little switch to run all the code and things like that and it does seem like it's creating a little execution environment for your Python and it just continues to run there.
23:05 Michael Kennedy: Okay, so there's PyPy.js and I've covered that before on the show quite a while ago. My understanding, it could be outdated, was that project is not really active anymore, is that accurate, do you know?
23:05 Panelists: No, I actually worked on that, it isn't active anymore. Brian from Mozilla started that and I investigated it quite heavily 'cause this gives you the whole of Python, this gives you a full reference implementation of Python in the browser, but compiling PyPy.js is something special. Whoever's tried it, it's awesome. But it turns out it's 12 to 15 megabytes of very, very dense asm.js that outputs it and it takes a few seconds for the browser to understand.
23:05 Panelists: It's even more fun than that. So PyPy is Python interpreted as written in Python, which itself feels like a little bit of a contradiction because if you had a Python interpreter written in Python wouldn't you need another interpreter to interpret it and then you'd just be double stacking, but how PyPy's actually done is that it's written in a subset of Python called RPython, which can be translated effectively to machine code and so there is an RPython to native code compiler. It's actually RPython compiles to C and not to native.
23:05 Michael Kennedy: And that compiles to native, yeah.
23:05 Michael Kennedy: That to me sounds like the weak point of PyPy.js is you've now given the browser this huge amount of source code to go JITing and processing in and of itself. My experience with PyPy has been small stuff is fast, but I tried to get my websites to run under it, and it was actually slower, I don't know, there must have been something going on there. Anyway, that was a little bit older and that's in hibernation.
23:05 Panelists: Well, 'cause Mozilla have moved on to Pyodide, which is a much more sensible implementation of the same thing for the modern web.
23:05 Michael Kennedy: Yeah, tell us about Pyodide, I mean, I covered it actually not long ago, but not everyone's heard that episode.
23:05 Panelists: Right, in which case I'm going to tread very carefully because I will be much less expert than your previous guest, but it's a full CPython implementation with a whole bunch of common data science native libraries that include native code like NumPy and Pandas all compiled to WebAssembly. So it's really impressive to use, it's like part of the Iodide project, which is just kind of like a Jupyter notebook except all executing in your browser, not having to go back to a server, and again, if you load up the sample page and run a few lines of Python code there will be this period of grunting and straining while your computer downloads this blob of WebAssembly that is the compiled CPython in WebAssembly with all these libraries attached, but once it then gets up and running then you have this amazing data manipulation environment right in your browser and you can do things like using NumPy right in your browser and that's the only Python-in-the-browser technology that can pull that trick off.
23:05 Panelists: You're not going to run an ecommerce site off that WebAssembly Python interpreter. It's just got too much stuff and latency.
23:05 Michael Kennedy: Yeah, absolutely.
23:05 Panelists: But yeah, that future of a CDN and global Python interpreter that people can rely on being fast because everyone will have loaded it once, that's a very attractive future, but it's a long way away from now. The fact that Mozilla is making this up means that there are definitely people at Mozilla thinking about this very hard. I don't think it's impossible, and very likely even that it will happen. Oh yeah, and we will be sitting there waving pom-poms when it happens.
23:05 Michael Kennedy: Yeah, that'll be cool. To be honest, what I would rather see than a CDN is Mozilla ship the WebAssembly binary with Firefox and have Chrome ship the same thing, Python 3.7, or 3.8 or whatever and just update it. Browsers update frequently, just update that on release.
23:05 Panelists: That would be awesome, but I think that they would have to, they're probably not going to pick winners like that. 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.
23:05 Panelists: So, I'd say by far the best common use case is if you're building an application where you want your user to write Python. So Anvil is an obvious example here, but there's also something called Trinket for whom Albert's done some work, which is a nice education-focused environment where you can write some Python code, do a Turtle, draw some graphics and have that just run. So for them, something like Skulpt was an easy choice because they could edit in the browser, and just run it right there in the browser. Things like Code Combat.
23:05 Michael Kennedy: Yeah, Trinket is really nice, you get here and it gives you a wonderful little editor with auto-complete and it gives you a canvas or whatever.
23:05 Panelists: Ooh, do they have auto-complete now, hurray!
23:05 Michael Kennedy: I'm pretty sure they did, let me double check that before I...
23:05 Panelists: No, no, they have, it's based on Jedi.
23:05 Michael Kennedy: Yeah, yeah, it's all there, it's super nice. It even goes object.thing, and it evens auto-completes that. It's really nice, it's not just auto-completing the characters.
23:05 Panelists: If you want to see a proper auto-complete implementation with Skulpt, you do have to look at Anvil though.
23:05 Michael Kennedy: Yes, of course.
23:05 Panelists: What Trinket does is they send your Python to the server and then let Jedi look at it and Jedi gives you then the list of completions and then we put that up.
23:05 Michael Kennedy: I see, so they remote out the auto-complete.
23:05 Michael Kennedy: That's super cool.
23:05 Panelists: Having a compiler that is easy to start hacking around with and that exposes primitives like the abstract syntax tree and the parser in the browser is a really great tool if you want to start messing around with compilers and again if you want to start building things to go back to your original question, what would be the best use of Skulpt is really if you're developing something where you want someone to be writing Python as part of using the thing you're building.
23:05 Michael Kennedy: 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. Trinket is nice because Trinket is a pretty cool editor in the browser, it's got some IDE features and sort of a visual output component. You started to mention Code Combat as well I think.
23:05 Panelists: Yeah, and again that's, I mean, you only showed it to us shortly before this call, but this idea that you write some Python code and then it runs interactively as your characters do things, again, Skulpt was a really good fit for that because writing code into this thing is how you use it.
23:05 Panelists: Yeah, get yourself Transcrypt for that as quickly as possible, it will be great. Probably. Yeah. Anvil is much more used for things like Anvil and Trinket, Code Combat, there's a bunch of online courses so there's a couple of MOOCs that use Anvil, some of the other contributors are people who run university courses or build online courses and interactive textbooks with Anvil.
23:05 Michael Kennedy: Okay cool, yeah, we'll link to some of those in the show notes. Yeah, so I think Meredydd, you hit it really clearly on the head saying that a use case is if you need the people to create Python as part of using your project. And every one of the examples that we've seen so far is one of those. 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, but you're just running an app, I don't know, but who knows? So it sounds like the project is pretty good and certainly of all these use cases I would say Anvil is the most holistic and that's the reason I call it out because you're building an entire app ecosystems with this, also Code Combat is a pretty rich app where it does something kind of amazing. But maybe we could talk about the limitations of what people should be aware of in trying to use it.
23:05 Michael Kennedy: So is it not going to happen because it's a lot of work and you guys can't get to it or is it not going to happen 'cause it doesn't make sense to happen, right? So if someone's out there and they really want the CSV package, module to be part of it, could they drop in to source/lib and add a .csv or CSV.py or whatever.
23:05 Panelists: Yeah, yeah, definitely. Yeah, 100%, and a lot of this is so many times my own on the issues like, you know, if you really need it, I will help you, explain where stuff fits in and how you should write, you know 'cause they're all modules, there is some help files around as well, but it's just we're four active developers, maybe five, there's just no time for us to spend on stuff like that. And there's also, depends on the motivation, right? If some of those developers are in education and they're not focusing on the NumPy use case and of course with Anvil our answer to that question is always, "Well, that's okay, the server-side stuff is just a function call away, so go do your deep numerical processing on the server, and make one function call and do it." So there's not a lot of pressure when somebody desperately needs a thing it tends to materialize. Way back in early in my contribution to Skulpt, Skulpt acquired a working datetime module because we needed it, so we pulled over the pure Python implementation from PyPy actually.
23:05 Michael Kennedy: Yeah, I was thinking about PyPy. How much of the stuff could just be brought over from that world.
23:05 Panelists: A remarkable amount, but quite often it turns out that it's using, that was a thing with datetime, I ended up fixing bits of the compiler because some of the slightly exotic things that PyPy's implementation of datetime was using. Skulpt is the best example of this 80-20 rule. Due to sheer number of people trying stuff, we've built this 20% that 80% of the people use, but as soon as you use anything from the standard lib or as soon as you let a seriously senior Python engineer touch Skulpt, like line three they'll be like, "Hey, why doesn't this work?" I'm like, "Yes, well, let me tell you about this." Very long story why it doesn't work. From personal experience I'd say that the senior Python engineer problem has got noticeably better over the time that we've been involved with Skulpt, which is probably not coincidental given that that's the demographic Anvil attracts slightly more than Skulpts other users, but yeah, you'll usually find if you're porting any given thing from the standard library, you'll usually find some corner case in the compiler you need to fix up, but you know, for some of us that's our idea of a fun weekend.
23:05 Michael Kennedy: That's right, guess what case I added this weekend. No, that's pretty cool, so it does sound like if people really wanted to, there's a lot of organization and at least willing to accept people adding more Python standard library support if people wanted to write it.
23:05 Panelists: Oh, absolutely, bring it on. More contributors are always welcome.
23:05 Michael Kennedy: Yeah, yeah, so you guys take PRs and all that, huh?
23:05 Panelists: Yes, indeed, you'll most likely find Albert or possibly me commenting on it.
23:05 Michael Kennedy: Yeah super.
23:05 Panelists: Yeah, and I also operate on the thing that as long as it doesn't break the tests, the add functionality, there's a high likely that I will merge it because a lot of times I'm of the opinion that it's better in than out and if it's part of Skulpt, people will start using it and if there are problems with it, we'll find them and fix them later on.
23:05 Panelists: The choice is yours, you can add things to the Skulpt standard library either with a .py file or with a .js file or with a .py file that imports a module from .js, again it's very much like Python with native C modules, it's the same principle. Obviously writing it in JS is an awful lot more verbose, 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.
23:05 Panelists: There is actually a JSON implementation for Skulpt, it's just not in the standard lib.
23:05 Michael Kennedy: Ah, okay, I see.
23:05 Panelists: Somebody that did it, I have somebody at Trinket that has it. This is the eternal problem of open source tools and people that develop it, there's never enough time. I have several lists of things I have to do for Skulpt and this is definitely on one of those lists, but I never import JSON in Skulpt, so I never run into this, so I always forget to add it, but we should. Oh, please do, yes, we have users who'll be made happy by that. Okay, I've made a note to bug you after this call.
23:05 Michael Kennedy: Give me that implementation.
23:05 Panelists: Correct.
23:05 Michael Kennedy: Yeah, okay, sounds really interesting. I do have one other question on contributing really quick. How precisely, 100% CPython compatible does something have to be before you're willing to accept it? Could it be some subset, like if I implemented JSON, but it only did some of the things that's in the standard library would that be okay, or does it have to be all or nothing, right, like every possible use case of CPython has to be accepted or what is your thoughts around that?
23:05 Panelists: Albert said it, better in than out because if that thing is accepted with stubs for the things that don't work they're much more likely to get fixed up than if we stood on a molehill of purity and said, "No, not unless it's complete."
23:05 Michael Kennedy: It's like, "Fine, I'm going to go about my life."
23:05 Panelists: There is a caveat to that though. If you're adding to the compiler we will usually say this is not how it works in CPython, so we shouldn't introduce this unless it's, and this is because we have a few of those things in Skulpt and maybe for Anvil it's not such a big problem, but I think for Anvil it is a big problem. So you have a user that uses it, you're maintaining this wrong implementation of CPython forever.
23:05 Michael Kennedy: Yeah, yeah, I was thinking more of like at the module level and not at the language compiler level, sure.
23:05 Panelists: At the grammar level we are very strict and we actually use the grammar definitions from the real CPython, just imported in, so to drive the Skulpt parser. At the compiler level, work very hard to be a strict subset and there may be some things that we don't support, like for example we're in the middle of our Python 3 move and we don't have async yet, you know, it will syntax error after you try and do that. But everything we do support is in the compiler is to the best of our ability a strict subset of CPython.
23:05 Michael Kennedy: All right, perfect, yeah. Let's maybe round this out with two quick topics on Skulpt here, so you started by talking about adding Python 3.7.3 support, which is great. It's one of the major new things, what are the other new things that are maybe worth highlighting real quick?
23:05 Panelists: One of the really interesting things about the Python 3 grammar migration is that Skulpt does not have enough developer resources to fork ourselves into a Python 3 and Python 2 version. And thanks to projects like Anvil and Trinket and all the others, we have a ton of Python 2 code in production, right? Anvil's users have written a bunch of Python 2 code in the browser.
23:05 Michael Kennedy: They've written the only code they could at the time. And it was Python 2, right?
23:05 Panelists: And on the day we upgrade, they are quite reasonably going to wake up and expect their code to work as normal. And so one of the biggest challenges of this Python 3 migration was that we actually did while keeping compatibility with the Python 2 stuff that we already supported and we did this with bits of old grammar imported, so there is a mode where it will accept the print statement rather than just the print function and that kind of thing. And there's switchs coming through the standard library for you know, am I behaving like Python 2 or am I behaving like Python 3 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 moving forwards and sending out the standard library and keeping up with the fact that it's 2019 without breaking all the code that's already in production.
23:05 Michael Kennedy: 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, it's like now we're free to work on going forward and not double-implementing everything.
23:05 Panelists: 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, we can't let go of our Python 2 users yet. And the pain that they went through is what we will be maintaining parallel implementations of a bunch of the standard library and a whole bunch of flags and the compiler for some time yet 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, but speaking is so much work, so much better than the alternative.
23:05 Michael Kennedy: Yeah, absolutely. I mean it's extra tricky for you because your platform runs their code. It's not like, well, you just leave Python 2 on your server and you just run your Python 2 stuff there, nobody's going to touch your server, 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, right, so this is challenging on your end.
23:05 Michael Kennedy: Right, and maybe even textbooks with printed stuff that is super hard to update that says, go here and type this into that website and it'll work.
23:05 Panelists: And it's our responsibility as platform maintainers to ease the passage.
23:05 Michael Kennedy: Yeah, for sure. All right final topic and Meredydd, you and I have spoken about this and some of the stuff here was a little surprising to me or like I didn't realize it or whatever so I think it's interesting, but I'll give you the first word on this. It seems to me like a lot of the energy around some of this stuff, we talked about Pyodide is in the WebAssembly space and certainly and of the asm.js, Emscripten solutions should go down the WebAssembly direction, but what about Skulpt, does it make sense to have a WebAssembly version of Skulpt? Is that something you're thinking about, what's the story there?
23:05 Michael Kennedy: Yeah, very slow.
23:05 Michael Kennedy: It would be an interesting development around the core, hot loop of process each byte code and also it might be a way to bring in the C libraries, right? You could ship that as a WebAssembly instead of a C implementation for example.
23:05 Panelists: Yeah, exactly.
23:05 Michael Kennedy: Sure, right, where it's entirely contained within WebAssembly, right, something like that?
23:05 Panelists: Something like Anvil is like 90% interop, right? The reason you're writing that Python code in the browser is to drive visual elements on the browser and so actually I would be unsurprised even if we put in all the enormous amount of work in the current state of things, it wouldn't necessarily even improve performance, but that stuff is coming, and I think the world is moving in the right direction, we just have to hang on.
23:05 Michael Kennedy: Yeah, that sounds good, well, thanks for that. Okay, I think we've probably used up all the time that we have to talk about Skulpt and this Python in the browser world. Well, let me ask you really quickly here, each of you, the two questions at the end of the show I always ask. Albert, we'll go with you first. If you're going to write some Python code, what editor do you use?
23:05 Panelists: PyCharm.
23:05 Michael Kennedy: PyCharm, right on, Meredydd?
23:05 Panelists: These days of course a lot of the time I use Anvil's built in editor, but PyCharm is still the gold standard, right? When I'm writing my auto-complete or it's their auto-complete or I have my envious eyes on.
23:05 Michael Kennedy: Yeah, how does it work over here, dang that's nice, let's do that. I agree, cool. And then reverse order, notable PyPI package that maybe folks don't know about, but you've ran across, you're like, "This is amazing, I should tell people about Package X."
23:05 Panelists: Postal, like just transforming user input into valid postal address for basically anywhere on Earth. It's one of those things that the task will drive you wild except you can just pip install it and then somebody has solved this whole scary problem for you. It's awesome, it downloads enormous quantities of data, but it's awesome.
23:05 Michael Kennedy: Yeah, Python bindings for libpostal for fast international address parsing and normalization. Oh, sounds great, Albert?
23:05 Panelists: Well, my day job is actually in Python. I pip install a lot of stuff, but I don't pick packages that often, so I don't have any interesting, new packages to this day.
23:05 Michael Kennedy: I'll throw one out for you that people might not know about, httpx. Have either of you heard of that one?
23:05 Panelists: Ooh, what's that?
23:05 Michael Kennedy: So, you may have heard of something called requests, you've heard of that, right?
23:05 Panelists: Uh-huh.
23:05 Michael Kennedy: Yeah, everyone has. So this is a 100% API compatible thing with requests, but it adds on HTTP2 support, it adds on async and await support, it has some cool intermediate background, parallel work for like doing a whole bunch of requests and stuff. There's a bunch of modern HTTP support on top of the requests API.
23:05 Panelists: Sweet. Cool, yeah.
23:05 Michael Kennedy: That's a good one.
23:05 Panelists: I love the async and await stuff. I can't wait to add that to Skulpt.
23:05 Michael Kennedy: Yeah, that'll be super.
23:05 Panelists: One of the wonderful things about opening the grammar thing now, all we need to do is get that into the compiler. And we have the technology, I am so excited for what happens next.
23:05 Panelists: It is, definitely.
23:05 Michael Kennedy: Sweet, all right, thank you all for being here. I'm going to give you one more chance for a final call to action. People want to get involved with Skulpt, either contribute to it, use it, what do you guys say, what should they do?
23:05 Panelists: Come find us on GitHub, Skulpt, S-K-U-L-P-T.
23:05 Michael Kennedy: All right, super, Albert?
23:05 Panelists: Yeah, I don't have much to add to that. Try out the website, Skulpt.org.
23:05 Michael Kennedy: Super, all right, well, thank you both for being here, it's great to chat with you.
23:05 Panelists: All right, buh-bye. Cheers.
23:05 Michael Kennedy: Yep, bye. This has been another episode of Talk Python to Me. Our guests on this episode were Meredydd Luff and Albert-Jan Nijburg. And it's been brought to you by Linode and Tidelift. Linode is your go-to hosting for whatever you're building with Python. Get four months free at talkpython.fm/linode, that's L-I-O-N-D-E. If you run an open source project, Tidelift wants to help you get paid for keeping it going strong, just visit talkpython.fm/Tidelift, search for your package and get started today. Want to level up your Python? If you're just getting started try my Python Jumpstart by Building 10 Apps Course or if you're looking for something more advanced, check out our new Async course that digs into all the different types of async programming you can do in Python. And of course if you're interested in more than one of these be sure to check out our Everything Bundle. It's like a subscription that never expires. Be sure to subscribe to the show, open your favorite podcatcher and search for Python. We should be right at the top.
23:05 Panelists: You can also find the iTunes feed at /itunes, the Google Play feed at /play and the direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening, I really appreciate it. Now get out there and write some Python code.