The Python Podcast.__init__

Share on social media:

[00:00:12] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With 200 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you get everything you need to scale up. And for your tasks that need fast computations, such as training machine learning models or building your CI pipeline, they just launched dedicated CPU instances.   Go to pythonpodcast.com/linode.  

That's l I n o d e today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show.   And you listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis.   For even more opportunities to meet, listen, and learn from your peers, you don't want to miss out on this year's conference season.   We have partnered with organizations such as O'Reilly Media, DataVersity,   and the Open Data Science Conference.  

Go to python podcast.com/conferences   to learn more and to take advantage of our partner discounts when you register.   And visit the site at python podcast.com   to subscribe to the show, sign up for the newsletter, and read the show notes.   And to help other people find the show, please leave a review on iTunes and tell your friends and coworkers.   Your host as usual is Tobias Macy, and today I'm interviewing Adam Kelly and Wendel Baumann about Rust Python, a project to implement a new Python interpreter in Rust. So, Adam, could you start by introducing yourself?  

[00:01:46] Unknown:

Hi. I'm Adam Kelly. I'm very much sort of a programming language enthusiast, which is sort of how I got into the world of implementing a Python interpreter.   Self taught basic   on a zed x spectrum, got into Python in 2, 006,   spent 12 years doing sort of trading systems, got very into functional programming languages,   and very enthusiastic recently about,   Rust Python. No. Rust.  

[00:02:12] Unknown:

And, Wendell, could you start by introducing yourself?  

[00:02:15] Unknown:

Yeah. Sure. My name is, Wendell Baumann. Yeah. I'm an open source fan. I   I like,   open source and   hacking with Python. So I've been working with Python   for some time now. And last year, I, wanted to do something with Rust and looks pretty good. So I like the language as such and, by day, I'm a software engineer.   So working with   mainly,  

[00:02:39] Unknown:

c and c plus plus at the moment. And going back to you, Adam, do you remember how you first got introduced to Python?  

[00:02:45] Unknown:

Sure.   I think I remember people talking about it way back in 99, and I wish I'd taken the time to learn it then. And then post in the gap after my PhD, I needed a new language to learn, and Python seemed like a great 1 to learn. And I was very enthusiastic from it from the moment I started learning it. And, Wendell, do you remember how you first got introduced to Python?  

[00:03:06] Unknown:

No. I don't   I actually don't remember.   I think   it had it is a long time ago,   but I think I remember   I I was a little bit surprised by this white space,   thing.   First, I was   not really a fan of it, but   now I actually am a fan so, yeah.   That was kind of new to me.  

[00:03:29] Unknown:

And so in the process of working with Python and exploring other languages,   there's this project that you've both become involved with called Rust Python. So can you describe a bit about what it is and how it got started?  

[00:03:42] Unknown:

Yeah.   Sure. I can, I can describe it?   So   Rust Python   is basically a implementation of Python written in Rust. I actually started it for,   yeah, learning Rust   so to say. I Googled it. I couldn't find an any other project doing it so I thought I was the first but I was not.   And then,   I contacted,   Xing Liu who also started,   with the same ID, and he created a repository on GitHub.   And that's how it's, started going. And   at the beginning, I thought I don't know how hard it will be.   Actually, it's a lot of work. So I expected that. Yeah.   Turned out to be true.  



[00:04:29] Unknown:

I think it's now 1 year later or something. I discovered, the project at EuroPython last year when I saw Wendell's talk.   I spent a long time my sort of I want to learn a new language. I'll I'll implement a scheme   interpreter. Drew me to the project. So I was like, I wanna get involved in this. Got stuck into making classes work at that point.  

[00:04:48] Unknown:

And before we go too much further, can 1 of you describe a bit about what the Rust programming language is for anybody who isn't familiar with it and some of the reasons why you might want to build an interpreter with it? Sure.  

[00:05:00] Unknown:

Rust is a low level programming language   in terms of it's trying to compete and compete performance wise with c plus plus while providing really great memory safety   type features. So you don't have a garbage collector, but at the same time, you don't need to worry about manual memory   management, Rust at compile time can track who owns each piece of memory and ensure that you're not doing anything   bad like using memory after it's freed. Yeah. Maybe 1 thing to add is,  

