Type-Checking Python Programs With Type Hints and mypy

Get quick intro to Python type hinting using the mypy type checker, in order to catch bugs and improve the quality of your existing Python code.

In this video I'll walk you through a simple example of what Python's new type hints allow you to do, then I'll show you how to install and use the mypy type checker as a static analysis tool from the command line. At the end you'll get an outlook of the future of type checking and the type hinting syntax in Python.

* * *

FREE Python Tutorials & News:

[hehehe]

two things:
1, you should run pip install mypy now since the package names have been updated
2, you don't have to run the function in your code for it to be checked by mypy

[RameenFallschirmjager]

From the chaos and the menace that rage out there, I take shelter in serenity and stability and reliability of programming!

[FRIENDSofCAP]

FYI:: mypy-lang is not longer supported according to the terminal response... And as of pyton v3.7.4 (which I am running) suggests installing 'mypy' (i.e., pip install mypy'

[aoeu]

IMO: doctests with extended syntax can be used to derive types, and they are a better form of documentation than types.

Which is more useful:
join(Sequence[Sequence]) -> Sequence
or
% join(["cold", "bath"]) -> "coldbath"
% intadd(!1, !2) -> !3
So it will look at the arguments in your test, and annotate the function but any list or str will generalize into a Sequence and ints and floats will turn to Number unless you write ! which means don't try to "generalize" the types. It can run at about the same time that the type system works on.

[EmadMokhtar]

Is there a way to integrate MyPy to test suite?

[rikless]

Is it possible to type hint objects ? For example, to force a specific class type on an argument.

[sinekonata]

So 4 years later, is type-hinting and type checking the confirmed future of python?

[tcarney]

Two questions and a comment: How would mypy react if you left out the annotations on the arguments but included the one on the return value i.e., *-> int:* ? Can mypy read annotations in a same-line comment instead of embedded in the code?

My comment is that embedded hints add some visual noise for the human reader. *add_them(a, b):* is quite a bit easier for the eye to follow than *add_them(a: int, b: int) ->:* . A compromise might be:

*add_them(a, b) # a: int, b: int, -> int*

In the good-old qbasic days, you used a single character ($, %, etc.) appended to the variable name to force a type: ex. *name$* or *age%* . This was not as visually disconcerting as the PEP484 annotations. I guess as long as one reads annotated python code in a color-coded editor, the visual noise will be reduced somewhat since the annotations will be immediately apparent.

[aharongina]

we have inspect functionality in pycharm

[krishna_o]

does this needs to be done for every overridden method also.

[lindhe]

Cool. Does type hints work with keyword arguments also?

[vincenzofiorentini]

for me, this works in 3.5.4 by having an 'import mypy' in the code. with it, the type check works, without it has no effect. 'mypy-lang' seems seriously deprecated.

[vijayabhaskar-j]

What if I need the add_this function to handle both int and float?

[ORagnar]

I just realized, you sound like the Yankee slugger Alex Rodriguez.

[jonathanmoore]

Python is starting to eat its own tail... Programming is about a means to an end... Not an end in itself.

[RameenFallschirmjager]

So vanilla python is not that much great after all!