DEV Community

Using Python's Type Annotations

Daniel Starner on August 18, 2018

Python is known for being a Wild West language where anything goes. Indentation aside, code style and documentation are mostly left to the develope...

Read full post

edA‑qa mort‑ora‑y • Aug 19 '18

Type annotations that have no compile-time or runtime effect are worse than not having annotations at all. They will mislead readers of the code, giving them a false sense of security. Debugging will be made harder since we'll start relying on these annotations being true, even if they are not.

Sorry, it's a bad language that allows:

number : int = "Hello"

This doesn't help anything at all.

It would have been better off to just allow inline comments and you'd get the desired effect without the artificial "safety"

foo( number /*int*/, name /*string*/ )

Dave Cridland • Aug 20 '18

Actually it's much cleverer than having a comment:

Your IDE can pick up the difference much more easily and warn you, plus the typing information itself is syntax-checked.
Tools (like MyPy) can enforce it.
Yes, it can be ignored or overridden by a developer - that could be useful inside library internals.
User-defined metatypes, like the UserId example given in the docs, aren't possible with your comments.

For an example of the latter point:

from typing import NewType

UserId = NewType('UserId', int)
user1 = UserId(1)
user2 = UserId(2)

# user1 and user2 are simply integer values, but with typing info.

user = get_user(user1) # OK
user = get_user(user2) # OK
user3 = user1 + user2 # OK, these are ints!
user = get_user(user3) # Not OK! That's not a UserId

Vedran Čačić • Aug 25 '18

By the same thinking, why do we name variables meaningful names? If a compiler lets me write num_tries = 'five', does it follow that we should only name our variables generic names like x and y? After all, num_tries might give readers of the code false sense of security. :-P

Maik Nowak • Apr 18 '19

Ofc it's always easyer to tell why something is bad, than trying to see how it could add improvement. Just use MyPy as part of your Unit test suite and you get immediate value for your CI pipeline. See it like adding some "intentions" (that also your IDE understands #refactorings) to your code and let them be checked for consistency. From a small project point of view that may not seem like a big plus, especially compared to the additional work. But from a more professional point of view this was missing for way to long.

plus: what Dave Cridland said.

edA‑qa mort‑ora‑y • Apr 18 '19

I'm not saying it doesn't have uses, I'm saying that the basic syntax makes the code worse than it was before. The lying about the types will create more bugs.

This type of behaviour is very unusual for a language feature. Most features add value of some kind, or at least sit at zero value. This one actively reduces the ability of somebody to write proper code by misleading them about what is happening.

The fact it has some benefits does not outweigh these guaranteed negatives.

Jiri Novak • Dec 20 '19

After several months your comment seems wrong. Large number of questions on /r/learnpython wouldn't have been even asked if using type annotations + mypy.

Typical mistake: missing int() when using input() to read int values.

rhymes • Aug 19 '18

Type annotations that have no compile-time or runtime effect are worse than not having annotations at all

I agree, that's why I don't use them yet. I might start looking into them if I were to adopt mypy which is a compile time static type checker...

Augusto Santos • Aug 22 '18

Wait, it's just to turn the code more clear and avoid have to guess types to deal with function/methods parameters. Python is not a compiled language, all python programmers know that and won't use this feature like compile time checking for type security.

David McKay • Aug 19 '18

Interesting addition. As an intermediate level coder seeing this for the first time I can see it being useful of every developer looking at the code well read on the syntax. edA-qa makes a good point that it could lead to some people thinking they're making a runtime change when really they're not. The following syntax would make more sense to me:
number = 7 : int
Then the definition is separated from the annotation similarly to an end-of-line comment, which I often use, i.e.,
number = 7 # an integer

Thomas van Latum • Aug 20 '18

twitter.com/carterwickstrom/status...

Thomas van Latum • Aug 19 '18

The problem with statically typed languages is that you tend to spend an enormous amount of time finding out what type of variable you've used somewhere in your code.

For me dynamic typed code works best, I just write variable and function names that are self explanatory.

greetingString = "Hello World!";

vishal • Aug 19 '18