[00:05:28] Unknown:

Rust has really a lot of syntax features.   So   it's like in CUF   while if   switch case statement maybe. That's it. In Rust, there's really a lot more,  

[00:05:41] Unknown:

I feel. Yeah. It's really a language that's trying to bring in a lot of modern programming language features, which have been developed in other languages. And it's really a it has everything you could possibly want language.  

[00:05:52] Unknown:

Yep. And   some people would say that that's the same with c plus plus, but often it's meant as a,   often it's not meant as a compliment. It's meant as a sort of denigration of the language that they're just throwing everything in with the kitchen sink. But my understanding of Rust is that there's been a lot of upfront   design thinking about how it all fits together and what the overall goals are of the language rather than just cramming every new feature that somebody might ask for. I think that's very fair.  

[00:06:18] Unknown:

I know early earlier versions of the language had garbage selection   and green threads, and they took them out because they decided to refocus on making it perform as well as they could. Yeah. I think also Rust has the benefit that,  

[00:06:32] Unknown:

they can start with a clean slate, so   no legacy whereas c plus plus, of course, has, I think 40 years of, legacy all the way back to   to early c maybe. So that's a good thing. Also, there's,   dependency,   manager with the cargo tool, unit test,   style checking with,   what's it called? Rust Rust format which is really good.  

[00:06:57] Unknown:

And so can you discuss what your overall goals are for the REST Python project and what's involved in implementing a fully compliant Python interpreter?  

[00:07:07] Unknown:

So that's a good question. So   I think the goals are not really set in stone yet, I would say.   It's still starting. The project is still in the early phase. I think we even have discussion,   within  

[00:07:20] Unknown:

the within the group where we should go with this project. I don't know. Is that correct, Adam? Yeah. For me, it's very much I mean, implementing an entire Python interpreter is a absolutely huge task. So I think the only way I can come at it as a as a project reasonably is I'm here to learn Rust to really it's really fun learning all the ridiculous details of Python. If we if it can become   something practical and useful at the end, that would be great. But in the meantime, I'm very happy as a learning project and a chance to really get into the deep into what's involved in implementing a  

[00:08:02] Unknown:

well expressed language specification, which isn't always the case with other run times. So I'm wondering   what are some of the biggest difficulties that you're finding in the process of trying to match some of the specification as far as your interpreter? I think we struggled a lot with the,  

[00:08:21] Unknown:

the dictionary   type. Right? It's you implemented it recently, Adam, that we support now  

[00:08:27] Unknown:

all types as keys. That's maybe not another hard part, actually. It's a really complicated language is my take on this. I mean, it's a really simple language to use, and that's what makes it great. But when you dive in, the simplicity as a user comes from these really complicated   interlocking pieces. So resolving attributes on classes has something like 5 cases you've got to iterate through. And then if you're resolving an attribute on a type, it's slightly different. And I love exploring those circles. So type is a type. Object is a type. Type is an object. They both have dictionaries,   sort of like this puzzle of interlocking things.  

And everything is modifiable is the other thing.   So you can change the class of a of a class at runtime. You can check you can replace a class as an object's dictionary. And I think it's a very open question how much of that we will eventually support because some of that is sort of undefined, and you're just looking at the way CPython  

[00:09:20] Unknown:

works. And some of it is defined, and you have to implement it. And in the overall process of building your interpreter, how much of that involves just going through and trying to parse the c Python implementation and figure out what those different bits of c code are doing and then try and replicate that functionality in a different language?  

[00:09:38] Unknown:

I sometimes looked at the c Python codes. I also   got a reference from micro Python code base which is a little bit simpler   in some cases, I would say. I also looked at the, the PyPy implementation   in the   Python interpreter written in Python. So   because that's quite easy to read and then   you get an ID   how some part of the language really works. At least that's the the the references I took to,   to peak and sometimes   it's pretty obvious what has to be done. So no   need to reverse engineer the  

[00:10:13] Unknown:

