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've got everything you need to scale up.   And for your tasks that need fast computation, such as training machine learning models, they just launched dedicated CPU instances.   And they also have a new object storage service to make storing data for your apps even easier.  

Go to python podcast.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, Pareteum Global Intelligence,   ODSC,   and Data Council.  

Upcoming events include the software architecture conference, the Strata data conference, and PyCon US.   Go to python podcasts.com   slash conferences to learn more about these and other events and take advantage of our partner discounts to save money when you register today.   Your host as usual is Tobias Macy. And today, I'm interviewing Tal Anat about the idle editor for Python, its history, and what is in store for its future. So, So Tal, can you start by introducing yourself?  

[00:01:49] Unknown:

Yes. It's pleasure. Hi.   I'm Tal Einat. I'm from Israel. I've been programming,   with Python   since 2, 001.   I'm now a core developer since 2010,   of the Python language.   These days I'm a partner and co founder of, the educational technology company Foolproof,   which develops,   tools for   studying   high school math. And do you remember, hey, you first got introduced to Python? Yeah. I I learned Python and programming,   in the course that I did before my military service in Israel. In Israel, we have mandatory military service.   When I served, it was mandatory 3 years.  

So we had an intense,   half year course. We were taught a bunch of stuff. We were taught programming programming right from,   from the basics.   And we studied mostly c and Python.   And we started with c, and I remember distinctly that when we first started,   learning Python,   the first,   course, the first class,  

[00:02:52] Unknown:

with Python was just such a breath of fresh air. It was like love at first sight and I've been loving using Python since then. And so, as we mentioned at the opening, we're going to be talking about the Idle module in Python. So for anybody who hasn't used it, can you just start by explaining a bit about what it is? So Idle is an IDE, hence the name.  

[00:03:13] Unknown:

It's an integrated   development,   environment.   It's named as it is after Eric Idle who was 1 of the 6   cast members of Monty Python after which the language is named. So everything in Python is named after something Python related, Monty Python usually.   So it's a simple IDE. It's supposed to be usable and used by,   begin mostly by beginning,   programmers, beginning Python programmers and usually novice programmers in general.   So its goal,  

[00:03:44] Unknown:

it's different than most IDEs and purposeful issues. So so as you mentioned, it's targeted mainly at beginners to the language or beginners to programming in general.   And it's been part of the standard library of Python for quite a while now. And I'm curious if you happen to know the original motivation for adding it to the core of Python and some of the history behind it. Yeah. So,  

[00:04:05] Unknown:

I asked actually asked Guido about this in preparation for this, podcast.   And what he told me is that back in 1998,   he just thought he was looking at IDEs and specifically Visual Studio, which was ruling the Windows world of software development. And he said, well, it would be cool if we had something like that for Python and then just started hacking on it. So Guido,   Guido van Rasson, the the original creator of Python was also the original creator   of idle. And   this is after he mentioned that in 95, he also created a browser. So he had a previous history of creating things that he just thought would be cool and doing them with Python.   So that was the original,   motivation   And it sort of grew from there at some point. That was in 98. In 2000, there was a discussion,   with several developers who, some of who joined Guido working on idle, and   they decided that they wanted to add a few major features and changes to idle, which they did in the form of creating a new project they called idle fork,   which they developed outside of the main repository of idle   for a couple of years. This was led by, David Shurer along with, Nicholas Riley and Peter Schneider Kemp. So they worked on that. They added an RPC   mechanism so that,   the Python commands themselves in the interactive shell would be run-in a sub process,   and may keep the GUI responsive at all times,   and a bunch of other things which are we take for granted as being, central features of idle, came about, in that project. And that was merged back into the core Python code base in 2002 when the project was excuse me, in 2003   when the Idle Fork project was,  

[00:05:50] Unknown:

completed. Because of the fact that Idle has been baked into the language for a while, it's often pointed to as sort of the first environment for people to start experimenting with writing Python or learning to program. And so I'm curious   what you have seen as being some of the main use cases for IDLE and how the   original motivation   of building it and having it as part of the language has evolved along with the evolution of the computing environments that we have and just the overall   capabilities   of other editors or the ease of use of getting started with Python and text editing environment?  

[00:06:28] Unknown:

