Tags: python
Python is a strong and dynamically typed language, Strongly typed means that variables do have a type and that the type matters when using or performing operations on the variable such as concatenating 2 different variables.
This also means python runtime doesn't enforce function or variable type annotations. What does this mean I hear you say? Well I'm glad you asked! In python you can create a new variable without specifying its type simply like this:
untyped_int = 1
untyped_string = "What a beautiful string."
untyped_boolean = False
untyped_list = ["item1", "item2"]
untyped_dict = {"key1": "value1"}
This my friends, is called "dynamic typing", you can specify a variable without explicitly stating that it is an integer (or string, list, boolean...you get the picture.)
Python types
Now, I bet you're wondering "How can I trust that what this random, internet gremlin is telling me, is indeed correct?". Well let's take a quick look on our python interpreter, where we will use one of our trusty Python builtin functions, the type() function! This old favourite does exactly what it says on the tin, it takes a single argument and returns the type of that object!
>>> print(type(untyped_int))
<class 'int'>
>>> print(type(untyped_string))
<class 'str'>
>>> print(type(untyped_boolean))
<class 'bool'>
>>> print(type(untyped_list))
<class 'list'>
>>> print(type(untyped_dict))
<class 'dict'>
Ok, nice and simple, right? This is part of what makes Python such an easy to pick up language. But it's reliant on you recognising what makes a string a string, whereas in other statically typed languages it will tell you. Take a look at this java variable, it's clear that we are creating an integer:
int static_int = 1;
Using Python Type Hints
Enter stage left the Python typing module which provides runtime support for type hints. Type hints can be used to provide "hints" to the types used in our variables and functions. Here's an example to wet your appetite:
def my_first_hint(paramter_test:int) -> int:
return paramter_test + 4
This should be pretty self explanatory, except for this weird thing: -> . This a functional annotation or the "type hint" for the expected return value, this means the function should return an integer. Similary the parameter_test: int clearly shows that this parameter should be an integer as well.
Ok, easy peasy right? Well hold your horses, let's see what over variations we have before we get carried away! Here's another function that takes a dictionary as a parameter, where it also specifies the types required for the key, a str and the value, a bool type.
def my_second_hint(paramter_list:dict[str, float]) -> dict:
return parameter_list.update("test", 1.0)
I won't bombard you with all the different options, I'll just leave this link to the type hints cheat sheet from mypy. Which leads me perfectly on to how we can use type hints for a process called type checking.
How to use Static Type Checking
As mentioned above mypy can be used to check our type hints and annotations, Mypy started as a project by Jukka Lehtosalo during his Ph.D studies in 2012, originally as a python variant. However since then it has been rewritten to use annotations and is now a static type checker for regular old Python.
That's enough history, if that's your bag then you can google it or read the mypy history. You can install mypy the same as you do any other python module, with trusty old pip:
pip install mypy
Now we can run mypy on any or all of our python files as below:
mypy fake_file.py
fake_file.py:2: error: Incompatible return value type (got "list[str]", expected "str") [return-value]
Found 1 error in 1 file (checked 1 source file)
Oh no! My fake file and it's fake function failed its type check! Luckily mypy spells out quite clearly where we need to look, fake_file.py on line 2. It even tells us that the return value type was a list of strings but it expected a type of str. If we look at the fake function you can clearly see that the type hint says to expect a string:
def fake_function() -> str:
return ["test"]
If we update it to expect a list we should be good:
def fake_function() -> list:
return ["test"]
Or even better a list of strings (if we're sure that's what we expect to be returned):
def fake_function() -> list[str]:
return ["test"]
Ah yes that's much better!
mypy fake_file.py
Success: no issues found in 1 source file
Ok so you've drank the Kool-aid, but it sounds like a lot of extra work right? WRONG! Ok maybe at first, but it enforces both the programmer and anyone reading the code in the future to know exactly what is expected for the variable, function or class. It acts as it's own documentation or code comments and don't forget to use your IDE to make it easier for you! Third party plugins such as a mypy plugin or a pylance plugin for your IDE will flag any function and variable type hints you may have missed or if the wrong type is returned it will provide a similar error to the mypy error above but by an underline and in-line comment in your IDE.
Static typing vs Dynamic typing pros and cons
Static typing
- Type errors are reported at compile time
- Explicit type declarations offers clean and understandable code
- Early error detection can mean less buggy bugs
Dynamic typing
- Type errors are reported at runtime (type mismatches)
- Variables can change data type during runtime
- simple to use, no declaration of types
Conclusion
The moral of the story is, you can or you cannot enforce static type hinting in your python code along with type hints. The choice is up to you, I honestly don't care! Using static type hints can be helpful when working on larger projects or collaborating because it ensures all team members are adhering to a certain set of rules (or types!). Whereas if you're just smashing out a quick project then good old dynamically typed Python is your friend.