or translate existing c code into Rust code. I quite like playing with CPython. That's my starting point is like poking CPython and trying to find out what it does. I should probably be looking at the CPython code more. I think we all have sort of a different way of coming at these problems. But between sort of having an implementation, you can try and match having the having the c Python code and having various specification   docs and blog posts.   You can sort of work out what needs to be done.  

[00:10:42] Unknown:

And can you walk through a bit of the overall development cycle of figuring out what's the next feature that you're going to try and replicate or what's the new capability that you're trying to add and how you manage the overall road map. And I'm also particularly interested   in terms of the early days of the project of just getting something that would even compile just the simple hello world example of Python and how you went from 0 to that point and then from that point to where you are now. Yeah. Alright. So the the first thing I tried was,  

[00:11:13] Unknown:

parsing some, example   snippets.   A print hello world for example. That's, actually a piece of code I started with. Now it's a simple,   Python file with only   1 or 2 lines containing   a single snippet of, of syntax and I started with the with the partial part trying to to parse that   part of the code and then,   adding the the translation to byte codes,   that was done later on. So So that was really in the beginning. I think the current way is,   what about what I try when I'm looking for new things to implement in this is,   taking a piece of codes, running it and see what's,   where it fails and then try to   to figure out why it fails and a way to fix it. And recently, I,   experimented a little bit with the Ouroboros library   which is a,   Python library, standard library Just going over all the Python files and see if those files,   parse correctly for example. That's that's my take on it.  



[00:12:17] Unknown:

Very much similar I think. I when I   first came, I think the first thing I tried was let's define some functions and execute them. And then I found they worked, but there was no arguments. And then from there, well, classes is the next thing. And then got that got me into a, well, how do classes work? And from there, I think I've got stuck into trying to make sure that all of that machinery is right. So we have dictionaries and attributes and looking at how all of that stuff interacts. So what so I've done quite a bit of work on scopes. So look and then there's quite a lot of optimizations in c Python to make sort of local variable name resolution work fast, to make sure magic method trip lookups are fast.   So I've been thinking a lot about making sure that that machinery   works. But I think we've done very well because we've had a lot of great contributors who have come at the project from different angles. So you've said somebody has come in and made sure that our internal APIs are sensible and that we can define Python functions in Rust easily. We've got a very nice API from that, and then we've got other people who come in and gone, well, it'd be really cool if we could run this on the web with Walsom. So I think we've got a lot out of different people coming up the projects from different angles. And because we're just all doing this in our free time, it's got to work like that. It's got to work like, let's attack the bits that interest us. And in terms of the overall road map, I don't know if you have it sort of, like, well defined as to what pieces you have and what pieces you don't, but I'm just curious, at least from a gut feel, how far along you are in the overall process of getting an interpreter running that is able to   implement at least the majority of Python code. We now have complete syntax, I believe, and most of the core of the language works.  

There's a I think a couple of things. So we've been looking at sort of local and and global keyboard keywords. Nobody's ever mentioned async, so I suspect we don't.   Nobody's looked at that.  

[00:14:04] Unknown:

Not yet. Not yet. Not yet.  

[00:14:06] Unknown:

And then the core types are coming along rapidly. So making sure that we have all the methods on dictionaries and sets and all of that.   And then the standard library is the huge piece behind   that. Yeah.  

[00:14:21] Unknown:

Yeah. I know that there's a c at least a decent amount of the standard library that's actually implemented in Python, but there's also another set of it that is implemented in c. So I'm curious   how much of that overall effort needs to be replicated   in Rust or if you're just looking to libraries,   such as what you mentioned, window with Uroboros, where it's just a pure Python implementation of the standard library   and just the overall tact that you're taking on that front. Yeah. It's it's a really  

[00:14:48] Unknown:

interesting case because   if you go from the the Python libraries, like, for example, the unit test, part of the standard library, I think it's all written in Python so   that could be,   simply copied from c Python or maybe PyPy or   another   implementation. But the further you go,   down to some core modules, some of them are implemented to half in c, half in Python, and then it gets really interesting. So, I actually don't know exactly how we're gonna tackle this. It would be good if there was some some,   shared repository   between all Python implementations   which contains all the pure Python,   standard library functions   and files but there's no such thing. So, yeah, that's that's a challenge.  