So I I think when when we started working on it when the in the first few years of when Idle Idle was developed,   it was seen as it would this would be   the Python IDE,   similarly to Visual Studio being used on Windows for developing,   certain yeah. The Microsoft languages.   But I think that view changed, when when they started the idle fork project. They   defined very clear aims and goals for the project.   And some of those were keeping it simple, keeping it, as a very simple and easy to use IDE.   And in later stages, in 2002,   Kurt B. Kiser took over leading the project.  

And later, I mean, the past few years, Terry Jayaridi has been leading it. And again and again, when when this discussion has come up, we've always decided,   to keep those as the main goals. And I think   that,   mirrors very well the main uses of IDLE. It's mostly used by,   when teaching IDLE when teaching Python. Excuse me. It's mostly used when teaching Python to new programmers or by new programmers,   learning Python or learning programming.   Or sometimes it's used when you just need a very simple IDE without fully installing,   heavy   editor or IDE. And   so   I'd say, 1, having it baked and and always installed almost always installed with Python enables the second form of use. When you just need a simple editor, you can always,   run idle.  

And,   the first type of use when using learning Python is really helped by keeping it very simple and easy to use and geared towards   new programmers rather than power users. So and, I mean, for example,   1 of the core developers,   a long time core developer, Raymond Hettinger,   who a lot of what he does these days is, teaching Python development. Raymond uses IDLE in his teaching,   almost every day.   And,   he's been using it for many years. He's been 1 of the developers and,   also give giving us a lot of feedback on what happens when lots of people try to use idle to learn Python.  

[00:08:41] Unknown:

So and he's just 1 example. We get a lot of feedback from him, but I know that a lot of other people teaching Python have used idle over the years very often. And because of the fact that it is simple to get started with, but also fairly simple in terms of its feature set, I'm wondering what you have found to be the sort of general limitations   or the tipping point where people need to move beyond idle and into a different editor or a different IDE,   and what idle has built in as far as being able to maybe stretch its use cases beyond   the out of the box experience?  



[00:09:18] Unknown:

So I think well, 1 case when people move on from idle is when they were looking for more powerful editing abilities.   For example,   anyone who's a power user of an editor such as VI or emacs or any major IDE such as Visual Studio or, the newer ones like, Sublime Text, Versus Code. They know those have lots of powerful editing features that allow you to just work faster, make changes to code much faster. The idle,   is purposefully missing many of those features   to keep the interface very simple and to keep what you need to learn to use it effectively,   to a small set of things to learn. But that also it does definitely limit its usability for anyone who wants more advanced editing features. It also lacks integration of many other things like refactoring tools that more fully featured IDEs,   have, tools for running tests automatically, tools for integrating with version control systems, and so on and so on. So, I think in many professional environments when people are, developing professionally,   usually they   work in an organization or in a team and they find themselves moving on to tools that are more widely used in their team or integrate better with the tool set used by that team. The other side of idle that we we haven't discussed so far, but I think is 1 of its major,   advantages is for interactive work. And that's actually where many IDEs   don't focus, but idle has focused quite a bit. So idle shell, it's interactive environment which,   used to just enter commands and see their out run commands, see their output   is very, very useful. It's relatively powerful even compared to alternatives. The,   it's more comparable to interactive environments such as IPython or Jupyter. And so that is very usable and has some nice GUI features that are, for example, missing in ipython.  

And it's also,   its features are more easily discoverable things to the GUI compared to IPython where you have to read more documentation or go through a tutorial. So I think for interactive use, I still use it almost daily for interactive things in Python. Sometimes just for checking out,   you know, what a certain function does or getting,   seeing the help for a certain class. It's very quick to just fire up idle shell and check it out there than to search through the docs. So I think that's sort of something that stands out in idle and makes it very usable   even for people who mostly use other environments for development.  



[00:11:55] Unknown:

And so I'm wondering if you can go through a bit more of the feature set that is built into idle so that people can maybe compare and contrast between the initial implementation that they might have from just typing idle at the command line and seeing a window pop up and then wonder, what am I supposed to do with this versus people who are coming to Python   from   the experience of using some of these more full featured or heavyweight IDEs or even something like emacs or BI where it's just a native text environment and all the integrations are set up manually?  

[00:12:26] Unknown:

