Sebastián Ramírez is the developer behind FastAPI for Python REST APIs and Typer, for CLI applications. We discuss FastAPI, Typer, Swagger UI, interface design, autocompletion, and more.
Transcript for episode 120 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:00 Fast API is a modern, Fast high performance web framework for building APIs with Python based on standard Python type. Ins Typer is a library for building command line interface applications also based on Python type. Ins type, in and many other details are intended to make it easier to develop, test and debug applications using Fast API and typer. The person behind both Fast API and Typer is Sebastian Ramirez. Sebastian is on the show today and we discuss both Fast API and Typer and uses for both. This episode of Test and Code is brought to you by PyCharm. Save time, use PyCharm and by listeners like you who support the show through Patreon.
00:00:53 Welcome to Testing Code, because software engineering should include more testing.
00:01:00 Welcome to Test and Code. I’m really excited to have you here. You’re Sebastian Ramirez, and can you tell us a little bit about you?
00:01:08 Yeah, sure.
00:01:10 So first, thank you very much for having me here on the show. So, yeah, I’m Sebastian Ramirez, and I’m actually from Colombia, South America. That’s why the accent.
00:01:20 But I’m now living in Berlin, Germany. I’m working for Explosion, the company behind Spacey, the natural language processing toolkit.
00:01:31 They are the creators of Spacey and Prodigy, the Annotation, the annotation package for machine learning using active learning and Think, the deep learning library using type notations with a functional style. So I’m working here in Berlin, and I’m with the creator of Fast API, which is this new sort of newish, I guess, API framework and Typer, which is a common line interface framework of library, I guess you could say. Yeah, that’s me.
00:02:05 You’ve been working at Fast API for a while, right? When did this start?
00:02:09 Yeah, started in one year and some months ago when you consider all the other frameworks that are there. This is quite young, I would say. Yes, but yeah, it started when I was working at a company in Dubai.
00:02:34 It was actually like a combination of ideas of all these new previous frameworks and tools that have great ideas and great ways to work.
00:02:46 But then I was just like, trying to combine new tools and new possibilities to achieve the same things that I was trying to achieve, combining like a bunch of pieces together that is not necessarily easy to combine a bunch of plugins and to make them work. And I was just trying to make it all work by default, using standard Python type annotations so that you can just write standard Python code and get all the benefits of type. Annotations. Like type checks out the completion and all this stuff, and then get with that get for free data validation, data serialization documentation and all that, just like by annotating your data. So that when you add the functions and then when the function executes, you know that the data is already validated and you can just dedicate yourself to the business logic of your application without having to do all the custom logic for checking. Is this payload actually correct or not? And all the stuff. So that was the idea that I was trying to achieve for Fast API.
00:04:02 The API in there is a Rest API, so it’s an end point or set of endpoints, right?
00:04:10 Yeah, exactly. So the thing is that recently most of these frameworks have had the main idea of generating HTML in the back end and using templates and these kind of things. And they have invested a lot of work in these templates engines and all these things. But then many modern applications actually show the front end using a JavaScript library, like a modern front end using something like React or VGS or Angular or even like maybe the application is actually not like the front end or the user interface is actually not even a web thing with a mobile application. And the mobile application has to communicate with some back end servers. So with all this change or all this shift in development, these new applications end up communicating with the back end like a separate company and having just like these independent logic and independent responsibilities. So the idea with the API is just to be able to easily build mainly JSON web APIs, but actually you can implement it and do it with XML, I guess if you want to, or like YAML or whatever of these systems that you want to implement. Of course the default is just JSON because that’s like what most systems use.
00:05:49 The idea is just to be able to do that and to do it all in a standard way using open standards like Open API, JSON, Schema, and two for security.
00:05:59 And the fast part of it is high performance, right?
00:06:04 Yeah, actually it’s double like. Yeah, it’s high performance. So Fast API is actually based on Starlet, and Starlet is built by Tom Christie, the same creator of Jungle Rest framework.
00:06:18 And Starlet is currently like one of the fastest Python frameworks as measured by independent benchmarks. And then Fast API is actually just startled on steroids and it just adds a bunch of stuff. And then it combines it with another library called Python Tick that does data validation, visualization and documentation based on standard Python type things. So then fantastic. I just combines these two things and both of them are like they’re in the top ranking for performance.
00:06:50 Okay.
00:06:51 So that’s on the side of performance, it’s one of the fastest frameworks available for Python. And on the other side, writing code in Fast API is quite fast. Like having a product ready is quite fast. Like the amount of code that you have to write for the API itself is actually very little. Most of the code that you end up writing is the business logic of your application. Like the API code is actually really small because it just gets out of the way and does the right thing for you.
00:07:25 The fast part is because it’s like high performance, but on the other side, it’s very quick to have something already working when developing with test API.
00:07:37 Thank you Pie Chart for sponsoring this episode. I love running my tests right from PyCharm. There are many ways to run the tests, and I use lots of them, and every one of those also has an option to run the tests with the debugger or with the profiler or with coverage. Run with coverage. And now there are percentage of lines covered listed in the project tree right next to the file names. Select a file with low coverage, for instance, and visually you see exactly which lines are covered and which ones are not by colors in the gutter alongside the code coverage and PyCharm, two tools I use all the time work great together. Awesome. Running with the profiler or with code coverage are part of PyCharm Pro and is one of the reasons why I use PyCharm Pro. Not the only reason to grab Pro, but it is super cool. Try it yourself by visiting Testingcode PyCharm there. You can try PyCharm free for four months and see for yourself if coverage in your editor saves you time. I think it will if you go to the Fast API documentation, the key feature bullet points. There’s only one that says like fast for performance, and there’s a whole bunch of focus on fast to code, reduce the number of human errors that happen by minimizing the syntax that people have to use, making it easy. And just like there’s not a lot of work to do to implement an API, the other end is you’ve also put a lot of thought into making sure that you can debug it easily.
00:09:13 So this whole comfort level for the developer experience is very refreshing, and I’m not surprised that it’s getting a lot of attention and getting a lot of use because of all of that and that it’s super fast.
00:09:32 I think it would have been popular in any way, even if it was just the same speed as everything else.
00:09:38 Yeah, thank you. I’m glad you liked the doors. I like the thing, but yeah, of the API, of the library and the way you interact with it, the design of it that was like a lot of work put just into the design of how it should look like and how it should feel like while developing with it. Because one of the main ideas I wanted was to have autocompletion everywhere. So whenever you are coding with US API, you get auto completion for your own data and you get a completion for the function parameters that you might pass to any of the functions that you use.
00:10:20 There is nowhere that you have to use one of these kw arcs that the function takes like some arbitrary number of keyword arguments, and then you just have to go to documentation to find out what is it that will go there. Like actually everything is declared and everything has types and everything. So you can just use auto completion for everything.
00:10:43 The idea is that you should be able to give a quick pass to the documentation and then just like never come back. Just use autocompletion in your editor to know what is the thing that you have to pass in there for it to work.
00:10:55 Oh, that’s great. I didn’t notice that. That’s an interesting touch. And then also you’re building off other people as well, like Swagger’s one. Is Swagger part of it or incorporate it with it easily?
00:11:07 Yeah. So the thing is that Fast API, even the design of the code itself is built around the Open standard Open API, which was previously known as Swagger. Like it was Swagger one, then Swagger 2.0, and then the next version was called OpenAPI 3.0. But it’s the same old thing.
00:11:30 And then after it became Open API, it was transferred to the organization handling is the Linux Foundation or something like that. But still it’s a lot of the core development of that is done by the same guys that created Swagger. But then there is the user interface that can read that. So this Open API is just like a big JSON or YAML file that describes how an API would look like and describes all the possible endpoints or however you want to call them, and with all the possible parameters and all the boys and like the payloads and everything with all the data shapes and the data types of each one of those things. Then Fat API is built around that and it generates like the API that you create is automatically follows that specification, that standard. And then you get for free, like the generation of the schema for that Open API standard.
00:12:35 So you get a whole huge schema describing your whole API, and then the same thing is consumed by Swagger UI, which is like the user interface that lets you explore interactively the documentation of your own API, and you can actually execute requests to your own API using Swagger. Ai is just like a JavaScript library that reads this JSON Open API schema and then it can interact with that API. But Fast API bundles everything together. So you can just create your API and then go to your API docs and then you get an interactive API documentation for free.
00:13:23 So one of the things, since I’m not normally working on with Rest APIs and stuff it’s on my day to day thing, I’m curious, where is this used?
00:13:36 When do people use the Swagger UI? Is it during like debugging or adding a feature or is it just during development? Or when is the normal time for people to use it? Do you know?
00:13:50 Yes. So the funny thing with this is that once you have an interactive API exploration or documentation thing to work with your API, you end up using it all the time during development to check that your API is actually working so you don’t have to wait for the front end UI team. Or maybe that’s even yourself to build something that communicates with that API to make sure that it works. Or maybe like try to make coral commands and make sure that you send the right payload and everything because you have examples already there in the automatic documentation. So the first benefit and the first user of this automatic user interface is like the same developer that is writing the API.
00:14:42 It’s like, I don’t know, like having a postman integrated into the API that already knows where all the possible endpoints and where are all the possible payloads and what is valid and whatnot just have it right there. Then the next kind of people that could benefit from it is other teams. For example, if you have a front end team that needs to communicate with the API without a system like this, the documentation of the API many times ends up in a Wiki that ends up getting obsolete quite quickly. Like after you have to add upgrades and migrate stuff and change stuff. And then they are struggling trying to communicate with the API that has also the documentation in the Wiki. When they can just use the documentation that is always up to date with the actual API, that helps a lot. And then the other one is when you are building an API for your actual final customers or clients to interact with and they can explore the API directly.
00:15:50 That also helps a lot. Also because when you create the API and when you get this user interface, it also has like documentation and you can integrate actual textual documentation and Mark the documentation that is read from the dog strings of your functions. And it’s all done there automatically. So you can document how to use your whole API and everything inside of the same code that handles it. So it’s a lot easier to keep it up to date. Because if you update a parameter and you mentioned that parameter in the dockstring of the same function that is receiving that parameter, it’s a lot easier to detect that you are changing something that is documented there. If you need to have some specific textual explanation of what is it doing.
00:16:44 But people leave these in place forever, right? You don’t take them out at some point.
00:16:52 Yeah. Okay. The documentation interface.
00:16:55 Yeah.
00:16:56 So one option is just to leave it forever. And I will say that’s the simplest also because some people consider it they will want to hide it for final users. I guess it’s also like part of the idea of thinking that it will expose something that should be private or something like that. But actually the security should not be done by obscurity, by hiding where the end points, but actually by making sure that the data that is transferred is secure.
00:17:30 And that’s also like the same API and the same thing can be integrated with.
00:17:35 And they’re like utilities to make it super easy. So you can get an application that works very similar to GitHub or Twitter or Facebook or any of these things that say login with application X. Or you can integrate one of those X applications very easily and then do the authentication, not by hiding what are the possible endpoints, but by doing the security stuff on the API side. So, yeah, the simplest thing to do is just like have the API there because it’s actually just like an extra feature for your API to have it actually documented. But at the same time, there are some people that want to hide it and want to make it only available for authenticated users or stuff like that, so they can use it with an authentication cookie or things like that. But yeah, it’s also possible to hide it when people want to do that.
00:18:33 Okay. Yeah, okay. That’s actually interesting.
00:18:37 I thought of the notion of hiding it, and some people didn’t want it to expose to users, but they’ll still need it for maintenance work or having it on a debug server or something like that. Right. So that’s cool.
00:18:53 Okay. Then before we move on to type, I wanted to ask, do you know how widely used Fast API is yet?
00:19:02 I know that’s a hard thing to measure.
00:19:04 But yeah, I know it’s a lot more used than I would have expected it to be. I know there’s like a huge use base.
00:19:17 Not only did you say in Europe, also like in China, in Japan, in India, there’s like a lot of users. I can see, for example, just seeing the Google Analytics for documentation. You can see there’s always like, I don’t know, 2040 people every second in the documentation. It’s just like a lot of people just using it. And I have seen people migrating a lot from a lot of frameworks to Fast API. And I know that it’s currently used by Microsoft or Windows APIs and Netflix for their monitoring thing for Dispatcher. Uber uses it for the Lutewick machine learning system. So it’s actually like a bunch of places that they are already using it. And yeah, I think that’s really cool. People are being able to adopt these new technologies a lot faster also, I guess because the benefits that these new ideas and these new technologies provide, like justify adding new tools and using them. So, yeah, I guess that’s driving a lot of the new users.
00:20:30 Are there new features coming into Fast API or is it mostly in a maintenance mode, making sure that it stays compatible with everything in the future?
00:20:40 What’s the development model of Fast API right now?
00:20:43 So there’s actually a bunch of stuff that is coming to Fast API, and also there’s stuff coming to Startled itself. Startled itself.
00:21:00 The whole team are building like a bunch of stuff into Starlet and improving stuff there that also is inherited by Fast API. And then Fast API, there’s a bunch of things that are also going to be added. And even though there’s a bunch of stuff that is going to be added and included, there’s also already like some backward compatibility layers to make sure that older, quote unquote applications made with Vs API don’t break.
00:21:33 Yeah, they’re old at most, right?
00:21:35 Exactly.
00:21:36 It’s a bit weird to have compatibility layers and stuff in something that the version is still like pre 1.0. And I don’t know why do we keep these versions pre 1.0? Well, the test coverage is at 100%, the whole code base is fully tight and updated, and it’s used in a lot of places. But yeah, I guess it’s just to have this flexibility to update some of the interfaces and some of the ways that it can be handled and used to make sure that it has the best possible development experience.
00:22:16 Okay. Yeah, you’re still at zero point 54 it looks like.
00:22:20 Yeah.
00:22:21 What’s up with that? Why not go to one?
00:22:25 I ask myself the same.
00:22:27 Actually, I wanted to make sure. I wanted to wait for Pythonic to be one point something, and Pidantic is already 1.5. Now I’m waiting for Startled to be one point something to make sure that is also stable.
00:22:44 But yeah, it’s just to make sure stuff is relatively stable before moving to a one point something.
00:22:54 But if developers pin their versions and make sure that they have the code tested, then it should be fairly easy to upgrade to a new version.
00:23:05 Okay, so even if there’s possible interactions, realistically it doesn’t bother me at all. But if Starlet changed the API for some reason they probably are not, because a lot of people are using Starlet. Also, how much of the interface between Starlet and the end user of Fast API?
00:23:34 So the thing is that Startled is like a very lean toolkit and framework.
00:23:46 In some cases it could be more a toolkit than a framework. It’s very lean, it doesn’t have hard requirements, and it has a very simple code base. It’s actually a beautiful code base and Fast API just like uses all that and adds all the stuff on top of it. Okay, but if Starlet is not very possible that it will change a lot of its own API to change the way it works, it actually has changed the way the default style to declare path. Sorry, to declare endpoints and stuff and that I call them infested. I call them path operations because it’s a specific path with a specific Http operation or Http method. So just to keep it in line with the Open API specification.
00:24:40 So in fact API everything is done through decorators. So you can do like at App, get and then put the past there in it. The default is to use classes and declare the classes inside of lists and stuff like that like more similar to how it works in Django, then Fast API will be more similar to how it works in Flask, I guess.
00:25:07 But actually, that doesn’t really affect how Fast API and Starbucks interact with each other because it’s actually using the core stuff underneath for everything to work. On the other side, Tom Christie is like he’s an awesome guy and he knows that Fast API is using it heavily and that the interaction is very strong with Fast API and start it.
00:25:37 I don’t know. In some of the API changes he has asked me, hey, will this affect or not?
00:25:43 How do we make sure that everything keeps working?
00:25:46 Yeah. Tom is a really cool guy.
00:25:48 I should have him on the show. I haven’t had him on yet. But one of the other things I wanted to ask is if somebody already has an existing application that doesn’t that they want to add an API.
00:26:00 There is an API, too. Does Fast API work with other stuff?
00:26:06 Can I hook like a Django app to FastAPI or is that just don’t do that. No.
00:26:12 Yeah. Actually, recently someone was having a previous Jungle application and integrating that with a Fast API application and like, using the same Django Orm with the Fast API, which is kind of a weird trick for a new project. It will probably make that much sense. But if you have like an already existing project, like, Fast API is made to be super modular and super independent of any of them or any database or any of these, like, additional layers or components. So it’s very easy to just integrate it with other parts or even to add it as a layer on top of the existing API just to add new features through Fast API in some of the specific endpoints, let’s say, and then keeping the rest in the already existing application.
00:27:08 Okay. I mean, there’s a lot of applications out there and people that hold data that they’re being requested.
00:27:16 We’re trying to get more and more open with data. Right.
00:27:19 So that people can expose an API instead of just publishing CSV files or something.
00:27:28 Yeah, exactly.
00:27:30 Yeah, absolutely.
00:27:32 It will probably be the simplest way to do it, I guess. But of course, I’m supervised.
00:27:39 Yeah. Okay. So then Typer comes along. Typer is even newer. Were you in Berlin by then when you started looking?
00:27:54 I went to frequent come out during Christmas again.
00:27:58 Like last Christmas, it was finishing up Fast API like the previous Christmas. This Christmas was finishing Typer. The idea with typer is to provide kind of the same development experience and the same design ideas to command line applications to command line interfaces. So using standard Python type annotations just to declare command line arguments and parameters, like an option like declaring flags and everything, just with standard Python type annotations, and to get automatic data validation from the common dime and automatic like type checks autocompletion in your code, but at the same time autocompletion in the final command line application so that when your users use the command line application built with Typer, they can also get auto completion in their own shell. For the commands that you are creating with Type, that’s like the idea to make it super easy to build and to have it to generate a very nice final command line application for the final users.
00:29:12 One of my shortlist things of to do is to try to convert. I’ve got a couple applications that use Click that I want to convert to Typer. Just because it’s less syntax, there’s less junk that I have to put on top. Click is easy already, but there is some stuff in the API of Click that when you have it in your code, you look at it and you go I don’t really know what this is doing, it’s just I have to have it to make it work.
00:29:42 Yeah.
00:29:43 Anyway, nothing against Click. I mean it’s better than everything else I’ve tried before, but again it’s so simple. You just stick these like decorators on top of a function and then you’ve got an API like a command line interface. It’s incredible.
00:30:03 Yeah. Actually as someone pointed out, it wouldn’t actually be migrating from Click. It will be just like adding a layer on top of because Typer is actually a lean layer on top of Click, just adding the type stuff, but it’s actually Click what powers everything underneath. The thing is that Click was designed and created for Python two point X and then we didn’t even have types. We didn’t even have like a lot of the new things that we have now. So it didn’t even have the possibility to use types for these things. But then with types the idea is for example and Click, when you want to add like a flag option, let’s say like I don’t know verbose or something like that, you have to declare that in a decorator and then you have to declare it again as a function parameter. And those two things are pretty far away in the code. Like they’re like maybe several lines away.
00:31:05 And the thing is that when you update one of those and when you update the name of those, you have to update the other one. And keeping that in sync without having something that makes them correlated like automatically in some way that can make it a little bit more difficult. That’s one of the main ideas in Type is that you declare one of these parameters, one of these names, you declare them only once and then everything is kept in sync together because you are just declaring it only once.
00:31:37 And then, I mean building on top of Click is smart because on the back end Click already had a test interface which was very nice to be able to test your application.
00:31:52 The testing part of Type or is that just using the same click testing interface or is it something else?
00:32:00 Yeah, it says like almost the same thing. It’s just that the click one expects a click application. The typer one expects a type of application because typer doesn’t really the way that click works is that when you decorate a function, it modifies the variable that you decorated to convert it to some specific type of object internal to click.
00:32:25 So then when you create a function, it ends up not being a function but being an instance of a command class, something like that. In typer, typer doesn’t really modify the function at all.
00:32:39 Then you get the typer application independent of that. And when you call it right, when you call the function, that’s when it generates a click application. That’s actually like a very technical detail. That’s how it works underneath. So the code is actually kind of the same. That will be for a click for testing a click application.
00:33:03 But it’s just that it takes care of making sure that you’re using a type of application and to convert all the things that need to be converted for it to work.
00:33:12 Yes, but again this focus on the comfort level of both the developer and the developer writing the tests. Hopefully it’s the same person, but it might be a different person.
00:33:25 This is really great and I love it. The auto completion part where you’re including these little stubs to be able to add auto completion to the applications that people write using typer.
00:33:39 This is interesting and why was this important to you?
00:33:44 I guess I don’t have very good memory. So I have been relying on auto completion for everything for the code I write and for the command line applications I write.
00:33:54 I don’t know when you use a command in the command line and maybe if you are using a new command knowing where are all the possible parameters, it’s like difficult like having to go to the documentation online and then going back to the command line and trying to check where the possible parameters were the possible subcommittee.
00:34:16 That’s not as comfortable as it could be when you can have auto completion in the command line itself.
00:34:24 I really enjoyed working with command line applications that have this as a completion feature for the shells that I was using. And I have been moving through all the shells Bash, Fish and now Seashell and actually Seashell them Fish and now back to Seashell. So I wanted to be able to these applications that are made with type that will work with any of these shelves and that take care of making it work for those shells without the developer having to deal with all the details of each specific shell. And actually they’re super different between each shell, between PowerShell and Windows, Bash, Seashell and Fish. All of them work very differently in the way they handle the completion. So having that by default was something that I was really wanted to achieve.
00:35:19 So your install completion bit will even deal with PowerShell?
00:35:25 Yes. So it will even deal with PowerShell, and there was a lot of struggle to make that actually work correctly.
00:35:32 That’s incredible.
00:35:34 The first versions were using a click completion that did a lot of the work there.
00:35:42 The recent versions of Taylor use some parts and some of the ideas of click completion, but actually don’t use click compilation itself because several parts are reimplemented to work with recent versions of PowerShell that are not supported like in any other library that I know of.
00:36:04 You said you use Z shell the most.
00:36:06 Yeah, I’m using Seashell the most.
00:36:08 Okay, so what happens if I write a little application and I run it with the install completion? What is it doing? Is it changing like a dot file or something?
00:36:20 Yeah. So for the case of Bash and Seashell, it’s generating another file inside of your environment in a specific place that will be read later and it’s modifying. In the case of Bash, it’s modifying the bashrc to read that file.
00:36:41 It’s not adding the completion part to the bashrc directly so that you can just remove that line if you want to uninstall the completion or remove the file that is generated. And for Seal, it’s the same for Fish, it’s generating a file in another place. For Phish functions that then Phish will read automatically and call it whenever you are triggering auto completion for that program. And for PowerShell is generating a file. It’s similar to bashrc, but for PowerShell it cannot read it from an external source because PowerShell doesn’t have a way to do that. But then it just adds the necessary configurations to have it in PowerShell. And actually in the latest version, it’s possible to have an application that is installed inside of a virtual environment, then install autocommflation, and then how to complete completion work when you are in the environment, even if the application is not installed outside of the environment. The trick here is that when you start a new session in your shell, all the auto completions are set up, but then if the command is not already available, then it cannot call that command to generate the completion.
00:38:05 But the latest version is made in a way that will delay that call to the command until the command is available, even if it’s inside of a virtual environment.
00:38:16 Okay, neat. Well, one of the things that I think is awesome about this is because I love it when tools provide completion and stuff, but I don’t know how to do it.
00:38:26 And a lot of command line tools are written not for a massive number of people. They’re written for a handful of people in a developer group or something, or it’s a tool for a company or something.
00:38:43 I can’t justify figuring out how to do completion for a little tool like that, except for if I just have to design it with typer and I get that for free. Then of course I’m going to have that included. And it’s pretty cool. I like it.
00:39:00 Yeah, exactly. And specifically for many of these use cases where it’s just like a small script, just like a small application that maybe doesn’t even justify building a whole Python package and installing it for it to work when you just, let’s say just have like a small task. Py script inside of the project. For these cases, I built a typer. Cli.
00:39:27 One thing is typer the library and this one is an independent package called typer. Cli that you can install and then it will read the file that you are providing it that has like us typer, and then it will provide you auto completion for that script directly in the command line without you even having to install anything in it. And because the way typer works, you can even create a standard file with just like a main function and declare some parameters with some types that you can say like this should be a path and this should be an integer and this should be like a string and then hold that with typer and typer will convert that into a command line application without a completion and everything just from your simple script.
00:40:19 Okay, check that out for specific projects and for having some script that is just very tightly attached to a project that doesn’t justify like creating a whole package just for that script.
00:40:35 These are actually works quite well.
00:40:37 Okay. Now, I warned you about this before you came on.
00:40:43 You have an awesome mustache.
00:40:46 And I want to I mean, I would probably call it a handlebar, but I don’t know if that’s the right term, but is there a story here? How long have you had this?
00:40:57 So the mustache has been there for actually for several years. I think it’s been there for like, I don’t know, seven or eight years, something like that.
00:41:05 Okay.
00:41:06 And the story is actually quite simple. It’s just that my grandfather, that is quite a character decided to grow a mustache like this and he just went with it and just decided to do it because he called.
00:41:21 And then I said, okay, let’s just follow along and do the same.
00:41:26 I think when he started painting and drawing, he said, I want to have a mustache because I’m a painter now. And it was like after he was like, I don’t know, 60 or 70, I don’t remember. And he’ll say like, I’m just going to. So then I just copied this tile.
00:41:46 That’s awesome.
00:41:48 How much to your grandfather? So was he in Colombia then?
00:41:53 So my grandfather is quite a particular person. Yeah, he’s in Colombia and he was a cyclist when he was young and he went to the first Colombian team to go to the Tour de France from Colombia. And then he decided to retire and just have a farm and have animals and then lately he decided to be a painter, so yeah, he’s been doing whatever he wants, I think.
00:42:24 Is he still around then?
00:42:25 Yeah, okay. He’s still around.
00:42:28 Do you get to visit Columbia very often?
00:42:32 Not that much recently with coronavirus and stuff, but, yeah, from time to time I get to go there and visit. Nice, everyone.
00:42:41 Okay, I think we covered this already, but are you in Berlin now?
00:42:46 Yeah, I’m currently living in Berlin and working with explosion.
00:42:50 Okay. And I’ve never been to Berlin. I want to do that sometime once we get the travel things settled out.
00:42:59 It’s a very nice city. Make sure to come and let me know so we can have a coffee around.
00:43:03 Thanks so much. I want to thank you for coming on the show, but also for all your work on fast, API and typer.
00:43:11 Yeah, thank you very much. Thank you very much for having me. It’s a great pleasure.
00:43:20 Thank you, Sebastian, for that great interview and for working on fast, API and typer. Thank you to Patreon supporters join them by going to testandcode.com support and thank you, Python for sponsoring this episode. The link for the extended protrud is at testandcode.com PyCharm that link is also in our show. Notes at Test And Code.com 120 that’s all for now. Now go out and test something.