 I did some groups. So I think the first ones are more in the personal area. Chuk is asking, so now you're retired. So congratulations by the way. And she's asking if, what are you planning to do? Are you planning to do some cool things with Python or are you trying to look for more space in other things in your life? Well, actually both. I am very much enjoying retirement as an opportunity to spend more time outside, hiking and biking a lot with my wife. We live in a beautiful area. Within half an hour or an hour's drive are all sorts of beautiful places that they love to visit. If you find me on Instagram, you can see where I went lately. But at other times, I also like to keep my mind sharp by working on new ideas for Python. You have already seen probably the new parser that I introduced with. Okay, I didn't prepare this. Anyway, the new parser was introduced in Python 3.9. And currently I'm working with a few other people again on a match statement, which is proving somewhat controversial, but I think it will in the end turn out to be a very useful addition to Python. Okay, nice, looking forward to see that. So next question is, okay, what other language, what programming language do you like to use? Ah, that's tough, because I really don't like any other languages anymore. The only other language in the past few years, I think the only other language that I've used is pretty much C. And that's only because I'm working on Python internals occasionally, like with a parser, there was a lot of C code for the match statement is actually, there's also a lot of C code that someone else is maintaining that brand. Yeah, when I still worked at Dropbox occasionally, I saw a little bit of Go or Rust or JavaScript. Not a fan of JavaScript, probably just because I don't understand the ecosystem anymore, I haven't really kept up with what's going on in JavaScript and people are now writing incredibly complicated things using React and stuff like that. And I have no understanding of how that works or what you can do with it. Rust seems an interesting language, but I've never ever compiled even Hello World in Rust. I don't think I've ever downloaded the Rust compiler anywhere. Same for, well, yeah, pretty much the same for Go. Okay, nice. Yeah, so you created a language, so it makes sense that you don't want to work in a different one. So... Yeah, I can fly in Python and in all the other languages, I basically, I can fly in Python and C and in everything else, I have to learn to crawl still. Yeah, okay. So I will merge those two questions, but one person is asking, what was your inspiration to create Python? And then the next question, maybe we can put those together, is if you have the opportunity to start Python from scratch now, or maybe to go, I don't know, to get all the knowledge that you have now when you were starting, what do you think it will be different? So it will be, the question is, say it will be more close to JavaScript? And it's also asking if you would keep the gil, everyone is naming the gil, I don't know why. Wow, those are a bunch of very leading questions. I think I'm gonna separate it all out. The inspiration for Python was, well, I've written about it a couple of times, I guess. I actually enjoyed working on a language I had sort of helped implement a few years earlier in the early 80s. And I was writing a lot of C code at the time in, say 88, 89, 90. And I felt that I was being unproductive in the type of applications I was writing. So I was looking around for other options and we had a platform that would make it difficult to say do a port of Perl. Although in the end, if I had spent all the time I spent creating Python, if I had spent that on a good Perl port to that platform, Python would never have occurred. So I would still be living in Amsterdam coding for money. Sorry, I'm losing my voice, I realize. It's okay, take your time, it's okay. But yeah, if I had to start over in 2020 that is one of those crazy hypotheticals that I don't know what to do with. Because if there was no Python in 2020 there was certainly something else. And so I don't know, I can't translate the mindset that made me create Python in 1990 to 30 years later and come up with a sensible answer. If you're saying, would it be more like JavaScript? I hope not. But I mean, I don't know, it's like what if I was born rich instead of poor? Like, yeah, that's unanswerable. And there was some mention of, I think, the GIL and one other specific thing? I was on the GIL, so if you will maintain that. So I will rephrase that question. Let's say you have 128 bytes in a message to send to yourself in 1991. What would be your advice for starting Python at that time? It's a small message, I know. I think I will refuse to send that message because I feel that anything I could say would sort of, through the butterfly effect would change the world so much, even 128 bytes that I would be very worried for a completely different outcome. And I can't imagine what I would have to say to make the outcome better because I would, if I received the message from myself 30 years in the future saying, what you're doing is great and it's gonna be the most optional language in the world or something like that, I don't think I would have been able to handle that. Plus, of course, again, it's a nonsensical question. So I don't know, just ask something else. Next question, please. Yeah, okay. So a lot of people was asking the same. So I would tell you three or maybe put it all together, but basically the question is if you imagine Python running in the web, so as a JavaScript is running now in the browsers. So some, Harald was asking if, for example, is that support to Brighton is something that is in the plans of Python? Or if you think the Python can be a front-end web development language? There was like a lot of questions. Yeah, yeah. That has passed my mind a few times in the last three decades. But every time I considered it, JavaScript was a different language. Like I think the first time I thought about this and people actually built this, believe it or not, in 1995, there was a plug-in that worked in both existing web browsers at the time. Some early version of Microsoft Explorer as well as Netscape, I believe. And there was a plug-in that you could use to run Python in the browser. Nobody even remembers that because it turns out plug-ins were a dead end in the world of browsers. And this was actually, I think that the plug-in here was similar to running Java in the browser rather than running JavaScript in the browser. But nevertheless, you could send a whole program to the browser. The problem was that end users would have to install the plug-in because there was no automatic or easy mechanism to install plug-ins. Plus there was of course entirely an insecure. So smart end users probably wouldn't want to plug that in, to install that plug-in. And then a website developer of course would think twice before they decided to use that plug-in for their website because nobody could look at their website without installing the plug-in. And more recently, you may remember something called Flash, which was also a plug-in you had to install. For decades, websites that were built on Flash would sort of be sort of, there would always be places where they wouldn't run and there would be big buttons that say install Flash and yet half the world would not be able to install Flash until the browsers just came with Flash pre-installed and then became a huge security vector. So that was the whole plug-in model. I'm glad it's sort of gone from the world. The last time I saw a website that said your Flash is out of date or you're not running Flash was five years ago, I believe. Yeah, so then we got to the time when JavaScript embedded in HTML to make sort of things like active buttons and a few other things became popular. And so you would have mostly HTML and there would be like a script section in there where there would be little snippets of JavaScript sprinkled through the page and you would have some kind of dynamic activity in the browser. And I looked at that and I thought, well, could Python do the same? It probably could be made to do the same. There was a problem in that particular model that embedded Python code, like a small snippet of Python as long as it's more than a single expression. If it can be a statement, you're getting in trouble with the indentation. I wouldn't be surprised if people had actually implemented systems like that because as far as I recall, web standards actually supported other languages than JavaScript to be specified. But of course there were no browsers that sort of fully supported anything besides JavaScript. The latest incarnation is actually the most likely one to eventually yield some kind of success, which is the browser has an execution engine. We can translate any language we want to code that runs on that execution engine. The original version of that was just transpile anything you want to JavaScript. Doesn't matter how ugly the JavaScript looks because you're never gonna have to look at it. And now you can do everything on the server side. And so you don't have the problem that users have to install anything new in their browser. That could be done, I believe that some of, I actually have no idea how Brighton works, but I imagine there are some things like Brighton that work that way. More recent refinement of the same idea is WebAssembly, WASM, which I don't know that much about, but it sounds again like something where we could relatively easily and probably someone already has done it as a master's project or maybe a summer of code at Mozilla. Who knows? Just transpile compile Python to WebAssembly and run that in the browser. You can probably, if you wanna be crazy, you can transpile C code into WebAssembly and just take all of C Python and run that in the browser. I don't know how well that would run because it would be very large upload or download the first time you wanna run it. On the other hand, it has some advantages of sort of being more faithful to exact Python semantics. All these sound interesting approaches and it's possible that at some point, something like Brighton or another similar approach will be successful. I think it's too soon to tell. I don't know that it's necessarily the sort of the core Python teams task to look into this. This is something that anyone with sort of good knowledge of the target platform, namely a browser running WebAssembly or a browser running a modern JavaScript engine can figure out how to do. Okay, nice, thank you. Yeah, WebAssembly looks super interesting. Okay, let me move to the next question. We have a lot of live, I want to wait a few minutes for that. Ram is asking for, if you can share your feelings about the PEP 622, the pattern matching PEP. Sharing feelings. Oh, I'm not all that great at sharing feelings. My current feelings around that PEP are in part a sense of relief that most of the hard work of designing and even implementing pattern matching and sort of looking at all the possible ways that it can be implemented and looking at all the use cases and sort of looking at how it is best told and how to solve all the various constraints of making it sort of Pythonic and making it sort of powerful enough and making it useful. We've sort of done all the work and that's behind us. More recently, I was really upset by a lot of feedback that came from the core dev community about that PEP. It was not fun to sort of see threads with the subject, the anti PEP. Should we perhaps have a way to write a PEP that explains why a certain other PEP should not be accepted? And it was very clear what this was about. And other people that are very smart and whom I respect tremendously sort of putting all their effort into sort of tackling this new proposal and explaining why it is un-Pythonic and a bad idea and should not be done with them. And all in as far as I can tell, very sort of subjective emotional ways where it's hard to reason when one person's position is this is easy to teach and another person's position is everybody's going to be confused by this because we just don't have data to decide an argument like that. And so what you get is that sort of the person who shouts the loudest gets the biggest audience. And that sort of, I don't know, I feel I still have a pretty decent intuition about what sort of, what kind of language features fit well into Python and are generally useful and how to use them and how to design them. And so I sometimes just feel personally attacked when people who I see as clearly less experienced in language design and sometimes like utterly failing in language design come up with counter-proposals that are so poorly thought out that I don't even know how to respond to it except by saying, this can never work. So the PEP is currently in the stage where I sent it off to the steering council and the steering council has been very busy because they've been distracted by some other topics. But hopefully in the next few weeks, they will have some time to think about this and how they want to review it possibly. I mean, for me, the best possible outcome would be for the steering council to pick some developer who is somewhat friendly to this proposal to sort of review the PEP and decide where it needs more work and whether certain design decisions that are not set in stone can need to be changed. But it's possible that the steering council decides that this is just too big of a change and they don't want to get burned by approving it. Okay. Okay. Yeah, there was two different persons asking almost the same so I would pick one. So the question says, we've grown language support for even loops in the past decade, like it was for legal progress, stealing progress. And the question is, where do you feel the Python language stands in regards to concurrency primitives? And what area do you see the language moving more towards go with the sub interpreters or more towards the async await place? So, and there was two different persons asking almost the same like sub interpreters versus async. To be honest, I don't think that sub interpreters solve the problem with concurrency. Because they only solve it by placing a complete barrier between each sub interpreter. So there is not much gain to be made between compared to just forking multiple processes. And in a sense, sub interpreters are less robust because if one sub interpreter experiences the hard crash, the entire group of sub interpreters running in the same process will necessarily have to be terminated. Well, if you have a number of processes that they're all working on a problem in parallel, if one of the processes fails, the other processes, if you've designed things right, can continue and you can just restart the process. So I don't know that sub processes are really solving the right problem. They are definitely solving some problems but the problems are not so much in concurrency, I feel. They are more about larger applications embedding Python and sort of being able to have independent Python interpreters for sort of different parts of the embedded application or maybe there are different libraries that are combined together that each have a completely different independent use of Python. But for concurrency, yeah, I'm also not optimistic about getting rid of the gill, at least in the sort of every solution that's been tried and people have been trying for two decades at least. Every solution has sort of slowed down the single threaded performance dramatically because you end up having many finer grained locks. It is possible that a complete redesign of the Python interpreter really from the ground up made for concurrency could sort of have different performance characteristics. But that would be an enormous task that I think only private capital could fund that. And it's very unclear that much would come out of that. Okay, okay. So I want to ask the last one from my list because we already have 24 from the public, I think. Yeah, no, I'm not going to ask all of them. So the last question from my list is Shao-Marco from Brazil. He's asking if there is a plan or there is a program to engage, to introduce more people to the core developers team. So he was saying we love Python but Python doesn't fall from the trees. We need more people to order. So what's the plan and what's the program for that? The steering council is very aware that we're not attracting new core developers in sufficient numbers. So I can't speak for the steering council because I'm no longer a member. But I know that when I was on the steering council last year that this was also an important topic that we were thinking about. It's not an easy problem because it's sort of, it's one thing to get people to easily contribute a simple fix for a simple problem. I mean, that's hard enough. If you sort of, if you fix a one line bug in some C code that's part of CPython, you have to sort of go through a whole number of steps just in order to be able to compile and test your changes. We have developer guide that talks people through that in great detail. It's still not always easy to follow because of course people come into this with such different backgrounds. Some people are very experienced in open source development, just not in the particular workflow that Python uses. Other people are experienced C coders, but they have no idea of how Git works or I mean, we see a fair number of bungled pull requests from beginners who make some classic Git mistake and they do an incorrect merge and now they have 500 commits in their pull request that shouldn't be there because they didn't write those commits and this usually sort of causes 30 different core developers to be auto registered as reviewers. So anyway, the workflow is difficult but the other part of the problem, I mean, the workflow can be learned. We can also simplify the workflow to some extent. I don't think we can really sort of stop people from making basic Git mistakes because there are enough Git tutorials that explain how to do it and people just don't follow the tutorial because Git is so random. But sort of attracting people who are able to sort of take in this large amount of C code and Python code, of course, that is C Python and the standard library. It's just difficult because you can feel very productive by fixing some issues in one module but that doesn't teach you much about how some other module works and there is a huge amount of history and a very great concern for backward compatibility and you have to sort of be aware of the philosophy of sort of what kind of things make sense to add and what things don't. Like this morning on Python Ideas there was a little discussion about a new variation of the wrapper function that would take an extra parameter that basically tells it how much work to do, I guess, how large an output to produce and there was immediately debate about whether that was better to, it was better to do that as a third party library or whether that was really something that ought to be built into the language and there were immediately strong opinions on both sides of the argument. So it's just it's a difficult project and part of that is just because it's a very large mature piece of software that has to move carefully and slowly and you have to attract people who sort of are interested in working on that. That said, I mean, we have successfully attracted new developers, some with sort of very specific skills. We've also attracted new core developers who don't necessarily want to help out with the C code but are useful in other areas like documentation or workflow or issue triage. So we are trying to get more people involved for sure. And if you don't always see where to start, maybe part of that is that we're looking for people with a certain level of experience. So that means we can't teach people how to code in C for example. So if you can totally be a core dev and not ever touch any C code but you still have to sort of know a lot of other stuff and you'll eventually have to work your way around the C code. Okay, thank you. Nice. So let's move to a live questions. This one is easy. People are asking if you have ever met the Monty Python crew. Sorry, what was the last word? So if you ever meet the Monty Python crew, so the Monty Python crew. Unfortunately not. I'm a big fan of John Cleese but I've not come closer than following him on Twitter. Okay. What do you hate the most about Python? What do I hate most about Python? Yes. Nothing comes to mind. Sorry. Yeah. So I don't know if I want to ask this question but it has a lot of words. So what would you like to introduce to Python 4 and when do you see the switch happening? Well, I think that the general question is people are fearful about Python 4 because they remember the Python 3 transition and how we were not prepared and all that. I see two things in the future for sure. One is that Python 4 is a long time in the future if it ever happens because we're happily planning 3.10 and we can go all the way to Python 4 because we can go all the way to Python 4 and we're happily planning 3.10 and we can go all the way to 3.99 before we, well, then we can just go to 3.100. So there's no reason to switch to Python 4 and I know there are a few peps that still mention Python 4 as a possible time frame where certain things will change or become the default. That basically means never. If and when there is a Python 4 whether that is in 5 or 50 years my expectation is that we'll sort of spend an enormous amount of time working on transition strategies that are actually practical for real users in the Python community. With Python 3 we definitely thought about transition strategies but we misinterpreted how many Python users there were and what their skill levels were basically. We thought that everybody thought was sort of as interested in making their Python code better than they typically are. You can look up my talk about that topic at PyCascades a few years ago. Victor Stinner also gave a nice talk about this topic. If Python 4 ever happens if there is a reason to somehow break backwards compatibility there will be a very different approach to sort of how to maintain compatibility. And it's possible that in the end we'll actually declare something Python 4 for a very minor backwards incompatibility. It could be that like removing the guilt changes semantics of multiple threads enough that even without any other explicit API changes, if all the API and everything, all the objects worked exactly the same as they do in Python 3. The only difference was that the guilt was removed. We might still have to declare it Python 4 because in practice the guilt sort of causes certain performance guarantees even though you may not always like them, but actually in some cases you will like them. And it will just be sort of tricky for people to upgrade. And so I mean that's just a random hypothesis. It could be something completely different too. It could be that we're using a different approach to the C API. I mean there are a couple of new approaches there. There is a basic API that is smaller than the traditional C API. There's also a handle-based API under development. So maybe at some point we'll declare something Python 4 not because the language has changed, but because the C API has changed. And that is what keeps the ecosystem together. So that's again not a thing to say, ah, yeah, one or two extension writers have to change their code a little bit, but everyone else is safe. No, it would mean that the entire scientific Python, the entire data science machine learning world would have to produce new wheels at the very least and probably update their code significantly. So that's like not something we can do in five years. That takes a decade. So basically I'd say Python 4 is not happening anytime soon. It's not something to worry about. And it's going to feel very different than the Python 3 transition. Okay, thank you. Next one. So, people are asking what's your favorite book? Or maybe you can pick one. I don't know if you have only one favorite book. I have lots of books that I read and I sort of after I read a book I forget it again until I see it again maybe. One book that I've really, really enjoyed reading when it came out, I think well over a decade was Anathem by Neil Stevenson. Okay. Neil Stevenson in general is one of my favorite authors and has been for a long time. I think I've read almost everything that he's written. And Anathem for me was the most fun to read. I think of everything he's written. Okay, thank you for recommending it. I'm going to pick this one. It doesn't have a lot of all those shots because I'm selecting the questions. There is a piano in your teacher or it's a piano pattern and it's maybe that you are learning how to play the piano or is it something that you are trying to do? I'm sorry, I'm not following. The question is you have a piano pattern in your T-shirt and the question if that is a clue of a new hobby that you have that you are maybe trying to learn. Oh, my T-shirt. Ah, no. The T-shirt is actually a secret message. This T-shirt was printed by Dropbox a few years ago on the occasion of Black History World. And I believe that the story was to get the T-shirt you would have to donate $10 to a designated charity. So I donated a bunch of stuff and I got a T-shirt and it said I'll stand up so you can see the whole thing. It really has very little to do with piano. It's just about sort of different colors and diversity. I'm color blind, so probably I'm not going to guess the secret. There's not more than that to it. Thank you. Okay, we have a few minutes, not a lot. Do you think that my pipe will become part of the standard law? Yeah, people sort of have been very hopeful about my pipe. I don't think it's a good idea, actually. My pipe is a piece of code that like any other linter it has a very different development cycle and so I think it's a good idea. I think it's a good idea. I think it's a good idea. It has a very different development cycle and sort of fixing sort of tying my pipe's development to the standard library would sort of slow down my pipe development tremendously. So I would really much rather keep it separate because otherwise you would basically not be able to get new my pipe features with all python versions. It's possible that what people really meant by my pipe is some form of static type checking built into the interpreter. Again, I think that's not likely going to happen because the language is sort of allowed by the type system specified by pep484 and the follow on peps is actually less powerful than the full dynamic language and python is a dynamic language and I think it should always stay a dynamic language and sort of static checking definitely is an important tool that everybody who is writing more than a thousand lines of python should probably be familiar with and having their toolkit but at the same time it's one of those tools where you have to be able to turn it off or use a different tool or sort of its use needs to remain truly optional and if you have a corner of your application where static type checking makes no sense or just slows you down or maybe what you're doing is could be statically typed but it would require a significant expansion of the static type checking of the type system that MyPy and other checkers support that alone would be a good reason to sort of be careful here. There is still, there is a pending pep612 and there are probably going to be some follow up peps as well that try to deal with for example type checking applications that use NumPy arrays where you have operations that sort of require two inputs to have the same size or to have the same size in a certain dimension or to have the same dimensions there are all sorts of combinations and the current type system cannot express that at all so it's essentially way too early, way too soon to even try fitting everything in there so I think the dynamic side of the language needs to be ahead of the statically typed set subset. Okay, so we are on time now so I'm going to ask you the last question and I was saving this one for the end so Kanaq Kavadi and I probably mispronouncing that name so this person is saying Gido you are such an inspiration to me and all of us I'm sure both life and career for a young developer or a young software engineer like me and I knew that one would be coming and I don't have a path answer to sort of that question it's like my approach was and you should probably if you haven't ever read that blog post by me I wrote something called Kings Day Speech just Google for my name with Kings Day Speech and Google will certainly find that blog post for you that's the most inspirational story I've ever written I believe my approach and I was incredibly lucky that it worked out so well was make sure you have fun join the project that looks the most interesting and most fun to do and sort of prize that over what is perhaps the most lucrative or I don't know there are many different ways that you can evaluate jobs if I didn't want to do something I would not do it if I wanted to do something that other people didn't think I should do I might still do it after all that's how Python came into being at the same time sort of I've been looking back at my life and I would say I definitely worked too hard 30 years of being successful have not been great for my family I've sort of spent every day in the office and then every night I would be spent in many hours every weekend or most weekends I would be spending still keeping sort of thinking about Python stuff and sort of that level of taking your work home with you I don't think is good so have fun but make sure to sort of let yourself be distracted by other aspects of life besides work and yeah so we are on time so that was all I'm going to play some songs so you feel like