Python 2020+ Keynote

Speaker 1 [00:02]

Good morning. Thanks for coming. This is my 22nd public conference talk, one of my first keynotes, but probably the first one that is given to such a big audience. So I'd like to use this opportunity to get a little personal and through this lens to inspire you to make the world a better place by working on Python. The talk will go roughly as follows. Hi, I'm Lukasz. 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. We'll ask where all the new developers are hiding these days. Shouldn't we too be writing JavaScript anyway? But let's start at the very beginning. Hi, I'm Lukasz. 10 years ago, I didn't have my Comet bit yet. And 15 years back, I didn't even know Python existed. Today I'm a Python Software Foundation fellow. I'm the release manager of Python 3.8 and 3.9, the two Python versions under current development. I authored and co-authored like 11 peps. I started a tiny project last year to scratch my own itch, an opinionated formatter called Black. Does anybody here use it? Come claim your sticker later. I have stickers for you guys, for you people. for you beautiful people. See who won't make mistakes. All right. Job-wise, my biggest employer used to be Allegro back in Poland and Facebook in Vancouver, British Columbia, and in California. I used Python at both of these companies, and in fact, I immigrated probably a few million lines of code to Python 3.6. A particularly fun part of it was Instagram. This is well-covered by a keynote given by Lisa Guo and Hui Ding at PyCon US 2017, I highly recommend this video. It is very inspiring, but as well very technical, so you will know what is going on with that and how you can kind of also migrate your code base if you're still waiting for the last possible moment. Don't. These days I ended my fun employment and I recently joined the effort to develop an object relational database that is open source and built on top of Postgres QL. It features a strict, strongly typed schema, a powerful and expressive query language, a rich standard library, built-in support for schema migrations, native GraphQL support, but, like, I don't want to bore you with those details. You can check it yourself. It's on GitHub. And when you are on GitHub, you'll discover that, amazingly, this is written in modern Python 3, using asyncio with sprinkles of Cython where needed. So go ahead and look. But 15 years back, I didn't know Python was a thing. I was a terrified computer science student back in Poland, in Poznań, that's a western city. You can actually hop on a train and be there in under three hours, so it's pretty cool. It's pretty close to Berlin. I was 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, I would be kicked out of the university. So obviously I stuttered very hard for not to have this happen. But the subject matter went way over my head. I felt much more comfortable with high school math. That fits my brain. So I went through an entire book of exercises to practice this thing, to ensure that I will actually pass this time. The book listed answers on the back, so I could check and feel a bit better about myself. But there were some extra difficult ones marked with asterisks, and the answers for those were left out. So I was afraid that those would be the ones on the exam. So I talked with people. I like to complain. If you know me, you know this. So one of those friends told me, like, hey, man, actually, I have a Ruby script to confirm that I got the answers right. It will not tell you how to achieve the answer. It just computes it somewhere magically. But at least you can actually have the answer and check the numbers. So I was happy. You know, I was still like, you know, just tied to my PC stationery at home. So I just ran there like very excited that this will help me now. I downloaded a Ruby installer, clicked next, next, and it crashed. I downloaded a different version and tried this, but there was something off with my particular Windows XP box at the time. And next, next, it just invariably crashed. So I tried a few more times and all with the same result. I had to admit defeat. At this point, I got desperate, and I literally typed into Google, a Ruby alternative. That's how I discovered Python. The website looked something like this at the time. That installer worked. So 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 to kind of confirm that my answers were right, and the next morning I passed the test. But I'm not here to brag. I'm just here to tell you that had the Ruby installer worked that crucial day, We would not meet here now. I would not be here today. I would probably be at a RubyCon or something. I don't know. As most other major life events in my life, it's pure luck. This is something I strongly believe in. All successful people owe a lot to chance. More than most of them would care to admit. For example, a few years later, I found myself being a co-worker of this fine gentleman. That's Kent Beck, creator of Extreme Programming, one of the founders of agile software development, like leading proponent of TDD. And I was just like working with the guy. I was pretty amazing. So yeah, we all owe a lot to chance. And in particular, Kent Beck, you know, very often said to us that, hey, if you want to win, you need to play. Quit yelling from the stands, like get on the field, make a prediction, see what actually happens. So three years later, I found myself still at the university in a research project for the Polish equivalent of the Scotland Yard. I was programming this Italian microcontroller with GSM and GPS functionality that used a bastardized version of Python 1.6. That meant there were no packages, only flat modules. All exceptions were strings. There were no exception objects at the time. It was all kind of clunky, but it worked. I badly wanted to spread the news that it's incredible. I can program in high-level Python and have stuff happen on hardware. Keep in mind, this is 2007, five years before the launch of Raspberry Pi, long before Damien George had an idea to create MicroPython. I responded to the call for proposals for my first conference to talk about this. I was so excited. The talk didn't go well. by the end of my slot I was roughly halfway through my slides I attempted live coding as you do on your first talk ever and that section was particularly embarrassing to be honest with you people people kept sending text messages live to my microcontroller's phone number that they saw on the screen Michael Ford was there, talking about IronPython at the time. I asked him for feedback. And he took me aside and 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 I rather 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 were, and I thought that they're a mandatory part of the event. If you're going on a conference, you have to go to the sprints. I booked hotel and airfare to include the sprint days, and then I found myself on the sprints, and I didn't know what to do. Michael was the only person I knew there. So he helped me with some of my first attempts to contribute to Python. That particular sprint was not very productive in the end for me. Sorry, Michael. I wasted too much time on SVN and setting up my laptop environment to even build Python. But the 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 how actual development is done in practice. You have experts on hand to nag about your new problems. And they're very often very forgiving and very helpful. So this is a very safe environment. This is not something you could buy even if you wanted. Again, the fact that I even stayed for this prince was pure chance. And a fair share of naivete on my part. But it was enough to inspire me to attend the following year. So I did. And I got my comet bit a few weeks later. You have to show up. But if you're already on your feet, helping newcomers might have tremendous impact on their future lives. I know it changed mine. I wouldn't be here today without Raymond Hettinger, without Fred Drake, Georg Brandl, and Guido van Rossum. All of those spent tens, and in the case of Raymond Hettinger, hundreds of hours with me, both in person and online, often at inconvenient times of day due to time zone differences. I'll forever be in their debt. And today I am the risk manager. If I could do it, you can too. But there's a snag. Many core developers rightfully will mention now that, hey, hey, following your footsteps, Lukasz, as I described them, might not be as easy for you as it was for me. Python got much bigger. It has to be much more stable now compared to 10 years back. In other words, most low-hanging fruit are already picked. What's left is the maintenance of an increasingly fossilizing interpreter and standard library. That kind of maintenance is both tedious and tricky, especially for a dynamic interpreted language like Python. With compiled languages, using an old compiler lets you run the resulting binary no problem on new operating systems for years to come. With Python, you can only hope for your program to work on the new version, or you have to bundle the entire runtime with your app, which tends to be very tricky in practice. well python is the biggest community-run programming language on the planet other programming languages with similar or larger market penetration are ran by corporations either single ones or committees of several corporations in practice being a community-run project is both a blessing and a curse for python it's a blessing because python is truly free and independent of shareholder pressure of market swings it won't be cancelled it will be there in 10 years, probably 20 plus years from now. I would know. I'll be releasing versions of Python 3.9 all the way through 2025 for you. But being community-driven is also a curse. Almost the entire core development team is volunteering. They're volunteering their time and effort for free. While the Python Software Foundation is graciously funding infrastructure and events like PyCon US and the annual week-long Python Core Sprint that we just had last month in London this year, it does not currently employ any core developers. Since there is both Python and software right in the name of the foundation, I really want this to change. To be fair, there is progress. There is a grant that was just awarded a few days back, And among other things, for Beware, a project to be able to run Python on mobile devices, to work on their Android support. So there's a chance that things will get better. And there's hope that the Python software organization will provide us with the funds we need to develop Python, not just to keep it running. Because if you don't pay people, you have no influence over what they work on. Core developers choose problems to tackle based on what inspires them personally. In fact, there's never been an explicit roadmap for where Python should go and what problems core developers should focus on. To be fair, I have to mention that as long as Guido was the benevolent dictator, he did most of the vision work himself. He ran many projects personally, and he sparked inspirations in other core developers for things he found important. he stopped proposals quickly for things that he was dead set against. So there was plenty of pressure just on that single person to keep Python consistent and also going in a direction that is productive to the very wide community of users that we do have. And so today, we no longer have a benevolent dictator. It's too much for a single person. We do have a steering council, and I do hope they will be providing visionary guidance from now on. They will present us with some roadmap for where Python should be going. I'm hearing they are working on a document of this sort, but soon enough, we're going to have the release of Python 3.8, and with that, there's going to be a new election for a new steering committee. So, steering council. So it turns out those things take a little longer than I would like. And in fact, I am not on the steering council. I'm just the release manager, and that maybe sounds fancy, but in fact, it is a bit of a misnomer. The thing that I'm actually responsible for is the time you release off versioned source tarballs to the internet. So with friends Ned Dealy and Steve Dower, I do also provide binary packages that they build for macOS and Windows, but I have no say in what people choose to work on. As a release manager, the only way to influence contents of a Python version is to revert changes when they're made too late or when they're too disruptive. For example, they're incomplete or they're buggy or they're backwards incompatible in ways that we did not expect or anticipate. So I'm not on the steering council. But since you're all 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 until now. I kept using the word Python all along, but in most cases, I really meant CPython, the reference implementation of the language written in C that most of us are using for their daily needs, right? The snack I described applies to CPython alone. This is the interpreter that is ran by a team of volunteers with an insanely important but crippling focus on backwards compatibility. This is the interpreter that is going to be maintained for decades. Drastic changes are thus very unlikely. Because of that, I would argue that if Python stays synonymous with CPython for too long, we'll be in big trouble. Why? Because CPython is not available where development trends are shifting. For the web, the lingua franca is JavaScript these days, an increasingly popular TypeScript. For mobile, for the two most popular operating systems there, we have Swift, the modern take on Objective-C, and Kotlin, the modern take on Java. For 3D games and the raising kind of development on VR and AR, there's C Sharp provided by Unity. But Python is also slowly losing ground on the field of systems orchestration, where Go is gaining traction. It used to be the case that OpenStack was entirely in Python. Perhaps if not for the rise of machine learning and AI, I was unforeseen by core developers, Python would not survive the transition between Python 2 to Python 3. So we were really lucky there. But if you think that what I just described is sad, negative, depressing, or fatalistic, think again. In the developer survey that was conducted by Stack Overflow in 2018, Python is the most wanted language. People want to use it. It won by far. So why aren't those people using Python? Let's look at another result from that same survey. Looks like we are the seventh most popular language in use. 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 who want to use it. In fact, looks like we are already the fastest-growing major programming language after all. This article was published in 2017. I recommend reading it if you haven't seen it yet. it says, among other things, with a 27% year-over-year growth rate, Python stands alone as something that is both large and growing rapidly. So C-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 for a new runtime or a new compiler unencumbered by the constraints of CPython targeting a new trending platform like the web or VRAR. This can become career-defining work for you, and you'll make the world a better place that way. At face value, what I propose here is crazy. There were many unsuccessful attempts to create a new Python runtime after all. Don't I know it? Remember this picture right here? python was discussed in this vm panel at euro python that year and from the left you can see here carl friedrich boltz representing pi pi mark shannon representing hot pi which is now a defunct project he's a pi c python core developer you can see michael ford representing iron python which is now a defunct project and he is a CPython core developer you can see Frank Wierzbicki representing Jython pretty much a stalling project maybe abandoned, I'm not quite sure what the status there is you can see Georg Brandl representing CPython he's no longer around, we miss you Georg and we see Damien Dideren representing Crosstwine also a defunct project at this point not pictured here are representatives of Unladen Swallow, Piston, and so on. So creating an alternative Python runtime is very tricky. In fact, the one surviving alternative representation here, the alternative runtime, is PyPy. And it tries to be bug-to-bug compatible with CPython, to be maximally compatible so you can switch. And yet you never do. The adoption of PyPy is very low. And I'm not saying that to hate on PyPy. It is a wonderful project. In fact, this winter in February, I spent a week with the PyPy core devs in Dusseldorf to work on its Python 3.6 support. I met a lot of the core team. They're wonderful people. You should meet them and you should listen to them. I even ended up getting a commit bit myself. I don't know. They're like very liberal about giving it away, I guess. I solved a few Python 3.6 compatibility issues, and I learned a lot about how PyPy actually works internally. Among the things I learned was something that in hindsight is obvious, but I was kind of very shocked when I discovered this in my own kind of way of slow thinking. which is that PyPy is probably one of the most tricky Python applications there, but it's written in Python 2. And it'll probably forever have to support Python 2 itself because it has to bootstrap itself. It has to be able to compile itself. And so if you're not investing in PyPy removing that constraint, which would take years and probably millions of dollars of euros of investment that will that is just unlikely to happen the reason why is that you might say hey you've seen instagram it had like two million lines of code like this is a million like should be easy right well now like web applications are very often very regular code bases in comparison pi pi is using a lot of metaprogramming. It's using a lot of things that let them achieve dry, let them achieve like kind of ensure that they are correct. That makes it hard to move from Python 2 to Python 3. But in general, trying to replicate CPython bug to bug with all its behavior and all of the library is just super hard. So I'm skeptical about CPython replacements. Maybe you could pull it off with north of a million euro and five years of development time. But unless you have that, I don't think it's feasible. But areas of modern focus where Python currently has no penetration, like mobile, like client-side web, like VR and AR, all those don't require full compatibility with CPython. The good news is that since many Python features are hard to optimize and make static analysis work, maybe you can just skip some of those. That actually is something that we are already struggling with with CPython. There are certain features that we love when we are first experimenting, we're writing our initial programs, but later they become taxing on what the IDEs can do for us, what other software can do for us in terms of refactoring, in terms of finding problems via linters or whatever else. So I have no time to enumerate the entire laundry list of Python features that I personally think could be feasibly simplified given a new platform, but let me show you a handful. The import system. This is from the docs. This is a very complex Beast. It supports modules, packages, namespace packages, search, a runtime-writable module cache, finders and loaders that not only include the one that you know of, which is the default file system-based one, but also you can build custom ones. You can read Python code from encrypted sources so people don't see your .py files. You can write whatever you want. You can read it over the network or from a database. You have import hooks, you have metapath. This is very powerful, but do we need that on the web or VR or mobile? I think the new cool is something that Go does. Static binaries. No containers, no virtual ends, no pip installs, no orchestration. Just a single file. That's easy. Something like that would be a major win on the new platforms. What people actually want on mobile is for them to click install on the app store, type in their password or look at the phone and just have the app like there in a few minutes. Exec. We saw exec in use just yesterday, how you can program with templates, right? How you can actually put strings there and, you know, code comes out and does things. It is arguably tricky to get it a performant. It is for sure tricky to get it safe if it accepts any form of user input flowing down into what the exec does. But in the end, the string that you are evaluating could be just written to a .py file with a sensible build system and just compile regularly as regular Python files. So do we need to implement exec? Maybe yes, maybe not. Probably not. Metaclasses. Metaclasses enable you to customize how classes are built, not instances, but entire types. So this is very useful for quite a few things internally in Python in the standard library. but for a new platform you might provide some of those metaclass capability as a built-in thing and just not provide metaclasses as a generic construct which makes things behave a little magically and the long-running opinion on this is that if you can avoid it just don't use metaclasses they are a bit kind of crazy to explain and maintain so unless you really need them, avoid them. So maybe we could avoid them in a new runtime too. Looking further at objects, we have the descriptor protocol. Parts of the data model in Python are very dynamic, which might not be necessary. Descriptors allow customizing what happens when you access an attribute, when you set it or delete it. Descriptors were added in Python 2.2. So a long time ago, they were part of new style classes. This is how properties, class methods, and super are actually implemented. Python uses that to actually simplify the C implementation as well. But that's indirection. And indirection equals bad. That's slow. Knowing the shape of an object enables you to optimize memory. What is a shape of an object? It's a term that essentially means if you have a class, you know from the start what kinds of attributes and what kinds of methods are are going to be on it, and that thing is immutable, doesn't change through the lifetime of the object. If you know this, you can do magic things. You can be really quick now. You can just use kind of arrays in memory for those attributes and for those methods. Access to that is way faster than what we are doing now with hashes in Python. With Python, everything is also mutable. You can delete methods at runtime. You can add new ones. You can just, you know, add new attributes and remove them. Is that good for the human that is reading the code? That is also questionable. Customizing module attribute access. Did you know since Python 3.7, modules support dunder get adder, and they supported customizing dunder class since 3.5. Wait, what? Yeah, I'm saying dunder class on an object is mutable, and you can just lie about what type and particular instance is. This actually enables advanced functionality. For example, you can put custom classes as modules under sys.modules. Or stuff like mercurial plugins are implemented with Thunderclass rewriting. I could go on. The point is, starting out with a familiar subset of the language would simplify development a lot and potentially would even fit the target platform better. Don't believe me? That's MicroPython. Let's look at it for a while. A single developer, Damien George, started development from scratch six years back in Australia, funding his work with a Kickstarter campaign. It's a surprisingly compatible runtime for microcontrollers with very little memory, like 16 kilobytes of memory and 256 kilobytes of memory for code. If you think about it, it's just mind-boggling. It also works on microcontrollers with very little computing power, and yet it does things tremendously well. It's used as a teaching platform in the BBC Microbit, like in the Adafruit Circuit Playground, and home automation MIDI controllers. And we just learned yesterday, it will be sent to space as part of the ESA Euclid mission. It's pretty impressive to me. This is also a game console called PewPew that my friend is developing. It's also using MicroPython there. I'm hearing it is becoming very popular. It was distributed this year on EuroPython. I highly recommend getting one. It's great fun. I actually like to use it. For correctness, I should add that some of the users I mentioned here are powered by a friendly fork of MicroPython called CircuitPython that is used for education more than actual production uses. For example, you can literally connect it to your computer using a USB cable and you see it as a thumb drive and you see Python files that if you save them, it will automatically reboot the microcontroller so you can see the changes that you made all around like very quickly. But the reason I'm telling you about MicroPython is that it has a long list of agreed differences with CPython. It's like, hey, the target platform is different. We cannot or are not willing to support some of the things that CPython is known for. So having all this is not crippling for the CircuitPython users. It's not crippling for the MicroPython users. In fact, this is what enables the users to learn Python in the first place very often. The BBC Microbit is their first forage into hardware programming. And in fact, even though there are lists of things that we don't support in MicroPython, you can still connect the device over USB and press CTRL-C while your program is running, and you get a familiar REPL. How cool is that? That's pretty impressive to me. You can, for example, execute there on the board module, and you will get the available pins, the actual physical pins on your circuit board. That just blows me away. But you will need Control-C here. Will you need it on client-side web app that is running on your phone's web browser? Probably not. Instead, I think we need a Python compiler for the web. This means we cannot achieve full compatibility with CPython as CPython enables plenty of dynamic behavior at runtime. Some examples I listed before that we can probably do without, but there are things we cannot do without. To be viable for production use, for professional use, Python on the web must not be orders of magnitude slower than the default language on the platform. That rules out running an interpreter on top of the provided runtime. You will never be as fast as JavaScript that way. That same for mobile, and especially on an increasingly popular intersection, a mobile web browser. You don't want Python to kill your device's battery because you just ran a website that happened to be written in Python. Or you don't want it to be unresponsive. You want it to scroll nicely. You want the animations to be impressive and everything else. So we need a Python compiler for web. That's a hard path, but in my opinion, that's inevitable. Luckily, there's some prior art we can either improve or reuse or take inspiration from. Here we have logos of Nootka, Cython, Theano, Shedskin, Python, and Numba. But the one I wanted to focus on for a moment is the newest kid on the block, MyPyC. It's a MyPy2Python C extension compiler, a dedicated code generator. What it does is it treats your Python code and generates Python C extensions for CPython that are way faster. I think a dedicated code generator like this that targets WebAssembly or Swift on mobile or something is definitely viable. If they can do it with the Python C API, we could do it with this other target platform. So CPython is an interpreter. It runs an evaluation loop over opcodes that you have, for example, in a .pyc file, and dispatches what to do at all times. Every time, every day, all day. So very often it delegates behavior to dunder methods or some hash lookups. The compiler should not just inline that eval loop to native instructions since this is just a worse version of the full-fledged interpreter. You cannot PDB it now. You cannot quite see what the interpreter is doing at any given point in time. And that kind of removes some of the flexibility while not providing much speed itself. What I'm talking about is a compiler that moves as much of the special method behavior and hash lookups from runtime to pre-compiled as possible. And in fact, if you were bored by what I'm saying and just like reading through this page here instead, you would see that MyPy already does get away with some differences from regular Python. It is settling on a strict subset that it's calling itself. For example, saying your code has to be type annotated and those type annotations are used and enforced at runtime. It uses those to actually align things in memory in different ways. And classes are compiled into extension modules without, into extension classes without dunder dict. What that means is you don't have a hash lookup for every attribute and method. We assume the shape of the class will not change, the shape of the object is going to stay the same. But now we can use an array, and it is actually way faster. Monkey patching doesn't work, and you're thinking, maybe that's even an improvement. But if you ever use unit tests mock, mock.patch is monkey patching. There's plenty of other subtle examples of monkey patching that are used in Python. So this is not supporting the full flexibility of CPython already. For example, metaclasses are not supported. So that kind of proves that what I just told you a few slides back is feasible. Like we can just get away with not having that. There's other examples here and that kind of strict subset is still a moving target. But so far we know this. MyPyC was originally conceived to make MyPy itself better. MyPy as a complex beast is a type checker for Python. It does a lot for you. there's been a lot of work to make it feasible to be used as part of an IDE to be as fast as possible and with MyPyC it is four times faster in fact the MyPyC developer, the main developer Michael Sullivan was very excited about making Black work with MyPyC too and there's an open pull request for that, Black works twice as fast with MyPyC so this is feasible we can have something like that. If you expected I would now reveal that I have something like this running for WebAssembly, I have to disappoint you with the release manager position, with black, family, unrelated hobbies, and a new job. I have little time for a big project like this. But what about you? What about your organization? What about sponsoring such effort? What if the Python Software Foundation funded that? Maybe the Python Software Verband. Maybe a Kickstarter campaign. But hey, if you still want to work on CPython instead, I'm not saying that CPython is a dead end. It will forever be an important project. It will forever be an important Python runtime. Maybe even the dominant one. Until Python stops being used altogether. New people are still both welcome and needed. For example, Pablo Galindo Salgado, one of the fresh committers that we have. he just got his commit bid last year, 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 back. The runtime is mission critical in many industries, mission critical in entire industries, which is why development must be extremely careful. So we reached the final point. To be honest with ourselves, we have to ask, maybe it's okay for Python not to be available on those newfangled platforms? Well, I strongly believe that enabling Python on new platforms is important work. As Alan Kay, one of the pioneers of object-oriented programming and user interfaces, said, 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 for many things, it is 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 the extra layers of abstraction and new cryptic things to learn. That is the practice part of learning to play violin. 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 at how much you can accomplish with just a few lines of code, especially compared to languages like Java that I was taught before. But there are languages even more expressive in enabling even more compact notation, right? So what makes Python special then? Python is runnable pseudocode. It reads like English and is very elegant. Edgar Dijkstra even says, elegance is not a dispensable luxury, but a quality that decides between success and failure. Right, right. But in my experience, convenience all too often wins over quality of experience. Our responsibility is then to make our runnable pseudocode convenient to use. and that means to be enabled on the iPad, on the phone, on VR and AR. Runnable pseudocode means Python is very popular in teaching already and it should stay that way. Let me give you an example. Here's a room of musicians figuring out how to use Python for the first time. What they're doing is they're making their software synthesizers play controlled by CircuitPython hardware with MIDI. That was at Moogfest, which is a very large music festival in North Carolina in the US. It was this year. People were mind-blown that they are not even programmers. And yet, after a few hours, they are able to make their software synthesizers just play what they want. Right? You have to understand those are musicians. Another example would be... I'm not saying that to, you know... just saying they're not trained and everything is practice right you know quantity enables quality meet this other guy that's stanley that's my son back in 2013 he was five at a time he was trying his first steps with the turtle module on a raspberry pi i got that year at PyCon US. I will always remember the pure joy when he by himself made the turtle go where he wanted. Now he's almost 11. We still have fun with Python, like mostly through the PewPew console. But to be honest with you, he's having way more fun on the iPad with the Swift playgrounds, with Scratch, you know, trying his first steps like making games in Roblox or whatnot. The PewPew console only gets him so far. We could enable a future generation of software developers if his first programming language, the one that he uses on a tiny piece of hardware that costs 10 euros, 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 much easier and better by bridging the gap between the micro bit and developing applications for true mobile devices that everybody of us, like every of us, has in their pockets. That could also build some job security for us. Maybe that's a good thing. But we could really enable this 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.