So Idle is first of all a graphic   application. It works. It's cross platform and it's built on the TK.   It's built on the TK graphical toolkit which uses the TCL language underneath and that sort of on a technical level very interesting sort of integration. But what that allows it is to be very cross platform. It works on Windows and Linux and Mac and, so on. And being a GUI,   environment with a very advanced shell, but being simple enough that anyone could just start using it without learning almost anything   is I think a major benefit. And then, HIDAL's 2 major modes are it's has editor windows for editing   files with code, usually with code, and then the shell window. The editor windows are relatively simple,   editors. They do have   basic features such as search, search and replace,   you know, just, anything you'd basically expect   from, an editor. It does have some, auto completion, for example. It has a nice code context feature.  

So while you're scrolling, you can see the context of the code you're currently looking at. So it does have a few niceties and, 1 of recent feature that has been asked for a long time that I've added is line numbers, which has been missing for many years.   But other than that,   as I mentioned before, it lacks features such as refactoring and anything that sort of goes beyond the context of looking at a single file of text. So that I'd say is the, for the editor windows. 1 very nice feature is the integration between the editor windows and the shell window. At any time when you're editing a file, you can hit f 5 and run the code in that file in the shell   and see the output there, interact with it if it, it's in, you know, asks for user input and so on. And then once that's done running, you still have the namespace populated by that, file so you could inspect   variables and classes and,   sort of check everything that happened and keep continue working interactively after that's run. So it's a very nice environment for,   iterating quickly, just testing simple things out.  

And when you're learning, that's 1 of the reasons it's very nice for learning Python. You can enter some code, hit f5, see what happens, go back to the code, try fix what you've done or try something else and so on. And then the shell window has some really nice features like,   very nice auto completion,   call tips.   It has,   we recently added a feature where it squeezes very long outputs so they don't sort of fill up your shell and then definitely,   it squeezes it into this small bar that you can expand or view in a separate window. And you can restart the the shell, you can restart the   separate Python process which actually runs the commands without losing all of your previous output. And it has many other features. I won't go into all of them but, just to give a taste, it's a pretty nice, interactive environment. And that's really the reason 1 why I started to use idle. Back when I was in the military, we would use idle for a lot of our interactive work after the, in the beginning we were using, just simple   command line   interactive interface,   And IDLE was much better than that. That act that's actually what led me to begin contributing to IDLE. When I when I was in the military, we developed,   we extended idle's   capabilities mostly in the shell to make our interactive work,   more effective. And then I I wanted to bring some of those improvements back, to Python's idle. And so that's a good entry point to discuss some of your overall experience  

[00:16:07] Unknown:

of working as a core contributor   and some of the involvement that you've had with Idle specifically over the years. So I'm wondering if you can maybe talk through some of the challenges that exist in the implementation of Idle as far as adding new capabilities and maybe discuss a bit about how Idle itself has actually implemented and architected and some of the evolutions and changes that have happened up to the point where you got involved and then through to today? So Idle is built on TCL TK, which is a GUI toolkit, which, actually runs the TCL language,  

[00:16:39] Unknown:

underneath the hood. This is all done by the TK inter module,   in the Python standard library. IDLE builds on that and uses that as its GUI toolkit,   very extensively.   That influences a lot of the   technical   sort of the way IDLE is built. So this was originally started in 98 by Guido and it's developed a lot since then. The code base   shows that. I mean, it's,   when any code base that has been developing,   continuously for 20 years shows its age. And Python has also developed a lot over those years. I mean, it started before Python 2. So that's definitely it's been going, undergoing a lot of maintenance and updating in the recent years, but that's a lot of work. Terry Jayrede has been doing a really great job just tirelessly working to bring the code,   up to date in the recent few years. So it's a in a pretty good state now. It's, well tested mostly. And   now, most of the changes are, we're writing things that are just for Python 3 since the Python 2 version,   doesn't need to be maintained any longer with the Python 2 sunset a couple of weeks of weeks from now. So the implementation, it has an RPC mechanism for the main GUI process to talk   the sub process that actually runs   the shell commands. I'm trying to think what I can say about the architecture itself.  

So as as far as architecture, it's pretty simple.   Idle is built.   Mostly there's a central editor window   class   from which,   the the shell window is actually a subclass and a few other types of windows like output windows for search results and so on. And those classes pull in a bunch of,   modules,   which are pretty independent,   and they connect them together. So every,   major feature of idles such as, auto completion, call tips, code context,   search and replace,   all of those are implemented   standalone modules, which the editor window or the different windows pull in and tie together.   That's like the overarching   architecture.  

