 Thank you, everyone, for coming in. So I'm very happy to present Gukesh Langa. So he's not only an amazing person. He's also a Python core developer and our release manager for Python 3.8 and 3.9. Probably he will tell you more about that. So with all you, Gukesh. Good morning. This is my 21st public conference talk on my first keynote. So I thought, I'm going to use this opportunity to get a little personal. And through that lens, inspire you to make the world a better place by contributing to Python. The talk will go roughly as follows. I'm Gukesh. I'm bad at math. I used to stalk Michael Ford when I was younger. And it's all pure luck anyway. You can contribute to Python, just like I did. But Python is not the same as it was when I first started. But maybe that's a good thing. Where are all the new developers hiding these days? And shouldn't we be writing JavaScript anyway? So this is how this will go down. Let's start at the beginning. I'm Gukesh. 10 years ago, I didn't have my comet bit yet. And 15 years ago, I didn't even know Python existed. Today I'm a Python Sutter Foundation fellow. I'm the release manager of the two versions of Python that are in current development, which is Python 3.8 and 3.9. Then I authored and co-authored 11 peps to date. And last year, I started like a pet project to scratch my own itch, which is called Black. It's an opinionated Python code for a matter. Anybody here heard of it? So thank you. Well, job-wise, my biggest two employers were Allegro in Poland and Facebook in Vancouver, British Columbia, Menlo Park, California, and London, here in London. Well, I used Python at both companies. Specifically in my five years at Facebook, I helped migrate a few million lines of code to Python 3.6 at the time. You might have heard of a particularly fun part of it in Lisa Gwoz and Huiding's Instagram keynote at Python US 2017. But 15 years back, I didn't know Python was a thing. I was a terrified computer science student at Polznan University of Technology in Poland, struggling with linear algebra in particular. In fact, I was doing so badly that I was faced with a final exam retake. If I failed this one, I would be kicked out of the university. So obviously, I studied hard for this. I didn't want that to happen, but the subject matter was way over my head. I felt much more comfortable with high school math. That fit my brain. Well, so I went through an entire book of exercises to ensure that I'm going to pass this time. That book listed answers to problems at the back, which was very helpful, but a set of extra difficult ones marked with an asterisk were left out. So I knew these would be the ones on the exam, right? And lo and behold, the day before the exam, my friend told me, hey, I'm using a Ruby script to check that the answers are correct. Well, it doesn't show you how to achieve those answers, but at least you see whether the numbers are the same. So I got really excited. He shared it with me. I felt really relieved. I got back home. I downloaded a Ruby installer. I clicked Next, Next, and it crashed. I found another version, and Next, Next, and it crashed. And so with a few more versions, so at this point, I had to claim defeat, and I got really desperate. So I literally typed in Google Ruby alternative. This is how I found Python, and that installer worked. Well, soon after I was following a Python tutorial, trying to convert my friend's script from a language I didn't know to another language I didn't know, as any reasonable student does when faced with an important exam the very next day. Astonishingly, it kind of worked. I kind of managed to kind of convert enough of the script to kind of confirm my answers were right. So I got relieved, and the next day I passed the exam. Had the Ruby installer worked that crucial day, I would not be here today. As most other major life events of mine, that was pure luck. And this is something I strongly believe in. But all successful people owe a lot to chance. More than most of them would care to admit. But as Kent Beck, whom I used to work with, says, if you want to win, you need to play. Quit yelling from the stands and get on the field. Make a prediction, see what actually happens. So a few years later, still at university, I worked on a research project for the Polish equivalent of the Scotland Yard, programming Italian microcontrollers with GSM and GPS functionality. Amazingly, they were programmed with a bastardized version of Python 1.6. So I badly wanted to spread the knowledge that it's incredible to program hardware with Python. What you need to understand is that it was 2007. That was five years before the release of Raspberry Pi. So I responded to a call for proposals to my first conference. The talk didn't go well. By the end of my slot, I was roughly halfway through my slides. And I attempted live coding, which went particularly bad. That section was as awkward as it gets. People started sending live text messages to the phone number of the microcontroller they saw on the screen. So Michael Ford was in the audience. He was also there talking about Iron Python at the time. Is he in the audience today? He's at the event. So say hi to him if you see him later. I asked him for feedback. He took me aside and, hey, he gave me some of the harshest feedback I've ever received. But it was accurate and helpful. So thank you, Michael. Two years later, I attended EuroPython in Birmingham. That was my first international conference. And Michael Ford, pictured here, was the only face I recognized. So naturally, I shamelessly followed him around. In fact, you have to believe me that this guy right here, that's me. More importantly, I had no idea what sprints meant. I thought they were a mandatory part of the event. So I booked my travel and booked my hotel to just attend all days of sprints. I didn't know what they were. And Michael, at the sprints, was the only person I knew. So he helped me with my first attempts to contribute to Python. That particular sprint was not very productive in the end for me. I'm sorry, Michael. I wasted too much time on SVN, too much time setting up my environment so that the right libraries were there so Python even builds. But that experience taught me a very important lesson. Sprints are amazing. You get to work with actual maintainers on actual problems with their software. You get to see actual development done in practice live. And you have experts on hand to nag about your new problems. This is something that you could not buy even if you wanted. So even though all of this was pure chance for me that I even stayed for the sprints in the first place, and it was kind of in large part naivete on my part, it was enough to inspire me to come back the next year. And that time I came prepared. And a few weeks later, I got my comet bit. So you have to show up. But if you are already on your feet, helping newcomers might have tremendous impact on their future lives. I know it had on mine. So you know what? I wouldn't be here today without Raymond Hettinger, without Guido van Rossum, Fred Drake, and Georg Brandl, all of whom spent tens of hours with me, both in person and online, sometimes at very inconvenient times of day due to time zone differences. And I will forever be in their debt. Today on the release manager, if I could do it, you can too. But there's a snag. Many core developers rightfully mentioned that following my footsteps as I described them will not be as easy as it was for me. Python got much bigger now. It has to be much more stable compared to 10 years ago, and got much more complex as well. In other words, most low-hanging fruit already picked. What's left is maintenance of an increasingly fossilizing interpreter and standard library. That kind of maintenance is both tedious and tricky, especially for a dynamic interpreter language like Python. With compile languages, you can compile a program with an old compiler, and then it runs on new boxes just fine. With Python, you write your program, and maybe it won't run on next Red Hat. You don't know. Python is the biggest community-run programming language on the planet. Other programming languages with similar or larger market penetration are run by corporations, either single corporations or committees of multiple ones. Being a community project is both a blessing and a curse for Python. It's a blessing because it's truly free. It's truly free from shareholder pressure and market swings. So it's going to be there for you in 10 years and 20 years. I should know. I'll be releasing versions of Python 3.9 for you all the way to 2025. Well, but being a community-run project is also a curse. Almost the entire core developer team is volunteering their time and effort for free. While the Python Software Foundation is graciously funding infrastructure and events like PyConUS and the annual week-long Python core sprint, it does not currently employ any core developers. Since there is both Python and software right in the name of the foundation, I want this to change. If you don't pay people, you have no influence over what they work on. Core developers often choose problems to tackle based on what inspires them personally. So we never had an explicit roadmap. There's never been a roadmap where Python should go, what problems core developers should focus on. To be fair, I have to mention that, you know, as long as we had Guido as the benevolent dictator, he did most of the vision work himself. He ran many projects personally. And behind the scenes, he sparked inspiration in core developers to do other projects that he found are important. But more importantly, he stopped proposals quickly for things that he was dead set against so that Python could stay consistent with what he saw as being Pythonic. But this is very hard to maintain as a single person. It's a very hard task and you need to work with people and, you know, agree and disagree. So today, Python is no longer governed by a PDFL. My personal hope is that the steering council will be providing visionary guidance from now on and will present us with an explicit roadmap for where we should go. I'm not on the steering council. In fact, the release manager position is a bit of a misnomer. What I am actually managing is the timely release of source tarballs and with help of Ned Deely and Steve Dower, binaries for Windows and macOS. So I have no say in what goes in and what people choose to work on. The only thing I can do is if they land their changes too late or if they are too disruptive because they're incomplete, they have bugs or they're backwards incompatible, I can decide to revert those. But as anybody who wants to keep working on a team, like, you will not use that hammer very liberally. So I'm not on the steering council. But since you're already here listening to me, let me share what I would like to see happen to Python anyway. Before I get there, let me reveal that I wasn't completely honest with you all along. Ah, I kept using the word Python. But what I really meant in most cases was see Python. The reference implementation of the language, the reference interpreter written in C that most of us are using for their day-to-day Python needs. The snag I described earlier applies to see Python alone. That's the interpreter that is run by a team of volunteers with an insanely important focus on backwards compatibility but a focus that is in many ways crippling. That see Python is gonna be maintained for decades but drastic changes are very hard and thus unlikely. Because of that, I would argue that if Python stays synonymous with see Python for too long, we'll be in big trouble. Why? Because see Python is not available where developer trends are shifting. For web, the lingua franca is JavaScript now. For the two biggest operating systems on mobile, we have Swift, the modern take on Objective Z and we have Kotlin, the modern take on Java. For VR and AR and many 3D games, we have C-Sharp provided by Unity, a tremendously popular option. Python is also slowly losing ground in the field of systems orchestration that was very close to my heart where Go is gaining traction. Open stack used to be all Python. Perhaps if not the rise of machine learning and artificial intelligence which were unforeseen by the core developers, Python would have not survived the transition between Python 2 and Python 3. So we got really lucky there. What if you think that what I just said is like sad, negative, depressing or fatalistic? Well, think again. In the 2018 developer survey ran by Stack Overflow, we learned that Python is the third most loved programming language out there. Better yet, it is the most wanted language by far. People want to use it. So why aren't they using it? Well, let's look at another result from the same survey. It looks like we're already the seventh most popular language in use, but looking above, it becomes plausible to think that providing a clear supported and official option for client-side web is what Python needs in order to satisfy the legion of people that want to use it. We are already the fastest growing major programming language after all. That's an article from 2017. I recommend reading it if you haven't seen it yet. Among other things, it says, with a 27% year over year growth rate, Python stands alone as a tag that is both large and growing rapidly. So see, Python is doing just fine. But for Python, the programming language to reach new heights, we need a new kind of Python. And this is where you come in. Truly tremendous impact awaits. And I'm serious here. For a new runtime or a new compiler unencumbered by the constraints of C-Python, targeting a new trending platform, this can become career-defining work. You will make the world a better place that way. At face value, what I propose is crazy. There were many unsuccessful attempts to create a new Python runtime after all. Don't I know it? Do you remember this picture right here? That's the Python VM panel at EuroPython 10 years ago. From the left, you can see Carl Friedrich Bolz from PyPy. You can see Mark Shannon representing HotPy, which is now a defunct project. He's a C-Python core developer. You can see Michael Ford representing IronPython, now a defunct project. He's a C-Python core developer. You can see Frank Wierzbicki representing Jython, now a defunct project. You can see Georg Brandt representing C-Python. Georg is no longer active. We miss you, Georg. And then you have Damien Dieter and representing Crosthwein, again a defunct project. There's a few people missing from this picture. You could add maintainers of Unlaid and Swallow. You could add maintainers of Piston and a few others. In fact, the only two runtimes left of this picture are C-Python and PyPy. And PyPy is an amazing project. It tries to be bug to bug compatible with C-Python. And that is still too hard for many users to consider switching from C-Python to PyPy. In fact, I spent a week in Düsseldorf in Germany this winter at a sprint that PyPy was running. I met a lot of the core team. They are wonderful people. You should meet them, and you should listen to them. I got a commit bit myself. It seems like PyPy gives out it rather liberally. I solved a few Python 3.6 compatibility issues, so I guess I'm not entirely ashamed of getting that commit bit so fast. But I learned a thing that in hindsight is obvious, but I never quite thought clearly about it before. PyPy is known to be the implementation of Python written in Python, but it's written in Python 2. It's one of the most complex applications in the industry written in Python 2. What that means is that without a tremendous investment, it is very unlikely to ever migrate to Python 3. It is just too complex, especially that. Those people are very clever. There's plenty of metaprogramming, so Python code generating more Python code, which then is translated to C and then compiled to native code. So PyPy will have to keep Python 2 support as long as they want to be able to bootstrap themselves, which they want because it's our most performant runtime that we have for Python. Trying to replicate C Python bug to bug with all its behavior and all the standard libraries super hard. And I'm skeptical of new developments for C Python replacements. Without a multimillion-dollar investment over many years, I don't think that's feasible. But areas of modern focus where Python currently has no penetration. I already mentioned mobile, client-side web, VRAR. All those don't require full compatibility with C Python. Do you really need your C extensions on your mobile web browser? Probably not. And that is good news, since Python has many features that are hard to optimize and make static analysis and thus IDEs fail. So there's no time now to enumerate the entire laundry list of Python features that I think is plausible that we could feasibly simplify, given a new platform. But let me show you a few examples. The import system is a very complex beast. It describes how modules are imported. It describes how packages, namespeed packages work. It describes search. It describes a runtime writeable, module cache. Finders and loaders, including how we find modules and packages on the file system and sys.path and stuff. But also how you can write custom ones that run your modules from a database memory or you name it. Import hooks, metapath, I could go on. But do we really need that on web or on VR, on mobile? What people want on mobile is to just go to their app store, click install, and have their small binary quickly load over their 3G network somewhere in rural Pennsylvania. So do we really need that on web? No, like people want, again, to have a small application so that their website runs fast and has a fast time to interact. In fact, one of Go's claims to fame is that they ship static binaries. So we only have one file. You can choose to still use containers, but you don't have to. You don't have virtual ENVs. You don't have pip installs. You don't have environments that you have to orchestrate being created and then turd down. exec is, again, like a feature of Python that provides tremendous value, but for a price. Many people now consider it as an anti-battern. They don't want to see it in their code. If any user-controlled input ends up in exec, that's a security vulnerability. But even if not, it obscures what is happening to your code from humans and static analysis. And it's very tricky to make that performant. Metaclasses are a way of extending the idea that if we already have dunder new and dunder init to control how we instantiate objects, how about we had a way to control how we instantiate classes? Python is using metaclasses internally a lot. And third-party libraries and frameworks like Django are utilizing it as well. But again, it makes it hard to see at first what Python is actually going to do when you are interacting with your class, which also defeats much of static analysis and is a form of indirection making things slower. Parts of the data model in Python are very dynamic, which might not be necessary. The scriptors are away for an object to control how it behaves when it is an attribute on another class. They were added in Python 2.2 as part of new-style classes. And in fact, part of their motivation was to simplify how C Python is implemented. And now we have properties, class methods, and super actually using the descriptive protocol themselves. But it's also a generic way for Python users to write powerful class and object behavior. But again, it's indirection. And indirection equals bad because it's slow. And it also makes it harder for us to see the shape of our objects. What is the shape? Well, many programming languages rely on the fact that they know what a given object provides as methods and as attributes. And using that knowledge, they can optimize how an object is preserved in memory, making them smaller and making attribute accesses and method calls faster. In Python, everything's mutable. So we can add and remove attributes. But at a given point in time, we can add and remove methods as well. But did you know? Since Python 3.7, modules support Dunderget other. We support it so that you can customize module attribute access. And we already supported customizing Dunder class since Python 3.5. What that means is you can take a module object and set its Dunder class attribute to something else. What? What did I just say? Like, you can lie about what class a given object is. Yes. And it enables pretty advanced functionality. In fact, Mercurial uses it for plugins, a few others as well. So you know what? It feels like it's useful for some advanced cases. But it makes it very hard to see what is happening. And it makes alternative runtimes very hard to write. I could go on. The point is starting out with a familiar subset of Python for the user that looks like Python would simplify development of a new runtime or compiler a lot and potentially would even fit the target platform better. Don't believe me? Look at MicroPython. A single programmer, Damian George, started development on it from scratch six years ago in Australia, funding his work with a Kickstarter campaign. And now it's a surprisingly compatible runtime for microcontrollers that have very little memory and by very little, I mean 16 kilobytes of RAM and 256 kilobytes for code memory and minimal computing power. It finds tremendous uses as a teaching platform in the BBC micro bit that you for sure heard about and other fruit circuit playground and a few others. But also production use in home automation and MIDI controllers and game consoles like Pew Pew. I'm hearing it will be distributed to Europe Python attendees this year. I highly recommend getting one. It's great fun. And the creator of it is a friend of mine. I know that he cares about it really much. So for correctness, I should mention that some of the use cases I talked about are powered by a friendly fork of MicroPython called Circuit Python that is focused on teaching more. It has like a list of innovations, one of them being if you connect your piece of hardware to your computer, it just appears as a thumb drive. And if you edit your files and save them, it restores your hardware so you can see what you just did right away, which provides like an amazingly short feedback loop for what you're doing. But more interestingly, I kept talking about ways in which CPython could be simplified to make other platforms easier to develop for. And Europe Python, oh, Europe Python. MicroPython has a list of things that it decides not to implement or implement differently. Some of them are just restrictions of what you can do when faced with a very tight programming environment. But some of them are just decided because of either developer efficiency or because they just fit the user better. Amazingly, MicroPython is still an interpreter. When you connect your device over USB, you can hit Control-C and then get a familiar ripple. That's impressive. You can, for example, run DER on the board module to get available pins on your circuit board. And how cool is that? But will you need Control-C on your client-side web application running on your phone? I guess not. Instead, we need a compiler for web. We don't need an interpreter running on top of the web platform. We need something that compiles your Python code to the web platform directly. That means you cannot achieve full CPython compatibility from the get-go. As CPython enables plenty of dynamic runtime behavior, some example I listed before that I think we can probably do it out. But there are things we cannot do it out. To be viable for professional production use, Python on the web must not be orders of magnitude slower than the default option, which is already better supported, has better documentation training, and is the focus of the developers of the browsers. Same for mobile, and especially on an increasingly popular intersection that I kept mentioning, which is the mobile web browser. Very often when people think of mobile, they think of their beefy laptop running Chrome or Firefox. But what you should really be thinking about is your phone in your pocket. You don't want your Python program to drain the battery on this one or make the device unresponsive. Thus, a compiler. That's a hard path, but in my opinion, that's inevitable. Luckily, there's some prior art that we can either improve, adapt, reuse, or maybe just take inspiration from. There's Nutca, there's Scython, there's Theano, Shedskin, there's Python, there's Numba. They have different focus, but they all implement roughly the idea I'm talking about. But the one I wanted to focus for a moment is MyPyC, the probably the newest player in town. What MyPyC does is it takes modern Python 3 code, which is type annotated, and generates fast Python C extensions. So C extensions for C Python. But it is already used in production for MyPy, the type checker, making it four times as fast. That's plenty impressive. What is even more interesting is that MyPyC to achieve its performance metric and to make this entire compilation thing viable already describes that it was going to work for a subset of Python. A Python language variant that is called strict. Some of the things that it says is type annotations have to be enforced at runtime, have to be correct. But it also says classes are compiled without dunderdict, which is a hash access to find your attributes, which again, indirection bad. So obviously they do that. When monkey patching doesn't work, you think, oh, isn't that a good thing? Monkey patching obscures what is happening. It is an anti pattern. We should not be using it. But really, you are using it. If you ever write unit tests with the mock module, mock's patch is monkey patching. So how would that work? Well, the compiler would have to be a bit smarter and recognize use cases like this to allow them in very constrained environments. But for everything else, we don't need monkey patching. And in fact, it's better to not have it. Instance attributes won't fall back to class attributes if they're undefined. And meta classes that I already mentioned are not supported. So it's not just a theoretical thing that I mentioned. See, Python is an interpreter. So it runs an eval loop over opcodes that you've got, for example, from a PYC file. And it then dispatches what to do just in time. Very often delegating behavior to Dunder methods or some hash lookups, the compiler should not just inline that eval loop into native instructions that are executed one by one, because that is just a worse version of a full-fledged interpreter. It's just better to retain the interpreter in that case and have all the flexibility. But what I'm talking about is a compiler that moves as much of the special method handling and hash lookups from runtime to pre-compiled as possible. If you expected, I would now reveal I have one running, I have to disappoint you. Between the release manager position, black family, and unrelated hobbies come talk to me about analog synthesizers. I have little time for a big project like this. But what about you? What about your organization? What about sponsoring such effort? Could the PSF fund that? Maybe we need a Kickstarter campaign. I'd be happy to be on a team paid to work on a thing like this. But what if you want to work on CPython? Well, I'm not saying that CPython is a dead end. It will forever be an important runtime for Python. Probably the dominant one, it's the reference implementation. New people are still both welcome and needed. In fact, Pablo Galindo Salgado just got his commit bit last year, and he's already more impactful than many long timers. So no, CPython is no dead end. However, working on CPython today is different from working on it 10 years ago. The runtime is mission critical in many industries, which is why development must be extremely careful. That way, we reach the final point. To be honest with ourselves, we have to ask if maybe it's OK for Python to not be available on those newfangled platforms. Well, I strongly believe that enabling Python on new platforms is important work. This is Alan Kay, the pioneer of object-oriented programming and graphical user interfaces. One of the things that he said in a talk given a few years back was, one of our many problems with thinking is cognitive load, the number of things we can pay attention to at once. The cliche is 7 plus minus 2, but many things make it even less. We make progress by making those few things be more powerful. This is one of the reasons mathematicians like compact notation. The downside is extra layers of abstraction and new cryptic things to learn. That's the practice part of violin playing. But once you can do this, what you can think about at once has been vastly magnified. Python is an extremely expressive language. When I first started, I was amazed how much you can accomplish with just a few lines of code, especially compared to Java. But there are languages even more expressive and enabling even more compact notation. So what makes Python special? Python is runnable pseudocode. It reads like English. It's very elegant. Etzger Dijkstra said that elegance is not a dispensable luxury, but a Q-quality that decides between success and failure. Well, I would like to agree with them. But in my experience, convenience all too often wins out over Q-quality of experience. So our responsibility is to make our runnable pseudocode convenient to use for new programmers. Because when it is convenient to use, it is very popular in teaching. Let me give you just two examples. Here's a room full of musicians figuring out Python for the first time. They're musicians. They are making their software synthesizers play using CircuitPython's capabilities. So they're programming a microcontroller to play notes on their software synthesizers. That was at Mocfest this year in North Carolina. It's a music festival. People were amazed that at the same day, they learned how to program hardware and learned about Python. And they could be productive from day one, just like I did on my first day with Python. Let me introduce you to another guy. That's Stanley. That's my son back in 2013. He was five at the time, trying his first steps with a troll module on a Raspberry Pi that I got at PyConUS that year. I will always remember his pure joy when he by himself made the troll go where he wanted. Now he's almost 11. We still have fun with Python, mostly with the Pew Pew console. But if his first programming language, one, he uses now on a tiny piece of hardware that costs eight pounds, would be directly applicable in his later life to use at his job. That would be incredible. We, the current generation of software developers, could make those future lives easier and so much better by bridging the gap between the micro bit and production mobile devices that everybody is using. And we could also build some job security for ourselves. And that can't be a bad thing. But we could really enable a future generation of software developers. And maybe one day, at their own conferences, they would say, if I could, you can too. Thank you very much. Well, we have some time for questions. All right, while compiled to web, what about back-end developers? What about scientists? Oh, we already covered those cases pretty well, I guess. We have CPython, and that works tremendously well. If we make PyPy better so that people can more easily migrate to that, that will also become more popular. So I guess the platforms that we already support, we just need to improve those. And that we can do gradually. And the core team is doing that for CPython. But many new users of computing don't run servers themselves. They don't have a laptop. They don't have a stationary PC. They only have an iPad or only have a phone. So this is a place where Python does not exist at the moment. Very interesting. Thank you very much. There's this project by Mozilla called Pyiodide, or something like that, that compiles a subset of scientific Python to WebAssembly. Can you comment a little bit on that? So there's a few projects already, like Python, like Pyiodide, like Rust Python, which also compiles to WebAssembly. What they do, they approach creating a full-fledged interpreter that just runs on top of the web platform, which I think is an interesting idea, but it delegates Python to this future where it always is slower than JavaScript. It always is slower than what is the default. And I think this is enough to make this inconvenient, to convince both big companies and then smaller users to write the programs that way. Thank you. That was extremely interesting and thought-provoking. You mentioned that the transition from Python 2 to Python 3 was painful in ways that were not expected beforehand, and then that Python, in a sense, was rescued from its end by the unexpected success in data science and machine learning. And this is a pattern that everything always seems to be unexpected until we look back on it, and then it seems obvious. So if the future is so difficult for us to guess, how are we going to know where to put our bets on the future of Python? What things, what platforms, use cases are we going to invest in, since we always seem to be surprised by what actually does happen? Well, it's hard to predict, especially the future. But what I learned at my time at Facebook is that you just need to take those guesses and run with them, and run with them enough that it becomes obvious that the problem was a bit harder than you anticipated, or that the world just went in a different way. As Kentback said, you need to play to win. If we just keep doing what we're doing now, we're going to miss a big transition. And those leaps are what actually provides progress in computing science. Before iPhone, Apple was a different company. There's plenty of examples where there were major shifts in the entire industry. If we already see them happening, which I think WebAssembly is one of them, it would be responsible for us to try this out in earnest. Christian. Hi. So you mentioned the restricted runtime environment for MyPyC. Also, now that PyPy has a R Python interpreter, would you alter a restricted subset of Python without some of these features? Very, very similar. So would it be maybe a good idea to standardize something in C Python where you have a subset of Python feature that we know we can optimize and have a way to flag code or inspect code or run code in this restricted environment? Yes. But the way you get there is to have an alternative platform that informs you what that constrained version of the language should be. If you try to predict the future of what are people going to need, you're likely going to just end up with a design that is artificial and not necessarily useful. Our Python in particular was created with an explicit goal to be able for PyPy to compile that subset to efficient C that then can be compiled. So that was their efficient goal. We can't use our Python, it's Python 2. Hi. Excellent keynote, really, really great. I just wanted to kind of make a similar point. So when you were both Christian and you were saying that there's a subset of things that effectively make Python very Pythonic, which is this dynamic nature of changing things, making metaclasses, dicks, all this introspection monkey patching, that is very core, at least for me, to what Python is. But there's a contradiction there towards making it compilable, if you will. How do you feel that that works? How do you feel that Python should move towards being more compiler friendly? I'm not saying Python as the entire programming language should just abandon what it is now with C Python being dynamic and whatnot. But what I'm saying is a Python-like experience with enough support on a platform where everybody is, is just incomparably better than no support at all because you just cannot get the last 10% of support running on that particular platform. So obviously, I would prefer for us to be able to just keep Python exactly as is and just move it to all new platforms. But as I said, without multimillion dollar investments over many years, that's not feasible. And even in the end, you're going to end up with a runtime that is slower than the default option on that given platform. All right, thank you very much.