Speaker 2 [43:30]

Thank you very much.

Speaker 1 [43:33]

Yeah, questions?

Speaker 2 [43:33]

questions not leaving questions who is over there I'm running I'm coming please stand up while I'm running oh too fast standing up

Speaker 1 [43:54]

Thanks for the great talk. Just a very brief question. What are your thoughts on Rust Python? Well, I played with it for a while. I do think it's in a kind of different area from what I'm saying because it does try to be a full-fledged interpreter, like rewritten from scratch. It is unclear to me what their mission statement is about being compatible with CPython or not. I do think ideas like this are important. So definitely there shouldn't be a core dev telling you that, hey, man, like, don't work on this. Like, no, like, that's not something that we should be saying to anybody. I kind of, I would like to see it succeed. So far, like, it looks like it's pretty early in their development. But if Rust and Python both interest you, you should get involved. Totally you should see, like, how you can make cool things with it. Like, the nice thing about Rust is that it already itself has a WebAssembly target. So you could enable running that kind of Python on the web that way. Like, as I said, is that going to be performant enough? That is to be seen. But maybe my worries are not kind of so well funded. I would like Rust Python to become a thing.

Speaker 2 [45:11]

Okay, next question.

Speaker 3 [45:13]

Thanks a lot for the great talk. So as you mentioned, Python is very successful in the machine learning and data science space. And people in that space are still having some difficulties with certain aspects of Python. For example, differentiable programming is not possible in Python. What do you think about taking Python also in that direction, where there's more support for such applications?