And the other part of that architecture is really the, RPC   mechanism by which the shell communicates with the Python sub process for running commands.   It actually acts as a server   talking with a client,   a 2 way RPC mechanism,   so that both the GUI can interrupt,   for example, the GUI can interrupt the sub process if I hit control c or if I'm closing idle.   And the other way as well, I can get,   output or exceptions from   commands run-in the shell. So those are those are the 2 major   parts of the, sort of high level design of idle. And there is an extension mechanism   And originally, many of these features were written as extensions, but we've been,   pulling all those extensions,   in as   actual modules of idle,   and removing them, from the extension extension   from being written as extensions just so that it could be better tested and better integrated and avoid,   some   funny quirks that, arose from the extension API.  

So these days, there aren't any ex extensions that are shipped with idle by default. There used to be quite a few, But you can still add,   other extensions. There aren't many. I mean, the yeah. The hope that there would become an eco ecosystem of idle extensions   never really panned out. There are a few sort of projects like idle x or v python that were more forks of idle than   just a set of extensions.   And they implemented   various features as extensions, but you don't see people,   pulling in just   1 or   several,   key extensions into their idle for daily use. That's almost never happens. Part of that is because the just technically the,   extension interface isn't very user friendly. There's no easy way to install an extension. You need to download the code and actually copy it into the library where your idle is and then copy   a specific part of the configuration   text into your configuration files for idles. That's not a nice interface.  

That doesn't really make it trivial. And there were some thoughts of making that easier, but with just there was lack of interest, I think that that's why that never actually happened. And so as you mentioned there,  

[00:21:07] Unknown:

the code for idle was started about 20 years ago, and now we're to the point where we're sunsetting Python 2 support. And so I'm curious how well the   overall code in the Idle module has aged   as new capabilities and features in the language itself have been added and as the sort of programming paradigms   and GUI toolkits have evolved.   And so I'm curious   what the sort of pain points have been as far as keeping things up to date and keeping them runnable or sort of how well it has held up. And then maybe some of the plans that are in store for the future of Idle now that we can free ourselves from Python 2 and start to look forward to how it looks in a Python 3 only world? So the code base itself,  

[00:21:51] Unknown:

is being,   is in the process of being brought   more up to date. It's still backwards compatible with Python 2, but with that being sunsetted in a couple of weeks, we'll stop doing that. And actually many of the recent,   improvements and changes are no longer in the Python 2 branch and they were written,   so they're not,   no longer compatible with Python 2. And going forward, we'll be removing a lot of those backwards compatibility   parts of the code base to make it more easier to maintain and easier to read.   Overall, there's been a lot of work to update the code base so it's in pretty good shape. Really, the the hardest part of keeping idle   in good working shape has been,   the evolution of operating systems   and trying to keep up. Just trying to keep things working as they are is actually rather difficult. Part of that is because it's built on top of TCL TK and that project,   has   had a difficult few years   where it wasn't very well,   kept up to date, and they had all sorts of problems. I mean, on Mac OS especially,   or back in the years when it was called OSX, there were all sorts of problems there that we had to work around or sometimes we just couldn't fix in idle because   there they were just issues in the TCLTK   itself. Sometimes we had at 1 point, Python began shipping   a specific version of TCLTK   with its OS 6 or Mac OS installers   just so to ensure that a good version because   the version that Apple shipped was problematic and the latest version that you could install from source was problematic.  

So we began shipping,   our own known to be good version of TCL TK just to I mean, not just for idle to work but everything based on Tkinter   to actually keep working well. And we're still not in a great situation as far as that goes. I mean, the recent,   macOS release,   caused a few more things to break. Our support for the new dark mode of macOS,   isn't great yet, Just to give 2 examples. And also, there there are all sorts of bugs in idle that we're having problems keeping up and fixing all of them   and and doing so on all the different platforms. Also, because just interested in idle and maintaining and developing it as it hasn't been very high.   In the past, I'd say a year or 2, Terry, Jay Reedy, and I have been doing a lot of that work. So I think it's a bit better than it was before, but there's still a lot of room for improvement. So if anyone hearing this now would like to help,   I would very much be I would be delighted to help anyone who would be interested to work on idle, to to guide, and to help you find interesting things to do and to,  

[00:24:30] Unknown:

together to fix bugs or to, move it forward and improve it. And I believe that there have actually been a few projects that have tried to build more full featured editors on top of idle and using that as a base. I'm curious  