Not if you are coding in C#. var keyword does all the heavy lifting for you and you still have all the good compile-time safety.

yucer • Aug 23 '18

The problem with statically-typed languages is that you tend to spend an enormous amount of time finding out what type of variable you've used somewhere in your code.

Why would you do that ? Given that is statically-typed language the compiler and the editor have the info of the variable type in the moment that you are programming.

They can not do that in a dynamically-typed language without stuff like the one described in this article, or something like the method documentations.

By the way, we can think about this like another way to document the method parameters and result.

I guess it is like this:

statically-typed language: You spent more time selecting the types to define / choose in every context.
dynamically-typed language: You spent more time guessing the types when you are using it.

Take this example:

You are going to use a python function called compute for the first time.

def compute(foo, bar):
   # .... 20 lines here

If the method has no documentation string, you need to read the documentation or read the code to infer the type.

AkashGanesan • Aug 19 '18

Actually, when the language had type inferences, it gets a lot easier and the intent is almost always made clear with type annotations. Haskell is a prime example of how easy it is to use the type system to guide program correctness. Oh, And the thing can look like a dynamically typed language because of the inference engine doing most of the heavy lifting for you.

Rudra • Aug 21 '18

greetingString = "Hello World!";

A pinch of JavaScript camel-case in Python.

Humans are messy !! but that's how they keep themselves evolving

Mohammed El-Afifi • Feb 3 '20

I'm going to write my honest opinion about this. I got to learn about type hinting in python a couple months ago(; I knew it existed long before that but didn't bother to learn about it until recently). While the idea seems promising at the first glance, I think the implementation could be much better, to say the least.

Adding type hints to python was performed in a way that got in the way of developers writing code instead of helping them to do so. It looks like a completely new language was suddenly embedded inside your python code, and makes the developer to write what seems like two languages interspersed on the same line.

First it has a steep learning curve(, and yes I mean the learning curve not the effort to apply the rules to an existing codebase, which is another story). Just consider the different types in the typing module the developer has to learn about to annotate variables instantiated from other popular types(built-in ones or otherwise) like list, tuple, re.Match, ...etc. You can't use the original types because they don't support the generic class syntax like list[int]; you have to instead rely on the equivalent ones from the typing module like List[int]. Even the syntax for specifying a generic class with a type parameter is inconvenient, relying on the indexing operator instead of some other clearer one. So you end up using two families of type names, one for constructing objects and another for annotating. Luckily this doesn't happen with user-defined types as they're supported to be used for both purposes.

And then consider the code changes. I should be honest to say that these changes are needed if you want a static type checker like mypy(which is the only one I've used so far) against your code, which seems the rational and right thing to do after you decide to add type hints(otherwise they'll turn out over time to be just another type of comments). Once you decide to use something like mypy, all hell gates are open. Suddenly some expressions that looked just fine and logical need restructuring and changes. Take for example containers or strings that we can use as boolean expressions; this no longer works because the type checker needs to see that you really mean to test their truth value(especially evident in return statements with functions returning bool). Another example is the need to convert many lambdas passed as parameters to functions to explicit standalone functions, just because the type checker can't sanitize the lambda syntax sufficiently(especially evident with third-party libraries, which I discuss later).

Sometimes the type checker is completely unable to understand what's written and seems like a very clear code snippet, like this question stackoverflow.com/questions/600296... I asked on stackoverflow about how to satisfy mypy without writing a lot of boilerplate code. Please don't get me wrong: I do appreciate the effort that has gone over the years to bring mypy and other type checkers to how they look now, but the deficiencies and shortcomings of these tools adversely affects the full picture of type hinting.

Now consider the conformance and adoption of third-party libraries and packages for type hinting. Very few libraries have done so, and even some very popular ones haven't put the effort to do(like the attrs library for example). This imposes that you must instruct your type checker to ignore uses and references to utilities from these third-party libraries which scanning your code, which still introduces many weaknesses contrary to what type hinting claimed and was intended for in the first place.

I'm still keen and intending to use type hints with my projects, but honestly the status quo of type hinting in python discourages developers from adopting and applying it as a mainstream practice while coding.