Speaker 1 [45:38]

an interesting question because for the longest time data science was just like kind of its own thing the core developers were very rarely involved in that space and this was why for example the matrix multiplication operator took so long to be added to Python. It was proposed like a long time ago and yet it was just rejected as like something that is not important for our user base in general and complicating things for everybody else And there was always, and it has to be always, this concern, like, what if people just start abusing it for something crazy? But yet, in the end, people came back to that same idea and said, like, hey, like, we really need this. This is really awkward if we don't have it. And it was added back to CPython, which you have to understand is, like, CPython is kind of a lot of islands of different use cases. Like, you know, the running joke is that it's the second best language for anything. So it is hard for us to just go in all directions at the same time and keep Python still nice and, like, tactable to learn as a target for beginners as well. So I cannot say how far we're going to go in a single direction. I do feel like at some point we're going to just have to have, like, domain-specific variants that are enabling stuff, like, that you really need as a data scientist, but you might not need on the web or the other way around, which is why I'm telling you maybe not even CPython, maybe a new runtime is what we should be pursuing. But definitely CPython is not frozen. Stuff that might have been kind of ignored before and it just rises to be an important issue might be still addressed. So if you are interested in a particular proposal, you should raise this question. you should pursue this to be fixed.

Speaker 4 [47:35]