I think that challenge will come rather sooner than later.  

[00:15:39] Unknown:

And I know that the primary goal of any project like this is to be able to maintain feature parity with the reference implementation.   But in some cases, it can also be important to maintain bug parity. So I'm wondering if that's something that you have looked at at all where you want to ensure that some edge case in the CPython interpreter that operates in an undocumented way also operates the same way in Rust.   1 of the more famous examples being that,   dictionary keys in certain cases were implicitly ordered before they were made explicitly so and people relying on that case. Dictionary keys, insertion order is,  

[00:16:15] Unknown:

we have implemented it that way that's now, the order is guaranteed. Right? Yes. That's correct. So we have covered that. But   for all other going into question of the parity,   my opinion would be, not to go for book parity, but just implement it in a correct way. So not copying bugs.   But maybe later that will change because I think it depends on   what we want to do with the project. Do we want to be at the drop in replacement for c Python or do we want it to be an another Python in implementation?  

[00:16:49] Unknown:

I think it's not yet decided. Right? Yeah. I think so. I think it's something that people within the project have quite different ideas about and will will are coming at from different directions. So it'll be interesting to see how that plays out, and you very quickly start finding the cases where CPython does something strange. You're like, do we need to implement that? Sometimes it's quite fun to figure out how to implement it. But, so I was looking because dictionaries have just gone in, I was looking at, dictionary iterators and what the rules are for if a dictionary changes while you're iterating it. And there's a little bit of freedom there in what you're allowed to do versus what c c Python does.  

[00:17:24] Unknown:

Quite fun. And another question that I have in terms of compatibility   with CPython   is the idea of libraries, particularly ones that rely on c extensions   and what your plan is as far as that level of support, or if you're just aiming for pure Python implementation  

[00:17:41] Unknown:

similar to what PyPy is targeting. So I know a little bit about the amount of work that PyPy have had to do on this. I mean, getting Fast NumPy to work there has been a hellish project. And I think building a compatibility   layer such that extensions that expect to be talking to CPython can talk to the API. Hopefully, some of the work that PyPy has done can make that easier so there are better interfaces there for things, and maybe we can piggyback on some of that. But I think there's a huge amount of work if we want to get that far with the project. I think we will do that in in the end and and hopefully,  

[00:18:13] Unknown:

some extensions that are now written in c will be rewritten maybe in Rust and then we don't face this problem anymore.  

[00:18:20] Unknown:

Maybe that's a take on it. It's an interesting it's an interesting potential application that if people more people are using Rust and they want to have Rust Python interactions, then maybe, at that point, Rust Python has a use.  

[00:18:33] Unknown:

Yeah. I think we we will we will probably first,   support extensions written in Rust. Right?   I would expect so. Yes. I think that that would be easier.  

[00:18:43] Unknown:

And in terms of your overall developer community that you've built around it, I'm curious   about how many people are actively involved with the project and how much interaction you have with the core Python developers   as far as just being able to get design advice or   answer questions about various edge cases and the implementation?  

[00:19:03] Unknown:

I think there's now   a group of, I think 6 or 7 people being act being really   actively working on this, I guess something like that. Personally, I I didn't have much contact with the CPython   developers.  

[00:19:18] Unknown:

I don't know about you, Adam. No. I haven't yet. I think probably as we get more complete and we start to hit really, really hairy edge cases and maybe get more into the parity, it'll become more relevant. But at the moment, I think we're working in areas that are pretty well understood, so we haven't had to. And also in terms of your overall development pattern of building Rust Python, I'm curious  

[00:19:40] Unknown:

how much of the work   requires   implementing things from scratch and how much you've been able to lean on the Rust community of libraries and crates for being able to pull in functionality.  

[00:19:51] Unknown:

Yeah. That's,   that was 1 of the reasons actually why I wanted to try this out because   in Rust, you already have, for example, unicodes,   strings. It's all working.   So no need to do weird things with, c and unicode and these kind of things. Also,   right there's a regular expressions module   and I think the regular,   the regular expressions model is is 1 of the modules that actually   uses a risk package. So in that case, in that sense   it's,   the regular expression   module that you import is really   a sort of a proxy to the regular regular expressions   engine and that's the rest package.  

