 And now I'm going to pass over to Pablo. Pablo, you probably know, he's one of the core developers. He's the release manager for Python 3.10. And he's also a member of the steering council that basically decides where Python is going in the next, well, steering council is voted for every year, but it's basically decided where Python's development is heading. So I want to... Hi, Pablo. Hi. Hi. You're here. Welcome to Europe, Python. Thanks for having me. Yes. Very nice of you to come and then give your talk. So I don't want to take more of your time, so I would suggest that you start the screen share. All the technicians put it up. Let's see. There you go. And I will stay around, but I will now leave the stage to you. Thank you, Pablo. Okay. Thank you. Thank you very much. Well, okay. So thank you, everyone, for coming. I would like also to take the opportunity to thank the organizers. Like, organizing a conference this big is a lot of work. I have organized smaller conferences, and I have ended exhausted, so good news to all the organizers. And, you know, like, make sure to say thank you to them if you have the opportunity. So thank you for coming to this keynote. It's a bit early in the morning, but let's see if we can get something interesting in these four to five minutes. So this keynote is going to be a bit special. It's going to be a bit of a journey over, like, you know, several aspects of how CPython is developed and, like, how things work in core development. But ideally, I would like also the keynote to be around an interesting idea that I had recently. And I see this idea popping up everywhere. So I would like to share it with you, and hopefully at the end of the talk, so you are a bit convinced of what I want to see. Okay, so just a few comments over, like, who I am, because, you know, I'm going to talk for 45 minutes, so you probably want to know briefly why you should listen to me for the five minutes, right? So as Marc mentioned, so I'm a CPython core developer for several years already. I'm in the Sting Council this year. The Sting Council is kind of this group of core devs and people from the community that kind of decides on, like, PEPs and, like, high governance and things like that. I'm the Python 3.10 and 3.11 Release Manager. As you know, probably Python 3.10 is, like, months away. We are super excited. It's a fantastic release. We think it's going to be the best Python ever. It's going to be faster. It has, like, super sign-in features, like pattern matching, a bunch of very interesting stuff. And in my daily work, I work in the Python infrastructure team at Bloomberg. So we are actually sponsoring your Python, so you have the opportunity to go and say hello into our digital booth or whatever it's called these days. Cool. So one interesting thing is that before I worked, you know, on Python and, you know, computer science and whatnot, I used to research black holes in academia. So, you know, like, this may sound like, why is this about black holes now, right? But bear with me. It's an interesting topic. So let me tell you about just briefly about black holes because I find them, like, super, super interesting. And it's actually quite very related to the small story that I want to show you. So something that I used to do when I used to study these things is to produce this kind of simulation over how black hole will look like. Very similar to the, you know, the fault of the black hole that you probably already see. My simulations are a bit different. Like, for instance, this is a simulation over how a particular rotating black hole distorts the background. So you can see, like, the dark part over here is kind of the even horizon, which is this region with light kind of escape. And you can see here, like, all these distortion around, like, the star field, right? Normally, these things are kind of surrounded by, like, aggression disc, which is this kind of, like, super hot matter that is falling into it. And it has, like, this super weird structure. I don't know if you have ever seen. Obviously, this talk is not really about black holes, so I won't go into a lot of detail. But all of this thing here is kind of the aggression disc. The same thing as this one inside, like, it's literally the same disc, like, being distorted by light. If you kind of see it in a kind of, if you make the camera going around the black hole to take, like, you can also have, like, kind of better images, of course, than just this low-res simulation. But if you take the camera, kind of, like, to look around the black hole, you can see how the kind of the disc inside here becomes the disc outside when it flips. It's quite interesting, right? Like, there are these super interesting bits that distort a space time in quite a dramatic way, right? They create this kind of a space-time storm, right? Okay, so, you know, like, you could say, okay, so why black holes? So I want you to look at this picture. This is kind of one of the most interesting points of the talk. So what you're seeing here is, like, a photo of from, I think, it's in 1997 until 2016 of the center of the galaxy. And if you see here, these, like, bright dots that you see are stars. Obviously, you know, like, stars move quite slow, like, these distance are, like, parsecs, right? But the interesting here that you can see is that, for instance, if you're looking at this star, this star is cycling something. You see, it's going in circles like this. But there is nothing in the middle. And this is basically the question of, like, okay, so, okay, if black holes are black and they don't emit light, so how we know that they are there, right? And this case here, as you can see, is a system, right? And this is going to become very interesting in the talk. It's a system when things are happening, right? You know, these brightest stars are moving around. But it seems that whatever is driving the movement of these stars is invisible, right? Like, we can see, for instance, as I mentioned, this one is doing these circles, but it's nothing here. There is not a bright star in the middle, right? Like, if you don't see it clearly, there is this other kind of, you know, image that is more, like, schematic when you can see the movement of these stars. As you can see, all these stars kind of are cycling something which is in the middle, which is not there, right? Which is a mystery, right? Like, this is one way that we used to detect black holes. Like, when you have these massive stars cycling around a single point, which is, like, black, then you can infer that something is there and then you can infer which is this mass and how much volume the mass is enclosing. And then you can kind of know, okay, so, you know, there is a black hole there, right? You know, you may be very confused, like, why are you talking about this thing? But it's going to become quite interesting, quite interesting on the top, right? So another kind of interesting topic around, like, mysteries of, you know, like physics and whatnot is what we call dark matter. So when we look at galaxies and then we see how fast this galaxies spin, like, on different points of the disk, like, for instance, we see how fast they spin close to the center and how fast they spin close to the edge. So you can have this kind of plot, right? So this line over here is what we expect, like, the galaxy spins slower, the farther it is from the center, but it turns out that what we see is this line over here. It's kind of the galaxy spins more or less at the same speed, which is super weird, right? And this is where it comes with the thing that we call dark matter cancer, right? Like, if, you know, it's kind of a weird thing because it's like, we are basically saying, okay, so dark matter is something weird that instead of, you know, of producing this result, produce this result. If you don't have it clear, basically the game that we play is that if you have this problem, like, you have, you know, one plus one equals three and, you know, it doesn't work, then you basically invent one extra number and then you call this dark number and then you are done. That's basically how physicists work, right? Like, that is basically what we call, right? So it's this entity that we don't know that is there. But the interesting thing is that this dark matter in the galaxies and the black holes in the images that you saw are kind of driving the whole behavior of the system, but they are invisible. You cannot see them, but this is one of the most important parts in the system, right? It's literally explaining how the system works and this is going to become very important. Okay, so the question then is like, okay, so what has, you know, black holes related to Python or to see Python in particular, which is what this talk is about. Well, you could say that, you know, like both will absorb you as you are close enough and will probably tear your soul apart in, you know, in a rip of a space time where not even like can escape. But, you know, like, obviously we are talking about two different things. So what we are going to like go now is to different aspects of like, you know, see Python development and different interesting insights that happen while we are, you know, developing see Python. But we are trying to, you know, the same way I explained with this black hole and that matter idea of like something visual is driving the system. I would like to kind of wrap around with all these stories. All these stories will have something common that hopefully we will see at the end. But maybe you will see the hints as we go. So the first like story or things that I want to talk about is kind of the invisible, right? Like it's okay. Well, the same way in black holes are invisible. There's things here that are invisible. But what is invisible in see Python development? So let me tell you a story. So this is something that happened on Twitter one day this year. So Anthony, for the ones that you don't know, Anthony is a great member of the Python community that works on like a lot of tools like FlakeAid, like he's also a Python score developer. Like he's a super nice person. He tweeted this tweet, right? He said like, oh, you're getting this kind of nonsense syntax error on Python, right? Like horrible, horrible error. You can try the PyPyPro, right? Like PyPy, as you know, is this a faster alternative interpreter? It's fantastic. You should try it out. But it turns out that he was complaining, you know, see Python has these horrible error messages. Well, PyPy has a much better. And, you know, I look at this and say like, I mean, you know, challenge accepted. Challenge accepted. Let me try to fix. And this tweet was the start of like one of the biggest new developments from Python 3.10, which is kind of these new error messages. So let me kind of show you a bit what is this around. So for instance, this is one of the problems that we have. In mind that you have like a dictionary, right? And you have a bunch of numbers. And the problem is that this dictionary is not closed. It doesn't have a closing bracket. And then there is some other code afterwards. So it turns out that if you run this example on Python 3.9 or 3.8, you will receive this thing, which is super weird, right? It's telling you that this equal sign in the some other code example is invalid syntax, which kind of it is because, you know, it's thinking that it's inside the dictionary because it never saw it closed. But like, this is super confusing, super confusing. So after some effort and, you know, quite a lot of changes on the tokenizer of C Python, which is one of the oldest areas of the code base. And it's very, very tricky as you can imagine. One cool thing that we have now in Python 3.10, the same as Python has as well, is that now we can finally, we can finally point you in this particular example that the problem is not like, you know, that there is an equal sign that is going correctly. That this open bracket was never closed. This seems like a very simple thing, right? But this is super important because even like experienced developers who know when this normally can happen, you know, they are tripped. And, you know, this is fantastic. And this was actually not super, super easy to implement in our particular tokenizer just because the error happened after we pass over these lines. But we are super excited to have this thing in the same way as the Piper interpreter has some others. And this is one of the examples, right? And then, you know, then I say, oh, you know, I saw these two people and people were like, wow, finally, like, you know, this is something that we all wanted. Like, this is fantastic. And this made me think like, okay, so we may be onto something, right? Like maybe, you know, people want the speed and you know, people want like, you know, new features and like pattern matching and whatnot. But maybe this is something that also people want. This is better on messages, right? So first of all, recently I've been working with Guido and Lisandro on the new parser, which is the kind of this new parser for Python that we introduced in Python 39. There is two talks about this parser on this conference. I'm quite excited to see them. So I will be there, I encourage you to check them. But the idea is that now this parser is quite more powerful than the one before. And one thing that I've been doing, transforming and working with it recently in Python 3.10 is to make it like much smarter regarding error messages and error reporting, which is a bit complicated in PEC because PEC doesn't have the concept of a failure. But we have pulled it out and I'm quite happy. Let me, I want to show you some of the examples that we have made. So for instance, one thing that we do now is that when there is a syntax error, we highlight now the whole range. So instead of like just pointing to set, we point to the whole thing. So in this example, it's a function called with the generator without parentheses. So we told you all the things that are wrong here, which is quite cool before we only showed you one of the, of the carrots. Something that we do as well is that, you know, if you do a conditional with only one equal here. So if something equal to something, instead of telling you, you know, like, well, generic invalid syntax, we told you like, okay, so, you know, maybe you mean like equal equals instead of one equals, which is quite cool as well. For instance, this is one of my favorites. Like if you have a dictionary or a list or something and you're missing here, you're missing a comma, then the interpreter would tell you, oh, maybe you're missing a comma here, right? Which is quite cool, instead of complaining to the next line. More things that we do, which is quite exciting, like if you type an attribute of a module or a class or basically of anything else, but that is not there, then Python will try to be helpful and tells you like, oh, maybe, you know, maybe instead of name tuple, that doesn't exist, you mean name tuple. So which is quite cool. This also works with local variables, I was never, probably many of you are from Germany, so you probably can pronounce Warshell much better than me. What a cool name, right? Like it's Warshell, it's one of the guys who discovered one of the simplest variables, it means black shield. I would like to have one surname as cool as this guy, but I never remember how to spell it. And in this case, for instance, if you use the variable, it will tell you, well, I don't have any variable with this spelling, but maybe you mean this other one, which, you know, we are super excited to see. And this is super cool, right? So, you know, we keep adding these things and then, you know, people keep reacting like super well and say like, oh, maybe we are onto something, like it seems that people really, really, really value UX experience and better our messages. And this lead us to PAP657, which is in Python 3.11, it's not on Python 3.10, but this is a word that we did with Amar and Batuhan Toskaya. And the idea here is that now the interpreter will tell you exactly where errors happen in a line. So for instance here, if there is some problem because one of these values is known, it will tell you that the problem is in this part of the expression, right? So this operation is the one that is wrong, and which is right because before it was like super, like imagine that you don't have these lines over here telling you exactly what's going on. It will be super difficult to know exactly what's happening, right? And for instance, if it's known, there is other kind of things. So I tweeted this thing and I announced that we have this thing. And we had this like fantastic response from the community, like super engaging. Like it turns out that everybody likes this thing, like is this like, I've been working on so many features of C Python, like I've been working on like some of the speed improvements from Python 3.10 and 11, some of the new features, some of the typing stuff, but it turns out that UX experience is this thing that turns out that everybody really, really likes. I mean, obviously you can imagine that people like UX, right? Like obviously, why do you want like better messages, but like I was not expecting this kind of response. This is one of the examples, right? Like is this mysterious like hidden item that people don't prioritize when they talk about why they're going Python. Normally they say, oh yeah, I want a faster Python, right? Or I want like type annotations to do something, or I want like pattern matching. But they don't normally discuss the things even if they really, really want them, right? So this is like the invisible thing that is driving the system. Like maybe what like make people excited about Python 3.10 is not that much pattern matching. Maybe what makes people excited about Python 3.10 is also obviously pattern matching is exciting, but you know, maybe it's also the error messages, right? So this is an interesting thing to think about. Like is there any other like aspects that people want that are hidden? Like there is any more black holes here that we don't see and it's driving the whole system of what people like in Python. So this is something that is making me think a lot recently and it's one of the stories that I wanted to share with you. Like how important this aspect is. You know, which sounds cool, but it turns out that nothing is that simple, right? Because you know, like, okay, so implement better error messages. So you know, if you look at how I was while I was implementing these newer error messages because you know, we needed to modify the back parser to this thing and the back parser is using back, which is not a especially good like passion mechanism for making error messages because it doesn't have a super clear concept of error. Although, you know, you can do it. There is a lot of research about this thing. So basically this was my, this was myself and the back parser, right? Like the fingers here are obviously backs and I was trying to smash all the backs and the problem is that every time, you know, like you implement some newer error messages and the older fail and you know, it's quite, quite ridiculous. So let me share one of the weirdest backs I have seen while I was developing these better error messages. Probably the weirdest one has been this one. So I type the same code in the rebel three times this stupid for loop, which is totally valid. And the third time the parser says that it's invalid syntax. So it's like a, like a quantum parser, right? Like something like that. The for loop is in a superposition of valid syntax and invalid syntax and only when you look it will collapse to either state. This was super ridiculous to find out because, you know, like it's a for loop that sometimes is invalid, sometimes it's not, right? And, you know, this took a lot of time because this is one of the kind of backs that happened after the fact. Like it's not like, you know, the back happens and then something goes wrong. Like it's something like, you know, the back happens and then it goes through all the interpreter, like, you know like all the way through the compiler pipeline. And at the end of the day, it turns out that, you know you get just invalid syntax, not a second fold, not a crash, nothing, it just invalid syntax. So what is going on here? Like what was happening? So it turns out that when the parser construct the abstract syntax tree, which is this tree that basically encodes before going to the compiler it encodes the shape of your program in a lexical way. So basically like for loop and maybe this is the target of the for loop and et cetera. So in C Python, the C in C Python is C, right? The C language, right? So C Python is implemented in C. And in C we have kind of this specific class basically, right, this extract. And we use this thing to store a collection of something, right? So, you know, like it has this size parameter here which is how many elements do we have? And then we have this array of elements of void star elements. And then we have, you know, a bunch of like markers here just to get maybe an element. Then we have another to set an element. And then we have another to tell us like what is the length of the sequence. The problem is that this thing is super generic. Like you can store absolutely whatever. Like you can store like, like, you know donuts, inters, flows, whatever you want. And you won't know what you have stored because the parameter is void star which basically means whatever like, you know the C doesn't care. So the problem is that we were inserting into one of these things something and then we were retrieving it as if it was something else. So imagine that you put into a box an orange and then, you know, I don't know you close your eyes and then you retrieve the orange and you pretend it is an apple. I mean, it's not going to be like super, super, you know, apple when you try to bite it down, right? So this was the problem. It was basically memory corruption. So when we were doing this thing we were corrupting the memory, but it was valid memory. So nothing was wrong from the perspective of the C programming language. But the problem is that, you know like the memory was getting corrupted. It was surviving the whole interpreter. It's just that like when it goes to the time of parsing the for loop, then it is basically not recognizing the PEC parser was not recognizing the for loop because one item that soon have been zero, it was zero just because we were corrupting this memory. So the way we saw this thing is that we, I mean, obviously a more strong language like C++ or RAS or something like that will have genetics, which is how you solve this problem. But in C kind of you don't have any of these. So the way we saw this thing is kind of like trying to, you know, make this thing even more complex. And now we have this cool kind of sequences that, you know, it has types here. So for instance, you can have like now, okay, so you have an array of Python objects. And then there is kind of this this critical here now that is able to allow you to work with type information, which is still like, you know, too complicated because we are implementing genetics in C, but it's safer now. Now this kind of bugs will not happen, right? So, but this was super, super tricky to find out, right? Like we needed to, you know, think about like how this could happen. And, you know, like, like check all the memory that was involved into these calculations. So, you know, I don't know if you have seen this kind of like table about like, you know, like there's a name in English I never remember for this thing, alignment, right? Alignment charts for D and D, right? So, you know, like people put here programming languages, maybe they say, okay, Python maybe is not for good. I don't know, Java is not for level. I mean, you know, like all programming languages are useful, so this is obviously a joke. But something that I'm super sure is that C is here. Like, you know, you kind of convinced me. Like if you program in C and I do, like, it's K of the keyboard. So that's how it is, right? Like C is just like a food gun pointed to both your feet at the same time. It's a quantum food gun. So C is bad, that's the conclusion. Don't call in C if you can avoid it. But let me tell you about other cool stories and bugs. Like one interesting thing about the bugging is this sentence by Nicholas Negroponte that says like, programming allows you to think about thinking and why do the bugging you are learning, you learn to learning, right? And the idea here is quite interesting because, you know, like you need to be a bit smarter than you were when you write the code and when you learn, you are putting your assumptions to test. So the bugging is probably one of the most important tasks as a programmer that you need to do, right? Because you need to have basically everything that you learn and then you understand the system and almost by definition, something will be wrong. So it's a fantastic way to condense and check, very scientific as well, right? Because you do these little experiments and whatnot. So I really like the bugging, not that much because of the sensation, because, you know, it's always frustrating and bugs are kind of hard and whatnot. But it really, really, really puts all your knowledge of the system to test. And it allows you to identify things faster. It allows you to be a bit humble because it's kind of unique to find yourself because you're going to be wrong. Like that's why the bugging, you have a bug, is like there is something that you didn't understood. So you need to find yourself a bit. And that's a super interesting thing, right? Like in systems like C-Python, it can be a bit complex because, you know, like the bugs can be super complex bugs from outer space. But I think it's one of the best activities that you can do to learn as a programmer. Let me tell you about some other weird bug that happened. So for instance, this is a bug that happened on the C-Python test suite. We have this kind of comparison checker class that takes kind of an object and every time it compares equals to something, it adds one to this comparison field. So basically it counts how many times this object was compared. And then in the Python test suite, we have this kind of test where we were creating like some other object. This could be a string or something like that. And then we were creating this comparison checker over a string. So the comparison checker will check how many times this string was compared to. And then we create this dictionary with both things as keys. Then we check if the comparison checker with the same string is in X and then we check how many comparisons, right? Like this thing over here should have created one comparison only because it's comparing against a string. But it turns out that this was failing sometimes, only sometimes, which was super, super annoying. Like it took several hours to understand what's going on because this thing was created only to be compared once and it has been working for years without nobody touching this code. And suddenly one afternoon it crashes with like more than one comparison. So this was quite hard because you need to understand exactly not only how the dictionary is implemented but also all the possibilities that can happen there. Like for experienced Python developers, you probably know what's going on. What's going on is that, you know, like this thing can have a hash collision in the dictionary and then it will compare more times. Like one way to force a hash collision here is to basically make the other object that we were discussing has the same hash as the string. And here what will happen is that once you add it here, then both A and B will be on the same bucket inside the dictionary because they will have the same hash but there will not be equal. So when you check it, the comparison check it is in X, then it will compare first to B and then to A. So the comparisons are not one or two. But how this happened? Like why this was working until one day? So it turns out that the strings in C Python has the hash being randomized. So the hash of the string changes every time you open the interpreter. With the bad luck that there's some other object here that we have, which was just another string maybe or I don't know what it was, but like a method, a function or something like that. So the bad luck was that that thing had a hash only on that execution of the test suite that was colliding for the first time in years with the other string that we were testing. And for the first time in years, the number of comparison was not one. We tells you like something about writing good tests and you know, like probably this was an oversight, but the debugging this thing was quite weird because you are expecting to see something like threads and like, you know, it's a rich condition only happens sometimes, but this was just a plain dictionary. It looked like super deterministic, but it turns out that it was not that deterministic, right? Like, you know, it can be hard. You need to, when you're debugging things, especially in C Python, you need to be thoughtful of what's going on. Let me then go to some other evidence here. So the idea here that, you know, some insights on debugging is that one interesting thing that you can do when you are started to debug something that you really don't understand, like, you know, think about these super complex bugs that you see that were nothing like seems to make sense. So one idea here that I normally do when I debug is that, so I try to be modular. The idea here is that you don't try to change multiple things at the same time, right? Like, you know, just do very, very small things, almost like, you know, like the scientific method, like to do a little experiment, you see what happens. But if you start to change, like, multiple things at the same time, even if it's very tempting because, you know, maybe you're changing like an equal equals and a less than or something like that, because you think both are wrong. Try to do one by one and see what happens because otherwise you're going to, you're going to probably be in nonlinear behavior and you really, really want to see, like, the facts of everything that you think is independent. So, you know, take your time. Debugging is a task that, you know, takes it some time. And if you try to rush it, you probably, you know, will not be able to succeed very well. So, you know, try to do these little changes. Another interesting thing is that, you know, check your assumption and the idea here is that one of the most cool things that I normally do here is to bring to the problem someone who has never worked with that part of the code base, like in CPython or maybe also like, you know, if you are debugging in your company or your own code. So try to try it because these people have superpowers, right? Like, these people will see the system for the first time. So it won't have your biases that you have towards it, right? They will tell you like, oh, yeah, but this thing that you said, it doesn't make sense, right? Maybe you have the thing already integrated and then you say, yeah, this is this wire, right? But maybe these people will tell you, I don't understand like what this is this wire, right? Then the next thing is like, you know, try to break down the thing, right? Like the idea is that there is some super mysterious thing, right? Like if you remember these mysterious things that are driving the back, maybe they are not the back, but they're driving the back. This is what makes the back happen. This is the black hole of the bagging, right? The mysterious invisible force that is dominating the system, but nobody sees it. So the idea is that you don't go, you know, head on towards the black hole. That is a bad idea, right? It's going to trap you forever. So you need to kind of break it down, right? Like you start saying like, okay, so what is the next thing that I don't understand? Like, can I do like a small experiment to understand what's going on? And like, you know, it's not a super smart like advice because probably you're already doing it, but like, you know, try to always think about like small problems. Don't try to like, you know, grab the big problem all ahead. And then the next like advice is like this lay hypothesis, like try to not make a hypothesis at the beginning of the problem because then you're going to go into confirmation bias. Like you're going to say, do you think, oh, I think this is what is happening. And if you don't have enough like information, then what's going to happen is that every behavior that you see from the system, you're going to try to justify towards your hypothesis, right? And maybe what happens is that you are convinced enough, which is one of the most dangerous state to be in. And then what you end doing is like, you implement these partial fixes or hacks, right? Just because you are convinced enough. And then you say, oh, this seems to fix the problem, or even I don't understand why. So let's go ahead, right? So, you know, this is like a small advice that I have learned over the years of the bug in CPython. And I think it will be interesting for you. Let me tell you about another cool thing, right? Like Julie Evans has a lot of discussions on the bugging. And she has these fantastic centers that says like, she lost the bugging bugs because, you know, it means that you're going to learn something new, which is something I always think when I have like some super weird bug happening, like it means that I have not understood something on my system or on CPython, and I'm going to learn something new. So, you know, like at least you have that to, to have in mind, we'll do the bug. Let me tell you some, one of the funniest bugs that we have in CPython is this DPO34 something, something, right? So this bug over here is some bug on FreeBSD. So this bug took like six days to solve just because we needed to like go through to an RFC and find out like, you know, like how the network layer like was supposed to behave. We needed to understand like, you know, how the packets were able to behave on different linear systems. We found this sentence on some forgotten page of the RSC that says that a portable application, like applications that can be making different operating systems needs to be providing some particular thing. So after six days, this was the PR. It was like a one line change. This is six days of the bugging, right? Like just to show you that this can happen when you are doing something as complex like networking. But probably my favorite bug in CPython is this one. It's BPO37213. Deephole Optimizer does not optimize functions with multiple expressions. But I like to call this bug, how a bug in CPython made code formatted with the black format that is lower. So let me tell you all the problem. So imagine you have this list comprehension. You have this X for X in interval if X, right? This is the byte code it generates, right? It's going to build a list. It loads like the interval that we store in this secret variable called dot zero. And then it loads the X to see if it's true or not. And if it's true, it goes to false to the next item. And if it's not true, it loads the X and appends it to the list, right? And then it jumps to the next one. If you see here, there is two jumps here. There is the jump in number 10 and the jump in number 16. Both jump to the next one on number four, right? So when both jumps will go to the same place. But if you break the list comprehension in two lines or three lines, then the byte code is mysteriously different. And the difference is that this jump over here, instead of going directly to four, which is the next item in the list comprehension, it goes to 16, which is another jump, then that then goes to four, which means that instead of like, you know, when it sees that there is an item here and this is all of this false, instead of going directly to the next item, it goes to another byte code that then it goes to the for iter. This is called like jump elimination when this doesn't happen. But it turns out that we weren't doing this thing with a certain kind of code, right? A certain kind of jumps. An interesting thing here is that, you know, like, this is just another byte code, but if you have a super big list comprehension of a loop, this can make your program slower. And, you know, think about a tool that converts very long lines, leading comprehension in one line into like, you know, like like comprehensions, responding multiple lines. So basically, because the code in the bottom was slower due to this bug. So black will have been seen as the optimizer. It was formatting your code and making it more beautiful, but also making it slower. Obviously the bug is fixed and black is not doing that thing anymore. But I always find it very funny that black was basically the first Python and optimizer. You know, interesting thing. So let's go to the kind of like the last, like interesting insight that I have. So these revolts to a story that I saw one day when, you know, like in some Python meetup in Spain. And the idea is that it was this person that was confused by a Python idiom. So this is the Python idiom, this person was confused. Because this person came from C or from Java or like who knows, right? And the idea here is that, you know, they were seeing this code to swap variables, you know, X comma Y equals Y comma X, which we all, you know, we all like coding Python, we love and we understand and it's one of the most expressive things in the language. But maybe not one of them, but like, you know, it's a very expressive thing. And but this, this, this person was like super confused, like why there's no temporary variable? Like how does this even work? Because in C or in Java or whatever this person was coding before, this person was used to have like a temporary variable that was swapping both, right? Like, and the answer to the person, like that this guy was asking, like, why is this happening? It was like, what's going on here? It's tappel unpacking. And that was the explanation. It's tappel unpacking. And, you know, the person obviously that didn't understood the code was given the answer. And the answer is tappel unpacking. And, you know, like, that is my point here and the whole thing that I wanted to teach you here is that tappel unpacking was the horrible as answered in the world. Why is this? Because like, what is even tappel unpacking, right? Like, do you have a person who is not asking a question of like, you know, like, how is, how is this called? It's not how is this called? It's like, how is this possible? And, you know, this person have like is the question is hinting like, okay, so, so how is this implemented? Because in my language in C or Java or whatever, I need a temporary variable. And here I don't need a temporary variable. And, you know, if you throw like a word and this happens, you know, to a lot of us, right? Like you, you are maybe on your, or asking some of your colleges or like, you know, some personal and they give you this like, like, you know, like names, right? And super complex names. And that is the explanation. This is a blue, blue, blue. And like, you know, that is another cool answer. And the reason is because this is stopping you from going deeper, like to understand what's going on. So this person who didn't understood like x comma y equal y comma x instead of like, you know, receiving capital unpacking as an answer. That person will have like going deeper and say, okay, so I have like this code. So what happens with this code? Like what, what, what is going on? It's like the question is, okay. So, so, so this is like Python code, which is obviously going to be translated into by code and it's going to be executed in C Python. C Python is C. I mean, C, you need a temporary variable to do something like this. So the question, one interesting question that you can actually answer, ask yourself, like, is there a temporary variable being used by C Python here internally, like a magic thing, right? Like for us, C Python does this, this nice thing. So it's a temporary variable or not. And that is a super interesting question. So let's try to find out. So when you do this code, it executes to bytecode, right? And the bytecode instructions for this particular operation is a operation called rot to, which means rotate to, which is basically like, you know, swap x and y. So let's see, you know, how that will look like. Of course, like in C you will do this, right? You will have like x, x and y. And, you know, if you want to put x where y is, you will need like a temporary variable. So I'll say, OK, let me save the state of x in my temporary, then let me assign to y and then let me recover y. This is what the person was expecting to. This is, like the question is, like, is C Python doing something like this internally? Yes, no, let's see what's going on. So what's going on, you know, like, when you, like, check the bytecode of this, you will see that the bytecode is like, you load the variable x, you load, sorry, the variable y, you load the variable x, then you execute this mysterious instruction called rot to, like, you know, rotate to, and then you store x and then you store y, right? So it's kind of like, there's some mysterious rotation and then you do some stores. So it's like, it's this rotation on these two stores using a temporary. So let's see, let's see how these two are implemented. So this is the, the C code for rot to. So you see, it's super easy. What you do here is that you take one object from the top of your stack. Then you take another object from the top of your stack and then you put them in the stack in the opposite order. There is not a temporary variable. I mean, you could consider that these locals here could be temporary variables, but they're not in the same sense as this temporary variable that we need in the other example, right? You could store the thing in the stack itself so you don't need C temporary variables or, and actually if you check, you check the assembly, this is actually going to be stored in register. So there is no temporary variables per se, right? I mean, you could also argue that in the, in the temporary variable, this is going to be a register there. But my point here is that here, a confusion over like, you know, how the swap works shows you something much, much more interesting, which is that the execution model is different. The execution model here is a stack. What you have is a stack with the variable. Like, you know, if you have never seen this thing, it's quite confusing, but you know, you can, you can Google it, right? What you have is a stack and then you have like the variables there and to just swap two variables on my stack, I just pulled them from the stack both, like I take the top and the second and then I put them in the stack in the opposite order. And that basically swaps the thing. Like if, if instead of X plus Y, I want to do Y plus X, I will take X, I will take Y and then I will put Y and then I will put X and or the other way, right? And the idea here is that, that this is a much more interesting thing. If this person that was confused by the double unpacking answer will have like go a bit deeper and it's like, so, so why I'm confused? Like, why is the thing that I don't understand? What is the black hole in this system, the invisible thing that is driving the whole thing? It will have understood that, you know, like there is a new thing that maybe you didn't knew that is that CPython in particular is using a stack machine as a, you know, as a execution model. You could also keep going deeper. There is like deeper as much as you want. You could say, okay, so this is C, but what happens like when this C is compiled to assembly? So what happens is this thing, this is the assembly code that is being generated, which is like, it's like a bunch of moves, right? Like if you check what's going on, is that the every two moves is basically one of these instructions here. And what you see here is that all of these are basically using like two registers, right? Plus offset, right? It's using the RVP register and the racks register. You don't need to understand this code. The point here is that what you need to know here is that, you know, assembly is a register based machine which also has a stack. So you could also say like, okay, so, you know, my code that swaps two variables, which is implemented in Python is transferred to bytecode, which is derived by C using a stack. That's why I don't need a temporary variable. But then you could say, there is a temporary variable in the C code. And then you check, okay, so that is translated then to assembly and is this bunch of move instruction, which is just the move instruction is basically moving things from memory. Although, you know, it turns out that this thing is too incomplete, by the way, like you can absolutely do a compiler that only meets move instructions. Some person has done that actually. It's called the MoFuSkator. It's quite crazy, like how powerful just moving things in memory can be. So in particular this code is just like a bunch of move instructions. But then you can discuss like, okay, so, you know, there is a temporary here and it turns out that there is another execution model which is totally different here, which is, you know, like a register stack machine. And you could think of the register as temporary or not. So it is now up to you to decide if at the end of the day it was or not a temporary variable. But you know, a person who have the time to go deeper and like, you know, maybe ask questions to people on this too, it will have discovered all this beauty, right, all this execution models. Like, I don't know if you have seen this meme, but is there like the Python programmers saying like, okay, so it's X plus Y, all an abstraction. And you know, like, like C plus plus and everyone's like, yeah, always have been right. And maybe you can even go to transistors if you have like some time or physics or electrical engineering, you know, it's interesting. You can keep going, like going deeper is something fantastic because it's something that will tell you like the behavior of your system, right. So I wanted to finish just as a talk, right. And the idea here is that in the same way, you know, the black hole was the mysterious thing and the dark matter here was the mysterious thing driving the whole system of these stars. These examples that I showed you are things that, you know, are hidden at the beginning, but they are driving the whole thing. And this is the thing that you need to do, right. You need to seek the dark matter in all these examples to have a better understanding. And I think you will be a much better professional and a much better engineer if you seek these invisible forces, right. That's, I think, I hope I have not burned out of extra time. So that's the finish of my talk. I hope you have enjoyed it. Thank you very much Pablo. That was an excellent talk, very exciting, very deep as well. Unfortunately, we are running out of time so we cannot answer any questions in this main room, but I would suggest that you perhaps go to the breakout room, Optiver, on Matrix, and then you can answer questions there. I'm gonna copy the questions that I collected to that room and then you can have a look there. So everyone is very excited. You're getting a nice applause. Thank you. Nice. Yeah, we're kind of trying to simulate everything, right? That is very needed in these times. Okay, so yeah, I very much enjoyed your talk. Thank you for coming to the conference. Thank you for the keynote. And I hope you enjoy the rest of the conference. So we will now have a short break and then we will head on to the next session. Bye-bye. Bye-bye.