Python Tutorial: Type Hinting vs Type Checking vs Data Validation - What’s the Difference?

Hey there. How's it going everybody? In this video, we're going to be learning about the differences between type hinting, type checking, and data validation in Python. I'm going to be doing some future tutorials on type hinting, pyanic for data validation, and fast API, which uses pyantic. And I see a lot of people who get these terms confused. So, understanding these will be helpful for diving deeper into those individual videos that go more in depth. So, Python isn't a statically typed language. We don't need to specify what data type something is when we create variables or functions. And data types can change throughout our scripts. And that has trade-offs. It gives us flexibility, but it can also lead to bugs that are harder to catch. Now, all three of these concepts that we're covering today, uh, hinting, checking, and validation, they all work with types, but they serve different purposes. So let me give you a quick preview of what we're going to be talking about. So type hints tell us what we expect something to be. Type checking is static analysis that makes sure that we're sticking to our declared types before the code is run. And data validation happens at runtime to make sure the data meets our requirements. So let's dive into each one of these and see what they mean and how you'd want to use them. So let's start with type hinting which is also called annotations. Now, hinting and annotations technically have a small difference. Uh, but for the purpose of this to tutorial, uh, we can assume that they're interchangeable, and most people use those terms interchangeably. Anyways, so type hinting is basically adding type information to variables or function parameters or return values. It improves code readability and maintainability because anyone looking at our code can immediately see what types we're expecting to work with. So, let me add hinting to our example here to show you how it's done. So, here in our function, we see we have first name, last name, and age. But we want people

to know that this is going to be a string. So, we put a colon here and an str. And then here, str and then age. We want this to be an integer. So, we'll put that there. Now, for a return type, we can do this dash arrow here. And then we can say what this return type is. We're returning a dictionary. So we'll add dict there. So we have first name as string, last name as string, age as an integer, and the return type as a dictionary. Now I can also type hint the variable down here where I'm assigning the result of this function to a variable. So doing this will let me know on this one line that I'm expecting a dictionary returned from that function and I won't have to go to the function itself to see that. But it's a bit of a trade-off because if I were to update what the function returns then we'd also have to update that here as well. So if I wanted to do that then just like before we can do a colon and say that this is going to be a dictionary that gets returned from this create user. So the benefits of this are that it creates self-documenting code. So anyone looking at this function immediately understands uh what types it expects and what it returns. It also helps with IDE autocomplete and suggestions because now your editor knows what types you're working with. Now you can type hint almost everything if you want to, but in my opinion it can be excessive because Python is somewhat self-documenting already. So for example uh here where I have this email I could type hint this and say that it's a string but we can already just look at this line and see that this is an fstring here. So I think that this is a little redundant here. So I tend to not uh type hint stuff like that that's obvious. So mainly I'd say that I personally tend to focus type hints on uh function parameters and uh return types and things like that. But here's the important thing about type