So it was a matter of, adding it to the project and,   running the correct function and it all works.   So that was really good. That was actually 1 of my, my hopes that I had with this, with this project that   since there are so many, libraries already written in Rust that we could,   leverage those, libraries.   So I'm also curious about other, standard library,   libraries that maybe also could benefit from it from this. I think, for example, the the IO library   dealing with files and these, these things and maybe the the the encodings.   So going from,   different text encodings and and these kind of,   yeah, these kind of functions, I think there's good possibilities there.  



[00:21:18] Unknown:

I think at some point too soon, we need to tackle the questions of ranking currency because I think that's quite an interesting case. It'll be very interesting to see what what tools Rust provides us with there. The GIL is always 1 of the things that comes up. And at the moment, it's not an issue because we don't support threading. We  

[00:21:35] Unknown:

don't have a GIL yet.  

[00:21:37] Unknown:

We don't have we don't have threads yet. No. Wait a second. Yeah. I'm curious how that will work out. But I'm hoping this, well, it's not necessarily an easy easy thing. There's a reason CPython has the GIL. That Rust safety features will really help when it comes to attack currency and then we might be able to do something good there. Yeah. I think the the object model we we we now have, I don't see any reason,  

[00:21:59] Unknown:

why we should have something like the deal.   But on the other hand,   I think we will find out when we implement when we implement, something like the training module. We'll probably find out. I'm curious how this will go. And in the other direction, I'm also curious  

[00:22:15] Unknown:

if there have been any pieces of work that you have put into Rust Python that you've been able to extract out into reusable libraries for other people in the Rust community to take advantage of? I don't think we we we've done that,  

[00:22:27] Unknown:

sir. Right? No. I don't think so.   It's an interesting question to think about whether we have anything yet that would be useful like that. Nothing comes to mind. I I think the the probably the Python parser, it's a separate,  

[00:22:41] Unknown:

crate at at this point. So it could prop probably be reused in   in other project where you need to deal with Python codes and only analyze the Python code for example.   So going from Python code to an AST that could probably be,   be reused as a separate package.   But the the rest of it, it's it's really 1 great actually.  

[00:23:03] Unknown:

And the other question is in terms of the overall binary size of the compiled interpreter,   if you have put any thought into trying to minimize that at all or if the main focus right now is just getting everything working and then dealing with that as a later optimization if and when it becomes necessary. I think the current goal is to get it it working at all and size is not really,  

[00:23:25] Unknown:

really an issue but,   I think we can also compile it for the web   then size is always an issue. So   but I think it's a good thing to go for,   code size,   reduction or at least keeping it small because, yeah, for the web, we can use it. But also for micro it's maybe also interesting. So you could go to embedded route with the respite,   as a sort of next to micro Python. Of course, it will be larger, but I don't know how much.   I think the current binary is, I think, 6 megabytes or something. I can check.  

[00:24:00] Unknown:

You did have to do some work to get, the binary size down for the web assembly side of things, didn't you? I didn't do that part of the web assembly.   Okay. Fair enough. I saw something going through you, but I don't remember the details. Yeah. I did some I did 1, optimization  

[00:24:14] Unknown:

in the parser, part.   The   So we use the partial,   LR pop from it's a risk, crates. It's a risk,   partial generator.   And I did a trick there to reduce the side the the the generated parse tables.   I think that saved   1 megabyte or something or half a megabyte   of code size in the in the web assembly bills. Still it's rather large, but it saved some.  

[00:24:40] Unknown:

And so, as you mentioned, 1 of the other benefits of using Rust for this type of interpreter is that it does have a web assembly compilation target. And so I'm curious if you can talk through a bit of some of the vision of how web assembly will be able to support writing   client side Python and just, your overall experience of working with WebAssembly  

[00:25:02] Unknown:

