Guido van Rossum Q&A
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 130 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/49941 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | |
| Genre |
EuroPython 202062 / 130
2
4
7
8
13
16
21
23
25
26
27
30
33
36
39
46
50
53
54
56
60
61
62
65
68
73
82
85
86
95
100
101
102
106
108
109
113
118
119
120
125
00:00
Area1 (number)Software developerLine (geometry)QuicksortMultiplication signProjective planeWeb browserServer (computing)Parameter (computer programming)NumberWebsitePosition operatorTask (computing)Process (computing)Electronic program guideMessage passingVideo gameFluid staticsCodeFormal languageElectronic mailing listPhysical systemThread (computing)Group actionConcurrency (computer science)Entire functionPauli exclusion principleOrder (biology)Interpreter (computing)Type theoryRevision controlCharacteristic polynomialDifferent (Kate Ryan album)MathematicsFamilyPiOffice suiteDecision theoryCore dumpArithmetic progressionThermal expansionLibrary (computing)Computing platformProgrammschleifeGoodness of fitCartesian coordinate systemRight anglePlanningSpeech synthesisCycle (graph theory)Point (geometry)Independence (probability theory)Semantics (computer science)Level (video gaming)Combinational logicOcean currentDynamical systemConstraint (mathematics)CASE <Informatik>Dimensional analysisoutputPattern languagePrimitive (album)Assembly languageForm (programming)Array data structureOperator (mathematics)ReliefMereologyInformation securityFlash memoryPlug-in (computing)Java appletBitEndliche ModelltheorieVector spaceMatching (graph theory)ParsingReading (process)Web pageSheaf (mathematics)Musical ensembleScripting languageAdditionStatement (computer science)Software bugMechanism designAuthorizationVirtual machineComputer programmingHypothesisStrategy gamePattern matchingWeb-DesignerMultiplicationWordStandard deviationOpen sourceObject (grammar)Classical physicsIntegerCompilerHand fanPlastikkarteControl flowSound effectExpressionProgramming languagePhase transitionWeb 2.0Arithmetic meanGraph coloringNetwork topologyFrame problemExtension (kinesiology)Function (mathematics)Computer configurationExpected valueDefault (computer science)BlogContext awarenessGame theoryCausalitySoftware engineeringModule (mathematics)DampingVotingFunctional (mathematics)Wrapper (data mining)Bounded variationVapor barrierFeedbackCrash (computing)SoftwareCapability Maturity ModelSpacetimeEinbettung <Mathematik>TwitterNP-hardFront and back endsFitness functionXMLUMLMeeting/Interview
Transcript: Englisch(auto-generated)
00:06
I did some groups, so I think the first ones are more in the personal area. Chuke is asking, so now you're retired, so congratulations, by the way, and she's asking me, what are you planning to do?
00:21
Are you planning to do some cool things with Python, or are you trying to look for more space in other things in your life? Well, actually both. I am very much enjoying retirement as an opportunity to spend more time outside,
00:41
hiking and biking a lot with my wife. We live in a beautiful area. Within half an hour or an hour's drive are all sorts of beautiful places that I love to visit. If you find me on Instagram, you can see where I went lately.
01:01
But at other times, I also like to keep my mind sharp by working on new ideas for Python. You have already seen probably the new parser that I introduced with, okay, I didn't prepare this.
01:25
Anyway, the new parser was introduced in Python 3.9. Currently, I'm working with a few other people again on a match statement,
01:42
which is proving somewhat controversial, but I think it will in the end turn out to be a very useful addition to Python. Okay, nice. Looking forward to see that. So, next question is, okay, what other programming language do you like to use?
02:06
That's tough because I really don't like any other languages anymore. The only other language in the past few years, I think the only other language that I've used is pretty much C.
02:23
And that's only because I'm working on Python internals occasionally, like with a parser, there was a lot of C code for the match statement is actually there. There's also a lot of C code, but someone else is maintaining that problem.
02:41
Yeah, when I still worked at Dropbox, occasionally, I saw a little bit of Go or Rust or JavaScript. Not a fan of JavaScript. Probably just because I don't understand the ecosystem anymore. I haven't really kept up with what's going on in JavaScript
03:01
and people are now writing incredibly complicated things using React and stuff like that. And I have no understanding of how that works or what you can do with it. Rust seems an interesting language, but I've never ever compiled even Hello World in Rust. I don't think I've ever downloaded the Rust compiler anywhere.
03:24
Well, yeah, pretty much the same for Go. Okay, nice. Yeah, so you created your language, so it makes sense that you want to work in a different one. Yeah, I can fly in Python and in all the other languages.
03:40
I can fly in Python and C, and in everything else, I have to learn to crawl still. I will merge those two questions. One person is asking, what was your inspiration to create Python? And then the next question, maybe we can put those together,
04:00
is if you have the opportunity to start Python from scratch now, or maybe to get all the knowledge that you have now when you were starting, why do you think it will be different? So the question is, will it be more close to JavaScript? And it's also asking if you would keep the gill.
04:22
Everyone is naming the gill, I don't know why. Wow, those are a bunch of very leading questions. I think I'm going to separate it all out. The inspiration for Python was, well, I've written about it a couple of times, I guess.
04:40
I actually enjoyed working on a language I had sort of helped implement a few years earlier, in the early 80s. And I was writing a lot of C code at the time in, say, 88, 89, 90.
05:02
And I felt that I was being unproductive in the type of applications I was writing. So I was looking around for other options. And we had a platform that would make it difficult to, say, do a port of Perl, although in the end, if I had spent all the time I spent creating Python,
05:24
if I had spent that on a good Perl port with that platform, Python would never have occurred. So I would still be living in Amsterdam coding for money.
05:41
Sorry, I'm losing my voice, I realize. It's okay, take your time. Yeah, if I had to start over in 2020, that is one of those crazy hypotheticals that I don't know what to do with.
06:01
Because if there was no Python in 2020, there was certainly something else. And so, I don't know, I can't translate the mindset that made me create Python in 1990 to 30 years later and come up with a sensible answer.
06:24
If you're saying, would it be more like JavaScript? I hope not. I don't know. It's like, what if I was born rich instead of poor?
06:41
Yeah, that's unanswerable. And there was some mention of, I think, the GIL and one other specific thing. It was only the GIL, so if you will maintain that. So I will rephrase that question. Let's say you have 128 bytes in a message to send to yourself in 1991.
07:03
What would be your advice for starting Python at that time? It's a small message, I know. I think I will refuse to send that message because I feel that anything I could say
07:22
through the butterfly effect would change the world so much, even 128 bytes, that I would be very worried for a completely different outcome. I can't imagine what I would have to say to make the outcome better.
07:42
If I received the message from myself 30 years in the future saying, what you're doing is great and it's going to be the most popular language in the world, or something like that, I don't think I would have been able to handle that. Plus, of course, again, it's a nonsensical question.
08:05
So, I don't know, just ask something else. Next question, please. Okay, so a lot of people was asking the same. So, I will tell you three or maybe put them together.
08:21
Basically, the question is if you imagine Python running in the web, so as JavaScript is running now in the browsers. So, Carl was asking if, for example, is the support to Brighton, is something that is in the plans of Python, or if you think that Python can be a front-end web development language?
08:47
There was a lot of questions. That has passed my mind a few times in the last three decades. But every time I considered it, JavaScript was a different language.
09:04
I think the first time I thought about this, and people actually built this, believe it or not, in 1995, there was a plug-in that worked in both existing web browsers at the time.
09:20
Some early version of Microsoft Explorer, as well as Netscape, I believe. There was a plug-in that you could use to run Python in the browser. Nobody even remembers that, because it turns out plug-ins were a dead end
09:42
in the world of browsers. And this was actually, I think that the plug-in here was similar to running Java in the browser rather than running JavaScript in the browser. But nevertheless, you could send a whole program to the browser.
10:01
The problem was that end users would have to install the plug-ins because there was no automatic or easy mechanism to install plug-ins. Plus, it was, of course, entirely insecure. So, smart end users probably wouldn't want to install that plug-in.
10:20
And then, a website developer, of course, would think twice before they decided to use that plug-in for their website because nobody could look at their website without installing the plug-in. More recently, you may remember something called Flash, which was also a plug-in you had to install.
10:44
For decades, websites that were built on Flash would sort of be, sort of, there would always be places where they wouldn't run and there would be big buttons that say, install Flash,
11:01
and yet, half the world would not be able to install Flash until the browsers just came with Flash pre-installed and then became a huge security vector. So, the whole plug-in model, I'm glad, is sort of gone from the world.
11:22
The last time I saw a website that said your Flash is out of date or you're not running Flash was five years ago, I believe. Yeah, so then we got to the time when JavaScript embedded in HTML
11:40
to make sort of things like active buttons and a few other things became popular. And so, you would have mostly HTML and there would be like a script section in there or there would be little snippets of JavaScript sprinkled through the page and you would have some kind of dynamic activity in the browser.
12:06
And I looked at that and I thought, well, could Python do the same? It probably could be made to do the same. There was a problem in that particular model that embedded Python code,
12:20
like a small snippet of Python, as long as it's more than a single expression, if it can be a statement, you're getting in trouble with the indentation. I wouldn't be surprised if people had actually implemented systems like that because, as far as I recall,
12:42
web standards actually supported other languages than JavaScript to be specified that, of course, there were no browsers that sort of fully supported anything besides JavaScript. The latest incarnation is actually the most likely one to eventually yield some kind of success,
13:03
which is the browser has an execution engine. We can translate any language we want to code that runs on that execution engine. The original version of that was just transpile anything you want to JavaScript.
13:26
It doesn't matter how ugly the JavaScript looks because you're never going to have to look at it. And now you can do everything on the server side and so you don't have the problem that users have to install anything new in their browser.
13:44
That could be done, I believe, that some of... I actually have no idea how Brighton works, but I imagine there are some things like Brighton that work that way. A more recent refinement of the same idea is WebAssembly, W-A-S-M,
14:05
which I don't know that much about, but it sounds, again, like something where we could relatively easily, and probably someone already has done it as a master's project or maybe a summer of code at Mozilla.
14:20
Who knows? Just compile Python to WebAssembly and run that in the browser. You can probably, if you want to be crazy, you can transpile C code into WebAssembly and just take all of C Python and run that in the browser.
14:40
I don't know how well that would run because it would be a very large upload or download the first time you want to run it. On the other hand, it has some advantages of being more faithful to exact Python semantics. All these sound interesting approaches,
15:04
and it's possible that at some point something like Brighton or another similar approach will be successful. I think it's too soon to tell. I don't know that it's necessarily the core Python team's task
15:23
to look into this. This is something that anyone with good knowledge of the target platform, namely a browser running WebAssembly or a browser running a modern JavaScript engine
15:41
can figure out how to do. Okay, nice. Thank you. Yeah, well, summer looks super interesting. Okay, let me move to the next question. We have a lot of live. I need to wait a few minutes for that.
16:01
Ram is asking if you can share your feelings about the PEP 622, the pattern matching PEP. Sharing feelings? Oh, I'm not all that great at sharing feelings. My current feelings around that PEP
16:22
are in part a sense of relief that most of the hard work of designing and even implementing pattern matching and sort of looking at all the possible ways
16:41
that it can be implemented and looking at all the use cases and sort of looking at how it is best told and how to solve all the various constraints of making it sort of Pythonic and making it sort of powerful enough and making it useful. We've sort of done all the work and that's behind us.
17:06
More recently, I was really upset by a lot of feedback that came from the core dev community about that PEP. It was not fun to sort of see threads with a subject,
17:26
the anti-PEP. Should we perhaps have a way to write a PEP that explains why a certain other PEP should not be accepted? And it was very clear what this was about. And other people that are very smart
17:43
and whom I respect tremendously sort of putting all their effort into sort of tackling this new proposal and explaining why it is un-Pythonic and a bad idea and should not be done with them.
18:03
And all in, as far as I can tell, very sort of subjective emotional ways where it's hard to reason when one person's position is,
18:20
this is easy to teach. And another person's position is everybody's going to be confused by this because we just don't have data to decide an argument like that. And so what you get is that sort of the person who shouts the loudest gets the biggest audience.
18:45
I don't know. I feel I still have a pretty decent intuition about what kind of language features fit well into Python
19:05
and are generally useful and how to use them and how to design them. And so I sometimes just feel personally attacked when people who I see as clearly less experienced
19:22
in language design and sometimes like utterly failing in language design come up with counter proposals that are so poorly thought out that I don't even know how to respond to it except by saying this can never work.
19:41
And so the PEP is currently in the stage where I sent it off to the steering council and the steering council has been very busy because they've been distracted by some other topics. But hopefully in the next few weeks, they will have some time to think about this
20:00
and how they want to review it possibly. I mean, for me, the best possible outcome would be for the steering council to pick some developer who is somewhat friendly to this proposal to sort of review the PEP and decide where it needs more work
20:22
and whether certain design decisions that are not set in stone can need to be changed. But it's possible that the steering council decides that this is just too big of a change and they don't want to get burned by approving it.
20:44
Okay. There was two different persons asking almost the same, so I will pick one. So the question says, we've grown language support for even loops
21:01
in the past decade. Like it was really good progress, still in progress. And the question is, where do you feel the Python language stands in regards to concurrency primitives? And what area do you see the language moving? More towards Go with the sub-interpreters or more towards the async await place?
21:25
And there was two different persons asking almost the same, like sub-interpreters versus async. To be honest, I don't think that sub-interpreters solve the problem with concurrency
21:44
because they only solve it by placing a complete barrier between each sub-interpreter. So there is not much gain to be made
22:03
compared to just forking multiple processes. And in a sense, sub-interpreters are less robust because if one sub-interpreter experiences a hard crash,
22:21
the entire group of sub-interpreters running in the same process will necessarily have to be terminated. Well, if you have a number of processes that they're all working on a problem in parallel, if one of the processes fails,
22:40
the other processes, if you've designed things right, can continue and you can just restart the process. So I don't know that sub-processes are really solving the right problem. They are definitely solving some problems, but the problems are not so much in concurrency, I feel. They are more about larger applications,
23:03
embedding Python, and sort of being able to have independent Python interpreters for sort of different parts of the embedded application. Or maybe there are different libraries that are combined together
23:20
that each have a completely different independent use of Python. But for concurrency, yeah, I'm also not optimistic about getting rid of the gill, at least in the sort of every solution that's been tried
23:41
and people have been trying for two decades at least. Every solution has sort of slowed down the single-threaded performance dramatically because you end up having many finer-grained locks. It is possible that a complete redesign
24:03
of the Python interpreter really from the ground up made for concurrency could sort of have different performance characteristics. But that would be an enormous task that I think only private capital could fund that,
24:23
and it's very unclear that much would come out of that. Okay, okay. So, I'm going to ask the last one from my list because we already had 24 from the public, I think. Yeah, no, I'm not going to ask all of them.
24:43
So, the last question from my list is, Sean Marco from Brazil, he's asking if there is a plan or if there is a program to engage, to introduce more people to the core developers team. So, he was saying we love Python, but Python doesn't fall from the trees.
25:01
We need more people to work there. So, what's the plan and what's the program for that? The steering council is very aware that we're not attracting new core developers in sufficient numbers.
25:20
So, I can't speak for the steering council because I'm no longer a member. But I know that when I was on the steering council last year that this was also an important topic that we were thinking about. It's not an easy problem
25:42
because it's one thing to get people to easily contribute a simple fix for a simple problem. That's hard enough. If you fix a one line bug in some C code
26:01
that's part of C Python, you have to go through a whole number of steps just in order to be able to compile and test your changes. We have developer guide that talks people through that in great detail.
26:24
It's still not always easy to follow because of course people come into this with such different backgrounds. Some people are very experienced in open source development, just not in the particular workflow that Python uses. Other people are experienced C coders,
26:41
but they have no idea of how Git works. We see a fair number of bungled pull requests from beginners who make some classic Git mistake and they do an incorrect merge
27:00
and now they have 500 commits in their pull request that shouldn't be there because they didn't write those commits. And this usually causes 30 different core developers to be auto registered as reviewer.
27:21
So anyway, the workflow is difficult, but the other part of the problem, I mean, the workflow can be learned. We can also simplify the workflow to some extent. I don't think we can really stop people from making basic Git mistakes because there are enough Git tutorials
27:42
that explain how to do it and people just don't follow the tutorial because Git is so random. But sort of attracting people who are able to sort of take in this large amount of C code and Python code, of course,
28:05
that is C Python and the standard library. It's just difficult because you can feel very productive by fixing some issues in one module, but that doesn't teach you much about how some other module works
28:21
and there is a huge amount of history and a very great concern for backwards compatibility and you have to sort of be aware of the philosophy of sort of what kind of things make sense to add and what things don't. Like this morning on Python Ideas,
28:41
there was a little discussion about a new variation of the wrapper function that would take an extra parameter that basically tells it how much work to do, I guess, how large an output to produce and there was immediately debate
29:01
about whether that was better to, it was better to do that as a third party library or whether that was really something that ought to be built into the language and there were immediately strong opinions on both sides of the argument. So it's just, it's a difficult project
29:22
and part of that is just because it's a very large mature piece of software that has to move carefully and slowly and you have to attract people who sort of are interested in working on that.
29:42
That said, I mean, we have successfully attracted new developers, some with sort of very specific skills. We've also attracted new core developers who don't necessarily want to help out with the C code but are useful in other areas like documentation
30:03
or workflow or issue triage. So we are trying to get more people involved for sure and if you don't always see where to start,
30:21
maybe part of that is that we're looking for people with a certain level of experience. So that means we can't teach people how to code in C, for example. So if you can totally be a core dev and not ever touch any C code but you still have to sort of know a lot of other stuff
30:46
and you'll eventually have to work your way around the C code. Okay, thank you, nice. So let's move to live questions. First one is easy.
31:01
People is asking if you have ever made the Monty Python crew? Sorry, what was the last word? So if you ever made the Monty Python crew, so the Monty Python crew. Unfortunately not. I'm a big fan of John Cleese but I've not come closer than following him on Twitter.
31:30
What do you hate most, the most? About Python. What do I hate most about Python? Yes.
31:45
Nothing comes to mind, sorry. I don't know if I want to ask this question but it has a lot of votes. What would you like to introduce to Python 4 and when do you see the switch happening?
32:06
Well, I think that the general question is people are fearful about Python 4 because they remember the Python 3 transition and how we were not prepared and all that.
32:28
I see two things in the future for sure. One is that Python 4 is a long time in the future if it ever happens
32:41
because we're happily planning 3.10 and we can go all the way to 3.99 before we, well, then we can just go to 3.100. So there's no reason to switch to Python 4 and I know there are a few peps that still mention Python 4 as a possible timeframe
33:04
where certain things will change or become the default. That basically means never. If and when there is a Python 4 whether that is in five or 50 years,
33:21
my expectation is that we'll sort of spend an enormous amount of time working on transition strategies that are actually practical for real users in the Python community.
33:41
With Python 3, we sort of, we definitely thought about transition strategies but we misinterpreted how many Python users there were and what their skill levels were basically. We thought that everybody thought was sort of as interested in making their Python code better
34:03
as the core developers typically are. So I don't wanna have that sort of, that you can look up my talk about that topic at PyCascades a few years ago. Victor Stinner also gave a nice talk about this topic. So if Python 4 ever happens,
34:22
if there is a reason to sort of somehow break backwards compatibility, there will be a very different approach to sort of how to maintain compatibility. And it's possible that in the end
34:43
we'll actually declare something Python 4 for a very minor backwards incompatibility. I mean, it could be that like removing the guild changes semantics of multiple threads enough that even without any other explicit API changes,
35:02
if all the API and everything, all the objects did exactly the same, worked exactly the same as they do in Python 3. If the only difference was that the guild was removed, we might still have to declare it Python 4 because in practice,
35:22
the guild sort of causes certain performance guarantees even though you may not always like them, but actually in some cases you will like them. And it will just be sort of tricky for people to upgrade.
35:42
And so, I mean, that's just a random hypothesis. It could be something completely different too. It could be that we're using a different approach for the C API. I mean, there are a couple of new approaches there. There is a basic API that is smaller
36:00
than the traditional C API. There's also a handle based API under development. So maybe at some point we'll declare something Python 4, not because the language has changed but because the C API has changed. And of course the C API sort of is what keeps the ecosystem together.
36:22
So that's again, not a thing to say, ah, yeah, one or two extension writers have to change their code a little bit but everyone else is safe. No, it would mean that like the entire scientific Python,
36:40
the entire data science machine learning world would have to produce new wheels at the very least and probably update their code significantly. So that's like not something we can do in five years. That takes a decade.
37:03
So basically I'd say Python 4 is not happening anytime soon. It's not something to worry about and it's going to feel very different than the Python 3 transition. Okay, thank you.
37:22
Next one. So people are asking what's your favorite book or maybe you can pick one. I don't know if you have only one favorite book.
37:42
I have lots of books that I read and I sort of, after I read a book, I forget it again until I see it again maybe. One book that I've really, really enjoyed reading when it came out, I think well over a decade
38:01
was Anathem by Neal Stephenson. Okay. Neal Stephenson in general is one of my favorite authors and has been for a long time. I think I've read almost everything that he's written and Anathem for me was the most fun to read.
38:26
I think of everything he's written. Okay, thank you for recommending it. I'm going to pick this one. It doesn't have a lot of goal, just because I'm selecting the questions. There is a piano in your teacher
38:41
or it's a piano pattern and it's maybe that you are learning how to play the piano or it's something that you are trying to do. I'm sorry, I'm not following. So the question is, you have a piano pattern in your teacher and the question if that is a clue
39:00
of a new hobby that you have that you're maybe trying to learn. Oh, my T-shirt. Yeah. No. The T-shirt is actually a secret message. This T-shirt was printed by Dropbox a few years ago
39:21
on the occasion of Black History World. And I believe that the story was to get the T-shirt, you would have to donate $10 to a designated charity. So I donated a bunch of stuff and I got a T-shirt and it said, I'll stand up so you can see the whole thing.
39:42
It really has very little to do with piano. It's just about sort of different colors. And diversity. Cool. I'm colorblind, so probably I'm not going to guess the secret. There's not more than that to it.
40:02
Thank you. Okay, we have a few minutes, not a lot. Do you think that my pipe will become part of the standard library? Yeah, people sort of I have been very hopeful about my pi.
40:25
I don't think it's a good idea, actually. My pi is a piece of code that like any other linter, it has a very different development cycle
40:42
and sort of fixing, sort of tying my pies development to the step that of the standard library would sort of slow down my pi development tremendously. So I would really much rather keep it separate.
41:01
Because otherwise you would basically not be able to get new my pi features with old Python versions. It's possible that what people really meant by my pi is some form of static type checking built into the interpreter.
41:23
Again, I think that's not likely going to happen because the language as sort of allowed by the type system specified by PEP 484 and the follow on PEPs
41:42
is actually less powerful than the full dynamic language. And Python is a dynamic language and I think it should always stay a dynamic language. And sort of static checking definitely is an important tool that everybody who is writing
42:02
more than a thousand lines of Python should probably be familiar with and have in their toolkit. But at the same time, it's one of those tools where you sort of you have to be able to turn it off
42:21
or use a different tool or sort of... It's use needs to remain truly optional and if you have a corner of your application where static type checking makes no sense or just slows you down, or maybe what you're doing
42:42
could be statically typed but it would require a significant expansion of the static type checking, the type system that mypy and other checkers support that alone would be good reason to sort of be careful here.
43:01
There is a pending PEP 612 and there are probably going to be some follow up PEPs as well that try to deal with, for example, type checking applications that use NumPy arrays
43:21
where you have operations that sort of require two inputs to have the same size or to have the same size in a certain dimension or to have the same dimensions. There are all sorts of combinations and the current type system cannot express that at all. So it's essentially way too early,
43:41
way too soon to even try fitting everything in there. So I think the dynamic side of the language needs to sort of stay ahead of the statically typed subset. Okay. So we are on time now.
44:00
So I'm going to ask you the last question and I was saving this one for the end. So Kanak Cavadi and I probably mispronounced that name. So this person is saying, Guido, you are such an inspiration to me and all of us, I'm sure. And what's your message or advice on both life and career
44:21
for a young developer or a young software engineer like me, you see, Kanak. And I knew that one would be coming and I don't have a path answer to sort of that question. It's like my approach was,
44:44
and you should probably, if you haven't ever read that blog post by me, I wrote something called a King's Day speech, just Google for my name with King's Day speech and Google will certainly find that blog post for you.
45:01
That's the most inspirational story I've ever written, I believe. My approach and I was incredibly lucky that it worked out so well was, make sure you have fun. Do sort of join the project
45:21
that looks the most interesting and most fun to do and sort of prize that over what is perhaps the most lucrative or I don't know, there are many different ways that you can evaluate jobs.
45:43
If I didn't want to do something, I would not do it. If I wanted to do something that other people didn't think I should do, I might still do it. After all, that's how Python came into being.
46:02
At the same time, I've been looking back at my life and I would say I definitely worked too hard. 30 years of being Python's BDFL have not been great for my family. I've sort of spent every day in the office
46:22
and then every night I would be spending and many hours every weekend or most weekends I would be spending still keeping sort of thinking about Python stuff
46:40
and sort of that level of taking your work home with you I don't think is good. So have fun, but make sure to sort of let yourself be distracted by other aspects of life besides work.
47:02
And yeah, so we are on time. So that was all. I'm going to play some sound so you feel like...