[00:24:43] Unknown:

what you have seen as far as any projects along those lines or other interesting or innovative use cases that it's been leveraged for. So there's I'm aware of 1 that really 1 such project that really added quite a few features and that's idle x. But I don't see that that's really taken off or seen wide use. I'm not aware of other major projects that try to build a,   more fully featured ID on top of that. There are some projects that try to use idle for   more specific,   education or or learning,   environments. I think v Python,   which also has,   sort of,   I think V Python also has   a version of idle with,   various changes   that's supposed to be used for   robotics,   for controlling   robots in an educational   context,   but I'm not   updated on where that project is today. It was started a long time ago.  

And there is some integration with idle with, Python turtle   module, which is also to be intended for use to learn   programming in a more,   child friendly way or more visual way. But actually, there haven't been many   significant projects that I'm aware of at least that have done so, unfortunately.   Part of that is probably because the code base is not the easiest to build upon and to use. And so as we've mentioned a couple of times, idle is often used in a  

[00:26:13] Unknown:

learning or a beginning coder environment. And as you said, there's the integration with the turtle module. And I'm wondering what your thoughts are or your impressions as far as the impacts and benefits   in terms of the adoption and growth of Python   that Idle has played, and the fact that there is this environment that makes it possible to have an easy to get started and easy to learn environment so that you don't have to install a whole bunch of different things to get started using Python. So I think it was more pronounced  

[00:26:45] Unknown:

in the early years back in the 2000 when   installing   of many for many languages, you would need to install something like Visual Studio   or,   Big IDE or install a build tool chain. And in contrast to that, once you had Python installed, which was relatively easy easy usually or, you know, many systems had it   pre installed. You could just start and get started,   similar to other what we're called, scripting languages like Perl, for example, that   were just there. You could always use them when it was very easy to pick them up and just start getting go get going. And on the other hand,   scripting languages were usually just written in editors.  

Python having a GUI IDE,   I think did make things much easier for beginners than, you know, opening vi or or emacs just in comparison. I think these days with   the Versus code and Sublime Text and   many other powerful and widely available editors. And for Python, for example, PyCharm is very widespread, but there are other great editors and IDEs out there. I'm just not gonna name them all because there's so many. I think the importance of idol in that has become reduced. Also, in terms of interactive environment, I think at the time, IDLE was really the IDLE shell. At the time, IDLE shell was really the only alternative to just running Python in a command line for an interactive environment. But these days we have IPython and Jupyter and few others as well   that are really,   very very good, interactive environments with a lot of features. So I think Idel's shell has be so I think Idel's shell has become much less used, in recent years just due to the,   widespread,  

[00:28:31] Unknown:

availability of great other tools. Yeah. I think that the introduction of Jupyter   as a new environment for getting people started to code has started to consume some of the use case for idle, where it's definitely a little bit more complicated to get running on a local machine. But the fact that there are these web based environments for being able to experiment with the notebooks and incorporate the visual outputs of things like charts and graphs,   maybe is starting to subsume   the user base for idle. But for local development, I think it's definitely still has a lot of value for people to be able to just install Python, run a single command, and then have that editor running without having to think about, well, what editor do I want to use, and how do I get it configured, and how do I get it running with Python?  

[00:29:16] Unknown:

Absolutely.   I mean, with more and more everything happening on the web or in a browser these days, so IDLE obviously becomes,   less popular,   in in this context.   I I still think I mean, 1 of the strong points of Python compared to practically any language is that you can fire up   the interactive,   command line or interactive shell and just, you know, type help something and see or or just try anything out immediately. You don't need to compile it. You don't need I mean, that compared that's also 1 of the nice things about JavaScript. You just open a browser, open the   the console and type something and see what happens. In most other languages that's,   you know, much more complicated to just try something out and see what works. And that's when I teach Python, I always just I try to deflect as many questions as possible with, well, just try it. IDLE is a great environment for that just because   everything   being more graphic and more   easier to understand the colored output and,   the interact the ability to restart the shell without losing your history. It has a lot of nice features for  

[00:30:21] Unknown:

just playing around and, seeing everything. Are there any other aspects of your work on the Idle project or your experience as a core contributor   or the Idle module   specifically that we didn't discuss yet that you'd like to cover before we close out the show? Sure. So I mean,  