in this Rust Python project? Maybe I can describe WebAssembly first in a bit. Yeah. So   WebAssembly   is an, is an ID to,   to write code in any language you like and then compile it to WebAssembly and then be able to run it in the browser. Whereas previously,   people were really,   when you develop an application for the browser, you have to do it in JavaScript. And, of course, JavaScript is good but   not everybody likes, the language itself. And precursor of WebAssembly was ASM dot JS which was a subset of JavaScript   and then,   compilers were created to compile, for example, c codes to this subset of, Javascript and then you could run   arbitrary c codes in browser, but still it was, Javascript so then the next phase was web assembly which is really a binary   format which could also be targeted,   by compilers. For example, going from c to, web assembly and then you can run c codes in browser. And Rust also has this option to compile from Rust to web assembly   which means effectively that if you have   a Rust program you could compile it to web assembly and then include it in your web page and load it and run it in your browser.  

And that's actually what has been done with the respite and as well in the demo page.   You can run,   the respite and interpreter inside   browser   really at the client side. So there's no communication going to a server where a Python process is run but it's all done on client side which is rather interesting. And there's some pretty good packages and tools supporting,   to build a Rust application   and compile it to WebAssembly.   Unfortunately,   I didn't set it up and and,  

[00:26:48] Unknown:

you were also not involved. So we're not really involved in how we did that. But I was able to reproduce it locally on my machine. So that's something. It's a great aspect of this open source model though that we we built the we built, an interpreter, and then some other people have come along and stuck a web page on front of us. And now now built compiles, runs in the browser. And if you go to the page, you get a nice interactive Python terminal in a web page. It was actually 1 of my my more evil plans to lure more people into this project because it was,  

[00:27:17] Unknown:

hey, there's rust and you can target web assembly. We have lots and lots of front end developers. So there's lots of people working with this, web assembly rust thing. So it has to be popular. So, probably, maybe we can get some,   attention and,   have some help of those,   of other people who maybe come from this,   space and maybe it works. I don't know. Yeah. I'm also interested  

[00:27:41] Unknown:

in   the types of applications that this might enable as far as being able to   use Python in the browser context natively rather than through some sort of transpilation layer or from trying to load a gigantic binary into the browser which it sounds like is still a little bit the case with Rust Python, but down the road you might be able to minify it bit more. I don't know. Yeah. I hope we can minify it, but,  

[00:28:07] Unknown:

yeah, we will have to look into it.   Maybe we can split it in some way that, if when you import a module that you download it on on the fly. 1 application that has already been built is the pick it up game engine.   It's it is built on Quicksilver and Rust Python. Quicksilver is a game engine written in Rust and it is then combined with Rust Python so you can write games in Python   and run them in the in the browser. So that's actually 1 example of what you could do. Still you what what you mentioned is true. You have a really dopey binary that you have to transfer over the weapons.   Yeah. So it is not really bandwidth,  

[00:28:44] Unknown:

friendly in that sense. I think the binary is still, 3 megabytes or of of of web assembly, what you have to download. Another potentially interesting is Python is often used as a language for learning. It's quite a it's quite a learning language. So there might be applications around people who want to just do that for learning Python interactively without the need to download and figure out how to install Python locally. There might be some interesting sort of  

[00:29:10] Unknown:

applications that could be built there. And on the web front too, I'm also   curious if you have done any research research as far as being able to minify Python code similar to what happens with JavaScript and also how the packaging   we  

[00:29:33] Unknown:

we haven't looked at it, at at least not at not that I know of.  

[00:29:37] Unknown:

No. I did did Google just before our conversation   and found pat 441,   which, handles,   building zip archives from, Python code, which is quite interesting. I don't know   whether you want to, ship a full   zip management to the browser. Might might just make our interpreter even bigger, but it's interesting that that exists.  

[00:29:57] Unknown:

Yeah. We still need the zip module. Yeah. Probably we can reuse some Rust and create at this zip, so that's  

[00:30:04] Unknown:

good. Yeah. I know that there are projects such as PEX for being able to bundle up an entire Python environment   as a zip archive for delivery to the server side, but I'm curious how that would manifest on the client side because of that  

[00:30:17] Unknown:

pressing desire to try and keep the binaries and the deliverables as small as possible. Yeah. That's certainly gonna make it a real challenge. And you're competing with JavaScript is very established. A lot of work has been done in this space. So there's a lot of catching up to do to get there. And in terms of your overall experience of working with the Rust Python interpreter and trying to replicate functionality  

[00:30:39] Unknown:

of other interpreters, I'm wondering what you've each found to be some of the most interesting or challenging or unexpected aspects of the project.  

[00:30:46] Unknown:

The thing I'm currently facing is the global non local,   keywords.   I was a little bit surprised how that should be implemented.  

[00:30:55] Unknown:

I still don't fully understand, how it should be done but I thought those things would be simpler. But, yeah, it was a little bit harder, a bit harder. I think a lot of sort of understanding the complexity of the of the internals and how many how many moving pieces there are. I'm quite interested at the moment. I'm looking at,   starting to look at slots   and how class attributes can be accessed.   I think there's quite a lot of exciting   well, optimizations there.  

[00:31:22] Unknown:

And are there any particularly interesting   uses of Rust Python that you've seen beyond just standard Python development   or anything sort of unexpected   as far as   the directions that the project has taken or ways that the project is being used?  

[00:31:38] Unknown:

I I don't know if it's used actually. Beside   I only see 1 use case, in the pick it up, game engine, but for the rest, I don't know. Also, wouldn't recommend actually to use it at this   at this point   since it's still yeah.   Yeah. I I don't know. It's not really usable, I think,   in an, in an actual application, I would say.  

[00:32:02] Unknown:

Yeah. I think once we're a bit more complete, it will start to get to the phase where we can find uses for it or find things where there's reason for people to come and use it. But at the moment, it really is a tool for people who are interested in learning about how a programming language interpreter works, how it fits together, how Python.  

[00:32:20] Unknown:

And   looking forward, what do you have planned for the near to medium future of the project as far as   goals   for utility or specific features that you're looking to implement or just overall community engagement?  

[00:32:34] Unknown:

I think we've had a lot of flux recently in terms of getting all our internal APIs right. So I think there's quite a lot of refactoring work in getting all of that in. Moving on to more interesting things,   I've mentioned the   optimization. I think starting to look at how fast we are.   I think when we measured it, we were something like 17 times slower than c Python, which I thought was not a bad result for a naive implementation.   The other thing I really think we should have a look at sooner rather than later is the concurrency stuff because that's going to   impact a lot of things, and it's also good advert adverse. If we can get a guildless Python without   a massive slowdown, then that would be a great thing to achieve.  

Garbage selection is a fun project as well that's come up because we currently don't do have it.  

[00:33:22] Unknown:

Yeah. And maybe, I think the standard library is also 1,   yeah, interesting,   interesting puzzle to solve. I I I'm looking forward to having a unit test module in the standard library. I think that's a good goal. It It'll be really nice once we have unit test. We can start running CPython test suites against our interpreter  

[00:33:42] Unknown:

and see just how compatible we are. And your point of the garbage collector is interesting too. I'm curious if you have put any thought into  

[00:33:50] Unknown:

whether you're going to try and take a different approach to the overall design or if you're going to stick with the reference counting and generational garbage collection. So currently, we use reference counting, which Rust provides for for us. So we can use Rust's internal implementation of reference counted pointers. So we have that type of garbage selection there already.   There's nothing in in order to deal with, garbage   with cycles, so obviously we're leaking there.   Somebody has had some a a look, and there are garbage collections writ lectures written in Rust. So it'll be very interesting to find out whether or not we can just bring 1 of those in   and take advantage   as was mentioned of, Rust's,  

[00:34:30] Unknown:

large ecosystem of libraries. If we can just take a garbage collector off the shelf and use it, that would be very cool. And what do you think are the risks that you can anticipate or that you foresee that could potentially derail the project before you get it to production readiness? I don't know. I don't,  

[00:34:47] Unknown:

yeah. Maybe that it will take a long time to complete it or maybe some   some disagreements about,   how we should implement things and that it the project will be forked into. But at the moment, I think we're still, heading in the correct direction. So   or more or less in the court in the in a good direction. So I don't see any risks yet,   except that it will be a a lot of work. And maybe in the end, 1,   risk would be that we,   copy the standard library   and we will have to maintain a,   yeah, how do you say, compatibility with the CPython implementation.  