hints. Python ignores these type hints at runtime. So they're just metadata. Even if you assign the wrong type to something that you've specified otherwise, it's not going to say anything to you or throw an error at runtime. So let me show you what I mean here. So if I run the code that we have now, we can see that we're printing out this user here and that's to be expected. So that runs fine. But if I change the age here, instead of the integer 38, let's change this to a string, and I'll just type in 38 there as a string. We can see we're not getting any errors here from the IDE uh or any warnings or anything like that. And if I run the code, we can see that the code runs fine because all we're doing is returning this dictionary where we've made these assignments and then printing those out. So, it's running just fine. So, type hints themselves don't actually enforce anything. Just like the name says, it's just giving us hints as to uh what types we can expect. And if we use type-cheing, they give us the ability to use type checking if we want. So, what is type checking? So, type checking and specifically I'm talking about static type checking here. Um, it analyzes your code before running your code to make sure that the types that you specified are correct. So it happens before runtime and catches type mismatches earlier on. And this is going to require an external tool. It's not built into Python like type hinting is. So for this video, I'm going to be using My Pi, which is a popular type checker, but there are others as well. Uh I have the extension installed in VS Code, but it's currently disabled. I disabled it so that we could see the difference here in the editor. Now, this is an official extension from Microsoft and it integrates uh my Pi directly in the VS Code. So, let me go ahead and enable this really quick. I'll go into my extensions here and scroll down and find my Pi. And here it is. I'm going to enable this. And it's probably going to ask me to restart my extensions. No, it's working fine right out of the gate. So now let me go back into full screen mode here. So now that I've enabled that, it should start checking to make sure that my types are correct. Um so if I pull up my problems tab here, then we can see that my pi is now showing an error for the mismatched types that uh when we created the user with this string of 38 here. It's saying create user has incompatible type string expected an integer. So, it's catching that mismatch for us. And that's what type checking is. Type hinting doesn't show us uh errors out of the box. We have to use one of these type-checking tools to do this for us. Now, with that said, this helps us find errors before runtime, but it still doesn't prevent us from running our code. If I run this right now, we can see that it still runs just fine, even though it looks like we have an error here in our problems tab. So the type checker warns us about the problem, but it doesn't prevent us from running the code. That's because my pi is doing static analysis. It's not actually executing anything. So this helps us as we're writing our code by pointing out uh when we're likely doing something wrong by passing in the wrong types, but it can't guard against dynamic data. So things like APIs, user input, or data from files. My PI can't know what those will contain at runtime. And that's where data validation comes in. So data validation is a runtime verification that makes sure data meets specific requirements. It happens during code execution and you can stop your program if the validation fails. And it goes beyond just type checking. It can validate values uh ranges, formats and prevent any bad data from getting into

your application. So when validations fail, it raises validation errors to let you know what went wrong. Now, data validation doesn't even necessarily need to have code with type hinting or type checking. So, before type hinting came along in Python, data validation was still a thing and people were just doing it manually. So, let me show you what that would look like. I have some example here in my snippets file. So, I'm going to copy this and then paste this into our function here. And let me get this uncommented and make sure that our indentation is correct. Okay. So let me save this. And first I'm going to run this with some good data. So I will put that back to a integer of 38. I'm getting some linting warnings here but let's not worry about that. So if I run this code then we can see that works just fine. Now, if I change this to a string again and save that and now run it with our bad data, then we can see that we're getting a type error here because we checked the instance of name, made sure that it was an integer. If it's not, we're raising a type error that age must be an integer. So, that's manual validation, but the downsides here are pretty obvious. So, this is a lot of code here. um it's hard to update and maintain especially as your functions get more complex. So once type hinting came along things like paidantic were developed that use type hinting to do data validation which was great because type hints already provide self-documenting code. So they can also be used for validation without writing all of this uh boilerplate validation code here. So let me show you pyantic here. Um first let me delete the manual validation code there that we were doing and I'll uncomment where we are importing uh paidantic here and this validate call decorator. So now I can just add this decorator here above our function that is validate call. Save that and that's going to be it. So for a very simple paidantic example that's all we need to do in order to validate a function. So now let me test this with some good data. So again I will say 38 as an integer here and run this. We can see that runs just fine. Let me change this back to a string and run this now and let's see what we get here. So we can see that it is uh throwing this validation error here and the validation error is saying one validation error for create user input should be a valid integer unable to parse string as an integer gives us the type the input value and things like that. So that's a lot more informative than our manual approach that we did earlier. uh it tells us exactly what field failed and what was expected. And Pyanic has a lot more built in for us than uh we'd likely want to do manually. So for example, it can also coers and cast data to different types. So if a user passes in the string 38 instead of an integer 38, not the text here, but if they passed in a literal string of the number 38, then it can actually handle this without throwing an error. So if I run this then we can see that our code runs fine. It converted that into an integer for us. Now the my pi extension here is still giving us a type check warning because it doesn't know that we're handling that type mismatch appropriately with paidantic. And pyanic has the ability to be as strict as we need if that's not what we want. So if we didn't want that to cast any data types um then we can turn that off. And

