 Hello, and welcome back after the short break. So in the next couple of minutes, we are going to see David Beasley, who is a very well-known speaker. He's been giving great, great talks and keynotes at several conferences, also at EuroPython in Edinburgh. He's also the author of several books, and he has been using Python for a long, long time, 25 years, it says here. We're going to hear about a bike riding story from him today. I wonder what that is going to be about. It's definitely going to be amazing, and I'm really looking forward to it. Hi, David. How are you today? Good. How are you doing? Excellent. Can you hear me OK? Hear me OK here? OK, good. Yes, yes. And thank you very much for getting up so early. David is in the US time zone, so it's 5 AM for him now, which was quite early. And but he said that it's not a problem. He's usually out bike riding at this time. Yeah, I'm usually out bike riding right now, so yeah. You're looking at my very fancy basement office here. All right. It's north of Chicago here, so. Very nice. So I won't take more of your time, so I would suggest that we put up the slides, and then I will move off stage and be back again for the Q&A afterwards. Thank you. OK, well, I'm very excited to give this talk, actually. So thanks for coming to this. So one of the things I do in my spare time, besides biking, is I play in a concert band. I play trombone. And one of the things in band is sometimes you play in piece and music known as a tone poem. And usually what this is, is it's a piece of music that is inspired by something maybe non-musical, like maybe a painting or something. So you take a painting, and then there's a piece of music inspired by that, and you play the music. OK, so this talk, in some sense, is that I'm going to be using the language of Python to describe something that's, well, really not Python. You'll see. So that's kind of the spirit of it. And then the other thing with biking, there is a certain danger of going biking at about 5 AM. So about a year and a half ago, I hit a deer in the face while riding my road bike and ended up breaking my wrist and two fingers in opposite hands. But that's not the deer, by the way. The deer, as far as I know, is uninjured. This is the picture you see there is probably from a coyote. Not far from where I actually hit a deer, actually. This is the same bike path. But there is a certain problem with having an accident like that, which is it makes life very difficult for somebody that likes live typing and live coding and things like that. You know, it's like, this is definitely going to put a damper on things. And so that's the not typing part of the talk. I'm actually not. It's not about the typing module. I'm sorry about that. So having this accident, I kind of spent some time looking at some different things, learning about some new stuff. And the talk is kind of inspired by that. So one of the things I was thinking about with the accident is I'm really glad I didn't hit a deer with antlers. And I'm really glad I didn't hit a deer with antlers guarded by another deer with antlers. This would have been a really bad situation. But this idea of pairs is actually something that comes up a lot in programming, where we think of pairs of numbers for math operations. ALU on a CPU takes pairs of inputs. Everybody's favorite data structure, the Python dictionary. You've got keys and values. It's pairs, right? So left and right, first and second. Pairs are sort of fundamental. And actually a lot of computing. We use these all the time. And one kind of interesting exercise you can do is restrict yourself to only programming with pairs. This is a new style guide. You're not actually allowed to use Python lists or dictionaries or sets or anything like that. The only thing you can use are pairs. And you can challenge yourself to make data structures. So what a list might look like is something like this. It's consistent of pairs. And then you have a lot of fun writing algorithms on this, like computing the length. Or maybe you want to practice recursion. Or maybe you really like reversing linked lists because you have a goal of getting a job playing foosball somewhere. So there's all sorts of things that you can do with this. But frankly, that's not really that interesting. I mean, well, it's kind of interesting. But nobody really cares about implementing linked lists or reversing linked lists. So a different line of thought that you might have is all of the different ways that you might implement a pair. I don't know, do you use a tuple? Do you use a list? Maybe a dictionary? A class? A class with slots? Maybe you like data class. Oh, data class is definitely. Or named tuples or a classic named tuple or a third party package or some crazy Lambda function thing. There's going to be a quiz on this code later, by the way. But you might go through that. And again, it's like, OK, we could have a battle about the best way to implement a pair, whether a data class or a tuple or something like that. But honestly, nobody really cares about that. And here's why. So imagine if some object, this is a pair of numbers. What do we actually care about here? Do we care about the internals? Or do we care about something else? And what we really care about is whether we can split it apart again. Kind of the essential property of a pair is that you can split it. First element, second element. I'm going to use F and S for first and second here. So that is sort of the property we care about. And as long as we have that, we sort of don't care how the thing is implemented, right? I mean, you could have a pair that uses tuples or you could have a pair that uses dictionaries. And it's fine. And this is something that we're all familiar with in Python. I mean, this is duck typing kind of stuff. It's interfaces. As long as something has the interface, you don't really care what it is. So we're all familiar with that. But there's a different line of thinking on this. So here's kind of a flipped question. I mean, we know that something is a pair based on whether it has the interface, right? But do pairs know that they're pairs? Kind of a weird question. So here's scenario. Let's say you have a pair. Let's say you have a class that you definitely know implements a pair. But then you have some other class, plu or something. I don't know what plu is. But you can create a plu object, 1, 2. And you can ask a question, is that a pair or not? And I would hope that the answer is I have no idea. I mean, plu is something we don't know what that is. It's not inheriting from pair. It's just some random thing. So we really don't know. But suppose that there was some function unknown to us. We don't know anything about the internals to this. So this has been provided from somewhere that takes a plu and produces a pair. So there's some way to go from plu to pair. Does that make plu into a pair? Does that make it a pair? And again, the answer is not really sure. I mean, without knowing any details about A, I wouldn't be able to say for certain. I mean, maybe this is some other thing that's producing a pair. So I honestly don't know. And it does kind of raise this question of what would the requirements be. I mean, if plu were a pair, I would have to retain this ability to kind of split it apart, right? I mean, I would have to be able to get to the one and the two. And I just don't know whether I can do that. I know that if I know that with this A, I can convert it. I can produce this pair-like object, right? I mean, it can produce a pair type of some kind. And I can split that. But I just have no guarantee what it's going to do, right? I mean, maybe I do that and I get some different values out of it. And then it's like, I don't know what that is. But if I were to be able to do this, like, let's say it actually worked, create a plu, I adapt it, and then I get one and two. I might be able to argue that actually plu is a pair and it doesn't even know that it's a pair, OK? So maybe it's like, yeah, I can use that as a pair because I can adapt it, basically. I can convert it to P. And then I could use F and S. And then everywhere I wanted to, I could use plu as a pair. So it's kind of a strange line of thinking, but it sort of leads to this rule that if something can be adapted into a duck, then it's a duck. And you can start playing games like this. You can start thinking it's like, oh, I can adapt things. And so there's all sorts of ways. You can convert tuple to dictionary. And dictionaries to tuples and classes to dictionaries and classes to tuples. And we do this all the time in programming. It's like adaption, adaptive pattern and stuff like that. It's how to make a small program into a huge program. That kind of stuff. And eventually, you'll sort of tire of this game of adapting. But then you might start to ask deeper questions, OK? This is a more interesting question. Is there a perfect implementation of a pair? This is how one starts to get into big arguments at work, right? The bike shedding argument. What is the perfect implementation? And so suppose that aliens came down from space and they presented a pair, like a pip install pair. So we have aliens presenting a pair to us. And there's a claim on it, a pair perfect for humans. Bold claim. We're going to be very skeptical of this. And ask questions like, what do you mean perfect for humans? Like, what do you mean perfection? What are you talking about? And the idea, that actually leads to kind of an interesting thought experiment, actually. What would it mean to have a perfect implementation of something? Not to say that it's perfect. I mean, the aliens would just say, look at it, it's perfect. And it's like, well, that's not going to fly, OK? So how would you prove this? Well, one of the ways that you might investigate that is you might make a claim that any kind of inferior pair could be upgraded into the perfect one. You could adapt it. Like, you could basically say, yeah, OK, you're using tuples. But we were going to do this more perfect thing. And so you could take all of the kind of lesser pairs and adapt it. But then somebody is going to ask, well, couldn't you go the other way? Like, couldn't the perfect pair be downgraded into a lesser perfect one in some way? And then we're going to have this argument again about which is the perfect pair. And so clearly, this is never, ever going to be allowed. I mean, if this perfect pair is perfect, it is ever, never going to be able to be downgraded. Now, I have no idea how this is going to be implemented. I mean, I'm not even sure Raymond Heddinger knows how to implement something like this. But the gist of it is that this perfect pair would only be adapted into itself. That's the only thing it would ever allow. It's like the perfect narcissistic pair. In fact, the arrow is even orange. OK, so there's sort of this limit of perfection. It's like, OK, that's kind of a weird concept. You've got this perfect thing that only adapts to itself. But what if you know nothing at all? OK, so here's, so let's say aliens come down. They present this thing to you. And they just tell you documentation. Just look at it. OK, we don't know what it is. OK, you're presented with this object. Alien object, you don't know what it is. Can you make any claim about it? And I don't know, just looking at it, maybe you can do things like wave your hand at it or stare at it or something like that. Maybe in the process of waving your hand at it, two things pop out of it. And then you can ask this question. It's like, OK, is that a pair? Maybe. It was one thing and now two things, right? I don't know, split apart. And that line of thinking, again, kind of takes you back to what is the essential thing that is going on with pairs here? Is it the thing? Or is it the arrows? The arrows, in some sense, are giving it shape, right? It's the arrows are sort of defining the deck that it's splitting apart. And so instead of talking about pairs, I actually want to talk about arrows for a second. So let's say you have an arrow. What is this even talking about? What are we even talking about with an arrow? Is this like an input to a function? Is it an output of a function? Is this a value of some kind? Or is it a type? And of course, you know that it's a type because you saw the title of the talk. It said types, right? So at some point, I was going to talk about types. So let's explore this a little bit. So imagine an arrow is something coming out of somewhere and it has a type attached to it. And as programmers, we're familiar with concepts of types. We have int and bool and float and string and so forth. And being sort of a systems programmer myself, I'm thinking a lot about hardware. It's like, oh, this is 32-bit or this is 64-bit int. And I got to encode this and think about little endian and all this stuff. So there's this concept of types. But this is not really the interesting thing with types. Int is not interesting. I mean, what's interesting is when the types start to pair up and we're now we're back at the beginning, a pair and a pair of pairs, okay? Things like what is going on if you start messing around with types? Like pairs of types, combinations of types and so forth. And so I'm going to kind of go through a few little thought experiments concerning combinations of types and pairing of types. So imagine you have a pair of types, pair A, B. Is that the same as pair B, A? Like if I just switch the types around and I think most rational programmers actually would look at that and say, no, no, that's not gonna, no, like an int and a float is not the same as a float in an int. I mean, a type checker is gonna blow that up. And so you look at that and then say, no, not really the same, but I could come along and say, well, you know, I can write a function that just swaps the elements. It's really easy to do that. I could just swap the elements and then I can go back to my rule that I had earlier. It's like if it can be adapted into a duck, then it's a duck. So you can look at that and sort of say, well, you know, I could go between the two and I'm not gonna lose any information. And maybe I'm, you know, I'll use like my force of status or something and say, well, you know, actually those actually are the same type. Okay, well, maybe not quite the same type, but they're an equivalent type. I can go back and forth between the two. So that sort of introduces this new line of thinking, which is basically if I have something that can go back and forth between a duck, I don't know, if I could convert a duck to a goat and then I could take a goat and convert it back into a duck, then I could say, well, the goat is basically equivalent to a duck. Okay, so this is kind of a new rule. I mean, one way to think about the rule is it's kind of an extension of what you do in Python already. Like, you know, is this the same object and equals the same value. And maybe there's some new operator, I don't know, this squiggle thing here where I claim that two things basically have the same quote structure. Now I've put structure in quotes because it's kind of a loose idea. Basically means I could convert one to the other and back and get back to where I started. As an example of this, here's kind of an example. It's the tuple AB equivalent to the string containing the tuple AB. As Python programmers are gonna look at that and say, no, that's crazy, but I could claim that those are actually the same because wrapper takes me one way and eval takes me the other way and there's no information loss. Actually, the only thing that would be lost here would probably be my job if I started claiming such madness at work, right? Okay, so, but under the system of rules that we're working with right now, those are the same. And you can kind of extend this into other thought processes here. Like, what if I had a pair with a nested pair inside? Pair A paired with pair B, like pair B, C like that. Can I just move the pairing? Can I just shift it over? Is that the same as pair, pair A, B, C, like that? Are those equivalent to each other? And the answer is yes, they are equivalent to each other, although the code is a little painful to read in the way that I've done this. Basically, you can shuffle things around and those two things are equivalent because there's no loss of information. Like, I can convert from one to the other and I can go back the other way. Here's kind of a trickier one. What if I had a pair and I had none on it? Pair of none type, what is that? None is kind of weird in Python, right? I mean, none is actually this thing that exists but there's only one value of it, none. So it's a singleton. And so, I could certainly ask a question, is there some way to simplify this thing? Like, is there something equivalent to a pair of A with none and it turns out the answer's A. Why is it A? Well, I could just get rid of the none. There's no loss of information there. So I could just convert it to an A and then if I wanted to convert it back, I just stick a none on it. I know what none is, none is none. So whether I have it or not is sort of immaterial, right? So those two are equivalent and essentially you build up a set of rules doing this. Pair AB is equal to BA and then you can move the pair and then you got this none thing. So in some sense, this is kind of a set of typing rules about pairs and it's slightly kind of extended universe. Okay, I mean, you might be looking at this saying just Dave has just completely gone off the rails with this weird equivalence rule, but it kind of works. Okay, so that's one line of thinking about arrows. Basically, we're talking about arrows and you can put a type on it. You can put a type on the arrow and then you can start thinking about pairs of arrows and all kinds of other things. So there is another line of thought though on arrows. Okay, so let's say you had an arrow and I wanted to do something other than put a type on it. What can I do with it? Well, one thing that you could do with it is just change the direction, just reverse it. Reverse arrows, okay? Just take all the arrows and reverse it. This is actually something really good to do in real life, by the way, not pick on Brian here, but just take like screws and nails and stuff in your house and just put them in the reverse way and then just see if people ask questions, right? Okay, so we're gonna reverse all the arrows. Okay, so imagine this scenario. Alien comes down, presents this magic object and instead of arrows coming out of it, it has arrows going into it. And then it's sort of weird. It's like once this alien object has, arrows coming in, suppose that you can adapt it into different things, like you can adapt it, but you can just never split it anymore. It's like the reverse of a pair. It's like, I don't know, it's like you put things in and you can never split it, but you can repaint it and reshape it and deform it and melt it, bury it and all this stuff, but no matter what you do to it, the thing is basically indivisible. It's like a permanence to it. It's like this, you sort of have this shape that looks like this, two things come in and then there's like this, you follow the arrows, but there's kind of this finality to it, right? It's like once the two arrows come in, you just can't do anything with it. And so the question with that, reversed arrows again is what is it? Like how would you describe this thing? Like, okay, what are we looking at? And maybe after a bit of study on it, you would conclude that this represents choice. It's not two things paired together. It's a choice of one thing from two things. And so examples are things like bits. Maybe it's one or zero. It's left zero or it's right one, but it's not both. It's either left zero or right one. Maybe it's a Boolean of some kind, like an if, else kind of thing. It's like it's either true in A or it's false in B, but it is not both, it is one or the other. It's either A or either B. More interesting case would be something like a Python function. Let's say you have the most, just a really simple function involving ints, return x plus two. It actually follows the same shape. Maybe there's an input like f of two where you get a value and you get a result back. Okay, you get a value four. Now, you might be looking at this and sort of thinking like, well, what's that? What's the second arrow? I don't see any choice in here. I don't see any if statement or anything like that. Well, I'm not talking about an if statement. I'm talking about exceptions. The other arrow might be exceptions. Like if I put two in there as a string, you get an error. So Python function is a choice. It's either you get a value or you get an error. Not both, but one of those. Okay, so this sort of line of thinking kind of leads to some parallel thought with the pair thing. It's like, you can start thinking about, well, okay, what are the rules for this choice business, this either business? Like, can I switch the A and the B? I think you'd argue, yeah, it's like you're picking one or the other. It doesn't really matter what order they're listed there. And you can also kind of shift the choices around. Like, is the choice of either A and either B or C the same as just moving the either over there. And again, those are basically equivalent. I mean, you're choosing one value and it doesn't matter really whether you decide to choose the A, B first and then choose the C, between that and C, or you go the other way. So there's sort of a certain similarity to what we had before. But then you sort of get to this little riddle. Okay, so here's kind of an interesting little thought. Okay, so none in Python is something that exists. It actually, it exists. Okay, I mean, I can type it in the REPL and it exists. Okay, so none is not none, it's this object, it's none. And this world that we're working in is this world of reversed error. Everything got reversed, right? And so what is the reverse of none? Like, if I were to reverse none, what are we talking about? None is something exists. It doesn't have many properties other than existing. So the reverse of none is maybe this concept of void. None or void, what does this mean? Okay, so void, this is not a Pythonic kind of concept, really, but void is essentially a type that can never ever exist. It's the opposite of existing. None exists, void doesn't exist. So imagine you have a class, if you try to create it, it just instantly blows up. Can't exist, okay. This leads to some other rules, like what if you had a choice of either A or void? What is that equivalent to? Well, it's equivalent to A. And the reason it's equivalent to A is that you can't create voids. Void can never exist. And since it can never exist, you can never create it. And since you can never create it, you can't choose it. It's not a valid option, okay. So the type either A, void is A. Just as an aside, by the way, you can create things from voids. If you wanna have a function that just spontaneously creates 42 out of nothing, okay. Like the empty parans are like void. You can do that. You can implement the big bang. You just can't implement the void, okay. So that is perfectly allowed. And so this leads to another set of rules, basically rules about this either operation. It's kind of in this universe with the reversed arrows, right. It's like, okay. And if you pair that up with the other rules, essentially you have rules of pairs and you have rules of choosing. And the thing that you're gonna notice here is that basically the rules look almost identical to each other, except for the none void thing, okay. So none and void are kind of opposite concepts. None exists, but void is something that can't exist, okay. So you have that. As a final kind of line of thought, you can ask questions about whether these, what happens when these mix together? Like what happens if you create a pair and you put a void in there? Is that equivalent to anything? What's that equivalent to? And it turns out that that's equivalent to void. The reason it's equivalent to void is you can't create voids ever, not as part of a pair, not in a data class, not in a struct or anything, okay. Void can never, ever be created. So if it were part of a pair, you wouldn't be able to create that either. It's like a, I hesitate to say the word virus, but void is like a virus on the types. Like you put that in there, you can't create them. A bonus kind of trick question is what if you have a choice of two pairs but the pairs have some commonality to it? Like let's say they both have an A. What is that? Well, you can rewrite that in a different form. You could say this is a pair where there's an A and then it's either B or C. There's basically what's going on there. It's either choice has an A in it. So you have that. There's no question about the A. The only question is about the BC part. So putting all this together, you get this kind of, this system of type rules. Okay. We've written some rules and they kind of come from different worlds. I mean, the thing I think it's interesting, you know, there's kind of the world of the forward arrows. That's the pair world. And then there's the world of the reverse arrows and that's the either, the either world. And so, so let's say you work this out. Okay. Work this whole thing out. And then let's say you're the one to beam it to aliens. Okay. We're going to flip the roles here. It's like, okay, you're going to give this away. Or maybe you're actually not aliens. Let's say you're just going to give it to your coworkers and or maybe you publish it in a conference or something like that. Okay. So you work out this system of type rules and you're going to give it away. And naturally, when you give it away, the aliens and your coworkers are not going to see it the same way. They're going to see it probably something like this. They're going to look at it and say, what is this? What are you talking about? Is this some kind of quiz? And you're going to say, no, it's not a quiz. It's a job interview question. This is what we give our job applicants to find out if they're 100X or not. We give them this question and we ask them, what is this? Okay. So that is kind of leads to an interesting thought experiment as well. Like if you were given this with no background information at all, just out of the blue and you were asked to describe what it is, what is it? Okay. You're going to sit there and like study it a bit, right? You know, it's like, huh, okay. What is this? After a certain amount of coffee and maybe a long bike ride or something like that, you might actually conclude that this is algebra. This is describing algebra. And here's the rationale on that. Maybe the emoji, the hands there, maybe that's like multiply and the finger is like plus. Maybe these are describing operators. And what you're seeing there are actually some rules about like sums and products. You know, the fact that you can like switch the order or you can do the grouping, you know, in different order like that. So maybe that's what's being described in the first part of this is kind of multiply and divide, you know, multiply and add, you know, kind of rules like that. Maybe the little arrows are like one and zero. And so what this rule is, the third rule there is sort of saying that A times one is equal to A. A plus zero is equal to A. These are sort of algebraic rules and maybe the other rules are some other, you know, some other rules from algebra. You multiply something by zero, you get zero. The other one is sort of distributing things or factoring that kind of stuff. So maybe somebody would make a claim that this is algebra and you would actually be correct. One of the things that's out there is this concept of algebraic type systems. This is something that you sometimes see in other programming languages. They'll claim that, oh, we have an algebraic type system. And usually they throw around terms like, oh, we have product types and sum types. And usually what they're talking about is you have structs and records and you have enums. Enums would be kind of a maybe a weak area of Python or maybe a more, that's probably a new, like Python traditionally has not had a whole lot with enums but it's starting to show up. But this is kind of the foundation of algebraic type systems is this idea that types can be expressed in algebra. Now, I wanted to do one example of this that just kind of sort of blows my mind on the algebra side. So let's say you had like a list of T's, I don't know, like a list of ints of some kind. How would you describe the type of that in this system that we formulated? Now, as a Python programmer, you might run into this and you would just say, well, this is list T. I don't know, typing module or something, list T. And I'm gonna get super annoyed by that. And in fact, I'm gonna dock full points because I'm gonna say no, use algebra. That's not algebra. I don't know what that is. That's just something else. Okay, so you're gonna look at that and say, okay, Beasley, what are you talking about? And here's the line of thinking in algebra. Maybe you use none to represent an empty list. And in this whole system that we formulated, none is basically like the one object. Okay, it was like this weird, it's a singleton. One is the one, none is the one. It's just the one object. Okay, so maybe list is one. And then if you have a single item list, maybe that's T, maybe T none is represented like that. This is a choice basically at this point. It's like, I either have a choice of none or I have a choice of a list with a T in it. Plus is choice, it's not both, it's a choice. It's either empty or I get a T. And then you can ask, well, how do I get, like, how do you get all these other T's? One way that you might do that is through recursion. You might read a little funny, but what you're saying here is that this is, okay, I have a choice of either an empty list, one, or I have a T followed by another list. It's recursive. Okay, so it's this recursive definition of the type. Now naturally, you know, people are gonna get annoyed by that or like, in Python, we don't do recursion. What are you talking about? Hate recursion. There's a recursion limit, okay? Beesley, what are you doing recursion for? Okay, so if you didn't wanna do recursion, there's another way to express the type, which will probably equally annoy people, but another way to express the type is through infinite series. You can say that a list is basically the infinite series of T to the N power. You're like, okay, what? Okay, so really read this as like, it's either an empty list, one, or it's a list with one T, or it's a list with two T's, or it's a list with three T's, or a list with four T's, and so off to infinity, okay? So this will be left as an exercise, by the way, how to express this for like type hinting or something like that, right? Okay, so you can do it as infinite series. Now, having shown you infinite series here, here is a really interesting line of exploration. Infinite series is actually something that one studies in calculus class, and one claim about calculus is that people sort of say that, oh, calculus, that's totally useless for programming. We don't do calculus. Well, I mean, okay, maybe you're making games or something, but like for just programming, there's nothing in calculus that's useful at all. But one of the things in calculus is you talk about infinite series, and it turns out that this infinite series actually has a result that you can compute. Now, never mind the fact that calculus, it's like for numbers, has to be less than one or something like that, but there's a result that you can compute, and being a Python programmer, I'm just gonna duck type this thing. In fact, I'm just gonna write that list T is equal to one over one minus T. I have no idea what this means, okay? T is a type. What is division of types? What is subtraction of types? I don't know what that is, but I'm gonna continue in my duck typing world here, and I'm gonna just do algebra on it, okay? One minus T times list T is equal to one. Again, I have no idea what this is doing. T is a type, okay? So, but we're gonna continue. We'll multiply the thing out. List T minus T list T, and then I'll move it over to the other side, and then I'll notice, hey, that's the same definition as the recursion. It's the same type. As I mentioned, there will be a quiz on this later on, okay, algebraic type system. Okay, that is an interesting, weird, strange, strange world. Now, going back to the original question, though, back to the symbols, okay? So let's go back to the quiz, the job interview question. Somebody else might look at this and say, you know what I see? I see something else in this system that you've created here. What I see is actually logic. I see the rules of logic. Maybe the hands are the and operator, and the, you know what he figures, the or operator. And I have rules of like and and or, and maybe the arrows are true and false. So a and true is equal to a, and a or false is equal to a. These are statements that we know from Boolean logic. Maybe this whole thing is actually describing kind of a logic system. And the answer to that is yes, actually. There's a whole, so you can view types, like a type system is a system of logic. So, you know, if types encode logic, you can sort of run down this other direction as like type checking, is that a type of proof? Are programs proofs? Are proofs programs? What can you instantiate? That's kind of an interesting question. If this is logic, are you allowed to instantiate falsehood? You can't instantiate void. That was the distinguishing feature of void. So like, if you're, if this is logic and void is the same as false, it's like, huh, okay. That's sort of interesting and I'm getting a wild thought there. And then, you know, again, going back to the, you know, back to the magic language here, somebody else might look at this and maybe they conclude that this is a language for describing diagrams. I would actually kind of worry about that person a little bit, because it's, you know, that might require more thoughts on it, but having gone through this, you suddenly have this question of like, what are we talking about here? We talking about algebra? Are we talking about logic? This arrows business? What are we doing here? Are we talking about types? And the answer is yes. That's what we're talking about. And that's the end of this talk. Now, having gotten to, that's the end of the tone poem part of this talk, you're gonna look at this and say, what was that? Okay, like, what are you talking about, Beasley? Okay, so let me give you a little, let me give a little backstory on this, okay. And then we'll, we'll talk a bit. Okay, so one of the things that's happening in Python right now, there's a lot of interest in typing, static type checking and type hinting and all this, a lot of stuff with types. The thing with types though, is that is a pretty big ocean. Like, if you look at it at the world of types, it is way bigger than Python. There's a lot of kind of weird stuff out there. I mean, like, if you get into the world of like type functional programming and all this stuff, there's a lot of stuff with types. And so after I had my bike accident, so I had my bike, getting back to the bike accident with broken wrists, I was sort of at a loss of what to do in the morning. I mean, it's like, you know, I don't want to just sit around my house and do nothing. And I was like, you know, maybe, maybe I'll get a, maybe I'll get a gym membership. So I signed up, you know, signed up for the, signed up for the gym and went over there and it's like, you know, I'll just do stationary bikes or stair climber or something. The problem is the gym for me is just super boring. Oh God, it's terrible. So, so I was over there. I was like, you know, I should, I should learn something. I don't know. I should learn about something new, something that I don't know anything about, not async IO, you know, like the usual stuff, something really, really, really, really different. And for reasons that I do not understand and cannot explain, I decided to answer the question, what is category theory? Category theory is one of these things that you hear sort of typed functional programming people talk about. And then usually it goes off into some really big discussion of all sorts of terminology you can't understand. So I ended up dropping into category theory from like, you know, just out of nowhere. And I ended up watching probably about 80 hours of courseware on category theory. And this talk in some sense is a very, very, very, very impressionistic painting of category theory. So a lot of the things in this talk, what that is about is actually thinking about, I don't know, maybe shapes of things like arrows, like the relationships between objects and other kinds of related things. And a lot of the ideas in the talk are actually very category theory ideas. Like all that madness with like the perfect pair and like that's something like a categorical limit that people talk about. And this idea of reversing the arrows and all this stuff, those are ideas out of category theory. But there's also some ideas kind of floating around that topic related to types as well. There's an intersection of typing and algebra and logic and category theory where you can kind of notice that basically there's a lot of similarities in these topics and they all kind of intersect with each other. So, you know, another, you know, there's sort of direct inspiration for this talk is actually something known as the Howard Curry Lambic correspondence has to do with the intersection of these topics. So it's kind of interesting. It's like, could I talk about that without talking about it in some weird way? Now, as far as what this might be relevant for Python programmers, I have no idea. I will say that exploring this has had kind of a profound impact on how I think about Python in kind of a more nebulous kind of general way. One of the things that it's got me thinking about is the importance of interactions between pieces like APIs, like how do things compose together, how to features interact with each other and stuff like that. So that's sort of interesting, but beyond that, I don't know, I think maybe the interesting thing is that, you know, in this kind of ocean of types, there are other things out there and this is an example of another thing. I mean, it might counter it if you hang out with too many Haskell programmers or something. So anyway, that is the end of the talk. Sort of thanks for listening to that. A couple of things at the end. I have included a few links that are mainly my entry point into this crazy topic. I mean, if you're interested in looking at that category theory, this is how I entered that topic. There was an MIT course on that and there's some reading about that. Also just shameless plug the, I have a new Python book coming out. It just went to print yesterday. So you can look at that. I'm not gonna say any more about that though, but thanks for coming to the talk. Maybe there's time for a question. Wow, you got a whole bunch of people in a room there. Yeah, well, we organized something and then, you know, recorded a video of it. Yeah, yeah. Well, that was an excellent talk. Thank you very much, David. I mean, the audience is completely excited and there was lots and lots of discussion in the room. Maybe you can have a look at the room afterwards. Okay, yeah. And then, you know, just lots of really nice comments and, you know, theories and it was really interesting to read all of that. I have a couple of, yeah, go ahead. I was gonna say, just a comment. I had no idea that algebraic type systems was kind of this thing. I'd heard the term for years, but as a programmer, I was like, I didn't know what it was. No, me neither. Yeah, I was like, yeah. When you started, you know, describing all these things, I immediately thought, hmm, this is algebra, right? That was really interesting to see all these relations and to see all these, you know, the logic behind all of this. To me, it also shows that, you know, typing may actually be a bit frightening to people. So, because of all these weird things that can happen, and I've seen quite a few cases where people try to actually express in a type annotation what they really want to express and then have lots of trouble with that. And I think that goes a bit into that direction because the topic is actually quite complex and not something as, you know, straightforward as just writing some Python code, right? I think there's also like a, there's like different direction too. Like this is the thing that I've, I've kind of come at typing through algebra here. And that's a totally different line of thinking than coming to typing through like systems programming. Like I'm a C programmer. That's like a totally different reality than algebra. That's. And see, you typically know what you're dealing with, right? But in Python, if you have a dict of, you know, lots of different types and then it's basically somewhat different. So, two questions I have here. I hope I gather everything. So, first one is, what is your study background? People were wondering. Because it's really deep what you're talking about. Like in school. So, I was a math major. And I actually was in a PhD program in math and I got kicked out of it because I failed algebra, believe it or not. I like, I could not figure out what was going on in algebra. I ended up going into, I started taking physics classes and then at some point in graduate school, they're like, Beasley, what are you studying here? I'm like, I don't know. And then they're like, well, get out. And then, so I survived like two years of a graduate program in math and then switched to computer science. Interesting. And now you're learning category theory, right? It is extremely punishing for me. I realized that like this is like confronting this has made me confront like fears from my past. I mean, I literally like failed algebra due to all the diagram stuff. I was like, I don't know whether I missed a lecture someday. Did I, was I out sick or something? But I just remember coming into class and then it just was off the rails. And I was like, I don't understand a single thing that's going on in here. And just never, never recovered. And so, you know, doing the category theory. It's like, this is probably the craziest thing that I could be looking at for somebody who's studying numerical analysis. Like that's kind of ended up what I was studying in math was that, but. All right. So we have a second question here. This one is Haskell like type inferences coming to Python anytime soon. What are your thoughts on this? I have no idea, but didn't go. I think Guido just had something like yesterday was there was some big event where it's like somebody's going to teach Guido F sharp. And I have no idea, you know, I don't know what's going to come out of that, but, but the, you know, yeah, I, I hadn't, I had no idea. He's not really a fan of functional programming, you know, right? Yeah, I know. I mean, actually another bit of that actually programming in ML. I did a not, I actually did learn a bunch of programming in standard ML back in graduate school. My experience with that is actually what led me to Python. I found the strict typing environment of that to be sort of very difficult to wrap my brain around it. It was sort of, you'd have these experiences where you just sit there and fiddle with the code for like three or four hours and never ever having it compile. And then you would make like a sudden change and then all of a sudden it would compile and magically give the right answer. But you'd have like, I'd have no mental concept of what I did to make it give the right answer. But, and then I would just turn it into the, to the TA saying, okay, my homework is done. I have no idea why it works, but it compiles. And, you know, I, maybe, maybe that was just immaturity on my part. Maybe I didn't quite get it, but I kind of, you know, in Python, I kind of like more of the, you know, the more immediacy of it, you know, where it's like, the code can run now, even though it's broken. At least you get an exception, right? Maybe I'm just better at, maybe I'm better at debugging bugs than debugging compilers that I'm willing to admit that. Okay, so let's see. We have one more question by Lukas Langer. Who you probably all know. Yeah. That one up. Do you think the choice type, typing paradigm, you discussed in terms of error handling as used in Rust has a place in Python? You know, that is a really interesting question. And I honestly, I think it might, I mean, that might be kind of a weird thing to say, but one of the things with exceptions is that they kind of fall outside of all of the typing stuff to me. Like, I mean, like if you sit there and you do type hinting and you're in on that, exception handling is this really weird, just kind of outlier out there. You know, I get this in classes. People ask, hey, can I figure out what exceptions a piece of Python code will raise? And I have to tell people, it's like, no. Well, unless you want to read the source, I mean, there's no way to, there's no way to know. And so you've got this, you've got this, you've got all this typing and then you've got this one thing, exceptions that sort of sit outside the rule. And I don't think anybody is proposing to put like checked exceptions in the pot. Is any, I don't think there's any proposal to do that. And so, you know, maybe, you know, maybe Python will start using monads, not to use the big monad word, but it may, you know, I don't know, I mean, I don't know. I mean, I have, Python is actually already doing this. Like this, like if you've used things like the, like futures, like concurrent futures and you get these like future objects and other things that that is sort of a style, that's sort of in the rust style where you get an object that has a result and an exception packaged into it, into one thing. And you start passing that around. And it's like, I don't know, maybe, maybe it's probably the worst pun, pun that I could say on that right now. But yeah, maybe. Maybe, yeah, there's a choice, right? Yeah. Excellent. So thank you very much again, excellent talk. Everyone is very excited. They probably have more questions. So I'd like to ask you to go to the breakout room, Optiver. Okay. And Matrix. And then, you know, maybe you can, you can have a discussion with folks by chat or you can join the JITZI. There's a JITZI, which is in there. JITZI is an audio video system that you can, where you can conference and then, you know, answer more questions. So thank you very much for, you know, getting up earlier for giving this talk, it was an excellent talk, yet another one in the longest series of great talks that you've given. And thank you very much for coming to your Python. Okay. So thank you and I had fun doing that. Thanks. Bye-bye. Okay.