[00:35:24] Unknown:

I think the sheer scale of the project is   very much the biggest risk. It's a lot of work. And at the moment, we   lack a clear purpose beyond it's very interesting. So   Yeah.   The the the other risk is Yeah. We get to a point where we've done all the interesting work and  

[00:35:42] Unknown:

there's no use for us. Yeah. May maybe maybe as 1 of the risk that's we don't have a clear goal. Yeah. There's some fake goal. We we want to build this but, yeah, not really set in stone with milestones and these kind of things. I don't know.  

[00:35:56] Unknown:

And as far as   help from other contributors or from the community, are there any specific areas that you're looking for people to join the project   and add their own opinions or feedback or contributions?  

[00:36:11] Unknown:

Yeah. I think,   we're always on the lookout for people,   adding   functions to the built in objects, for example. I don't know how percentage wise how how far we are. We we have a we have a script which checks all the methods,   which should be present. So   in theory, it should be possible to get some percentage there and on how far we are. But I I think it's it's good starting issues.   It's relatively easy to do and it's really a lot of work. So I think there we really are looking   for, contributors   in this area.  

[00:36:46] Unknown:

And are there any other aspects of the Rust Python project   or your efforts of replicating the CPython runtime that we didn't discuss yet that you'd like to cover before we close out the show? Yeah. Maybe 1 thing to mention is the the the JIT, the just in time compiler.  

[00:37:01] Unknown:

So PyPI is a really fast implementation of Python since it has a, JIT.   So I think   1 of the opportunities we have is respite and is also to add a JIT   compilation phase in 1 way or another   to make it go faster.   I don't know how it will work yet, but,   I think there's Jits, projects.   There's a holy Jits,   project. It's a Rust project,   for   creating a JIT in a way.   It should work. So we have to see how we can combine it with the Rust Python, in interpreter.  

[00:37:37] Unknown:

The whole area of performance is going to be very   interesting once we can get stuck into it. I think so far the the emphasis has correct lately been on getting a complete interpreter.   But we're going to need to set up   test suites to sort of monitor performance   and then get into that nitty gritty of making it fast.  

[00:37:57] Unknown:

Alright. Well, for anybody who wants to get in touch with either of you and follow your progress on the project or possibly other contributions, I'll have you add your preferred contact information to the show notes, and I'll also add links to the GitHub project.   And so with that, I'll move us into the picks. And this week, I'm going to choose the group Oysterhead.   It was a super group consisting of Les Claypool from Primus,   Trey Adestasio from Phish, and Stewart Copeland from The Police. And   they did 1 album, 1 tour, and then they split up and never wanted to talk to each other again. But the outcome of that was a   very enjoyable   album, definitely worth checking out. So with that, I'll pass it to you, Adam. Do you have any picks this week?  



[00:38:41] Unknown:

So 1 thing I've come across recently that I've really liking is f ZedF, the fuzzy finder, which I find very useful for sort of leaping to files and source code. They've, also made bash history far more far more usable, and it sort of integrates itself in lots of useful places. It, has support inside of Vim as well. And, Wendell, do you have any picks this week? Yes. The progress bar for Python.  

[00:39:03] Unknown:

It's called it's package, Python package,   tqdm.   I really like it. You have a for loop, You decorate it with this,   this library, and then you have a progress bar,   in your 4 loop. So,   yes, I think it's 1 of my favorite packages for the last,   last half year as I found.  

[00:39:22] Unknown:

It's really fun. Great. Being able to have some understanding of how far along you are in a process can be invaluable at times.   And also second your pick of the fuzzy finder, being able to just   type in portions of strings and find something useful out of it is always   very helpful. So I want to thank the both of you for taking the time today to join me and talk about your work on Rust Python.   I'm definitely interested to see how the project progresses   and possibly have another entry and another option for people who wanna run their Python code. So thank you for your efforts on that front, and I hope you enjoy the rest of your day. Thank you very much. It was great talking to you. Thanks. Thanks. Thank you.