Thanks, Lukas, for the great talk. To me, one of the greatest value propositions of Python is the ecosystem. And now I expect that on your new platforms, most Python packages will not be runnable, like those from PyPI, I mean. Do you think there's a chance to define a common denominator of different Python implementations so that we can preserve parts of the ecosystem, maybe akin to .NET Standard for .NET Framework and .NET Core? Good question.

Speaker 1 [48:06]

Good question. I think this is most useful if it starts as a grassroots movement, like if we actually know the use cases that we need, instead of just being like this decree from way above. The way I see this is that you are absolutely right. If you have CPython, but you cannot import any sensible library, then like it's not, you know, kind of useful anymore. However, MicroPython shows that you don't actually need to have NumPy available on your microcontroller. Maybe that would be nice, but if it's not there, you will still make do. But on the other hand, there are things you can import on MicroPython that you cannot import on CPython. They don't exist because they are specifically targeted, specifically useful in microcontrollers. This is what I kind of foresee for mobile platforms or client-side web as well. Like, you know, maybe you're going to be able to import the VDOM or something else on the web that just doesn't exist on CPython but makes perfect sense on client-side web. So some libraries, some third-party libraries might want to target also being viable on that particular new platform. This is already happening with libraries that want to ensure they're running on PyPy, right? It should be magically compatible and always work, but yet library maintainers have to put some little effort to make sure that there is compatibility. So this is what I foresee also happening with new runtimes.

Speaker 2 [49:34]

I think there will be many, many more questions. And we have a Python panel this afternoon at 2 o'clock, just in this very room. Lukasz will be there. Marjate will be there. Hinek will be there. Stefan Behl will be there. And it's a discussion about Python, so we're going to discuss on CPython, Python Ecosystem, everything. Just come by. We have one hour. We will have a short discussion and then also open to questions to the public.

Speaker 1 [50:04]

All right, cool.

Speaker 2 [50:05]

Thank you so much for this great keynote, Lukasz.