we'll see more on that in the future video on uh paidantic specifically. So now let me take this back to having good data here and rerun this really quick. Okay, so that's data validation. So where does data validation fit into our applications? So it's not so useful for our scripts where we're hard- coding our inputs like we're doing here in this script. It's mainly used with dynamic data where you're taking in data from other sources so that you can protect uh protect against taking in data that's incorrect. So it's great for API payloads, config loading, uh boundary checks where data is coming from external sources, things like that. So let me do a quick recap and overview of what we covered and also some misconceptions that I've heard when it comes to these terms. So first, type hinting. Uh, type hinting adds information to our code, type information to our code. They're not enforced by Python. They're just documentation and metadata that other tools can use. And second, we have type checking. Type checking analyzes our code before it runs and checks whether we're using the right types in the right places depending on what we specified with our type hints. It uses tools like my pi to do this analysis. and it still doesn't prevent our code from running. It just warns us about those potential issues. And third, we had data validation. It's a runtime verification that makes sure that our data meets specific requirements. And it's not strictly limited to just data types, although that is the big one and one of the main reasons that we use it. But it can be verification for anything like whether something is a valid email address or a valid phone number, something like that. And you don't always need all three of these. You should choose based on your needs. So I'm not making this video with the expectation that everyone should be using something like Pantic on every script that they write. I definitely don't do that myself. I only use Pyantic when I'm taking in data from external sources, which isn't the case with a lot of the code that I personally write. So for this example here, if I was writing this script myself and I was the only one who uh was going to be using it, I'm not going to do data validation on this because I can see right here that I'm passing in an integer. It's just unnecessary and uh you know extra code that we don't need. So here's kind of my recommended progression for real world projects and what we should be using. Now I would recommend using typense moving forward. So if you have an older codebase and want to add type hints, it doesn't have to be a complete overhaul. You can add type hints as you go and just fill in a little bit at a time. So if I had more functions here below this create user one, then I could add in the typants just to the create user and not even touch the other ones. I could just update a little bit at a time, commit that code, and then when I get back to this, add in some more. So, I'd also recommend using a type checker that integrates with your IDE uh so that you get early warnings when types aren't what they're supposed to be. So, I used My Pi in this video, but there are different tools out there. So, I've done some recent videos on astral tools like UV and Rough, and they have a new type checker coming out called TY, and it looks fairly promising. I've been messing around with it for a bit uh ever since I released the rough video and it seems to work pretty well and there's an early development extension for VS Code and you can choose that type checker if you want. It just depends on work what works best for you. I'm likely going to be using that TY extension once they flesh that out a little bit more. Now, in terms of data validation, uh like I said, don't go overboard here. Uh you don't need this everywhere. I don't use it on my local projects unless it's explicitly needed to prevent a critical mistake. Uh but you definitely want to validate external data. So things coming from APIs, from users, uh from environment variables. Uh you'll want to validate that with something like Pyantic to avoid saving bad data into your application or database. Now again, I used Pyantic for this video, but that's not the only option out there. Um, and some may depend on what framework you're using. So, for example, if you're using Django, they'll have their own data validation methods instead of something like Pyantic. And as I mentioned before, fast API uses Pantic extensively. So, like I said, in upcoming videos, I'm going to be doing a deep dive tutorial on type hinting best practices and also one on paidantic specifically. So, we'll do a deeper dive into those when those individual videos are released. In this video, I really just wanted to touch on the differences um and some confusion that I've seen floating around out there surrounding these terms specifically. So, having this video out there will allow me to move on to those more detailed videos without getting bogged down in those misunderstandings. So, be sure that you're subscribed if you want to be notified when those future videos are released. But with that said, I think that's going to do it for this video. Hopefully now you have a good idea of the differences between type hinting, type checking, and data validation, and when you might want to use each in one of your own projects. But if anyone has any questions about what we covered in this video, then feel free to ask in the comment section below, and I'll do my best to answer those. And if you enjoy these tutorials and would like to support them, there are several ways to do that. The easiest way is simply like the video and give it a thumbs up. Also, it's a huge help to share these videos with anyone who you think would find them useful. And if you have the means, you can contribute through Patreon or YouTube. And there are links to those pages in the description section below. Be sure to subscribe for future videos, and thank you all for watching.