[00:30:37] Unknown:

I mentioned that I began contributing to Idle when, I wanted to sort of help contribute back some of the nice features we developed,   for IDLE. And that took a long time. That was sort of my first steps with, contributing to open source. This was much before GitHub or git. This was before   Python even used Mercurial. It was back on SVN with, you needed to post patches to the issue tracker and wait for something to review them. We didn't even have code review tools.   So people manually apply the patches, try them locally, review them, and then just give,   you know, write back on the issue tracker with,   comments.  

That process took a long time. And also I,   wasn't on a I had no previous   experience contributing to open source and this wasn't something that was nearly as common as it is today outside of certain circles like Linux development. So it took a while to understand to understand at the time Kurt D. Kiser was, leading the development of Idol and it took a while for me to understand,   his vision for Idol to keep things simple, to cater to novice users rather than power users.   So many of the features that I wanted to contribute were, well, declined or we had to pair them down or change them to make them simpler or ease more easily discoverable or more newbie friendly,   before they came in. And it took many years, but eventually some of those things like, improvements to the auto completion or the squeezing automatic squeezing of, previous outputs and several other things did make it in. And there are still some such features that haven't gotten in yet. I mean, I've been working for years on the search bar. Idle still uses a very old fashioned search like a find dialogue like you have in notepad. Almost any editing environment these days has a search bar. I think even word today uses a search bar by default rather than opening a dialogue on top of your window. Definitely every IDE I know does this. But in ILE, you still get this huge   dialogue which is very clunky. But sort of getting this working, testing it on all the different platforms,   dealing with all the different edge cases, there's a lot of work. And just getting someone to review and go through the whole process,   it takes a long time. And I think for idle more so than, other parts of Python simply because so few people actually so few core developers work on and so few people in general. So that's sort of 1,   aspect   that I think, is worth highlighting.  

Another thing I hadn't,   mentioned was that in 2004, we had a Google Summer of Code student take part in the Python projects and work specifically on idle. His name is I'm probably mispronouncing this. I'm sorry. Simon Hav Heblikar.   So he worked through the summer and I co mentored him with Terry Rady. Terry actually did most of the mentoring. I, helped here and there. And he did a lot of work adding tests mostly. It was I think it was a big part of his work. But also, he did the most of the initial work on writing the, line numbers,   feature and many other features as well. So he did, quite a bit.  



[00:33:39] Unknown:

And I have to mention my friend, my good friend, Norm Raffael, with whom I served in the military. And he wrote he wrote the code context feature and the call tips feature. And I think he was either he wrote the auto completion feature or he added a lot to it. Alright. Well, for anybody who wants to get in touch with you or follow along with the work that you're doing or get involved with idle development, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks. And this week, I'm going to choose the show mister Robot. I started that recently and have been working my way through the episodes, and it's very good storyline,   a lot of interesting character development,   and they actually do a pretty good job of staying fairly accurate on the technical pieces. So it's always good to see that level of detail in the show because a lot of times, they'll just throw the sort of usual hacker trope of just banging away on the keyboard and having everything start working magically. So it's interesting to see a lot of the social engineering aspects that they bring into the show to try and popularize the way that technology actually works. And so with that, I'll pass it to you, Tal. Do you have any picks this week? Yeah. I have a couple. And as I in educational technology, they'll be,  

[00:34:45] Unknown:

sort of educational   they'll be sort of education related, but they're nice and popular things.   So the first 1 would be the movie Captain Fantastic, which sounds like a superhero movie but it isn't really. I I just won't spoil anything. If you're at all interested in education of children, then you it's a must   watch, in my opinion and it sort of causes a lot of opinionated   responses from people. It'll but at the very least it's thought provoking and interesting. And then my second pick is Paul Graham, of Y   Combinator fame. Recently posted a blog,   post about,   hackable tests, which I found,   I connected to very much. And I think gives,   sort of ties in a lot to how  

[00:35:28] Unknown:

almost all of our education systems are built and how they work. So I recommend reading that. Alright. Well, thank you very much for taking the time today to join me and discuss your experience of working on idle and some of the history   of that, venerable module. So I appreciate all of the work that you've done, and I hope you enjoy the rest of your day. Thank you too, Tobias. It was a great pleasure.  

[00:35:51] Unknown:

Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at data engineering podcast dot com for the latest on modern data management.   And visit the site of pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.