Introduce type hints PEP484 and integrate mypy into CI/CD

This issue was opened to discuss if nornir should introduce type checks and mypy.

Mypy is a static type checker for Python 2 and 3. It is quite smart and can infer a lot of types based on the code and type hinting which was introduced with PEP 484 Prior to Python 3.6 type hints were specified using comments: # type: <type>, but Python 3.6 introduced new type hinting using: var: <type> = <value> While some perceive it as ugly, it really helps (at least in my opinion):

• easier to document types there instead of docstrings, which can easily become outdated (just to clarify, I am not saying to remove docstrings, just types from them)
• easier to understand the code with types
• static type checker like mypy can catch some bugs early
• with more adoption, library maintainers will be pushed to migrate to it or provide stub files describing types so that application using the library can leverage those types

I am definitely not a mypy expert, but I was helping certbot (medium codebase, around 35k LoC) to migrate to mypy during PyCon sprints. We caught a dozen of small bugs and found places with weird code that definitely require refactoring.

The strategy was:

1. Add mypy with weak checks
2. Fix all found problems
3. Add mypy to CI/CD
4. Switch to stronger type checking settings one at a time
5. Repeat 2-4

As a point of reference we used this document written by Zulip team who successfully migrated to mypy for even larger codebase. Good presentation to understand type hints and how to do it in real-world: Carl Meyer - Type-checked Python in the real world - PyCon 2018

[dbarrosop]

I don’t think we need to rewrite anything for asyncio, we will need to provide a new facility as you suggested though but in the end nornir may end up having a run and an async_run mode. We will have to experiment a bit with this.

Regarding futures, to provide all that functionality there are bunch of very heavy classes that don’t scale well. You are free to test but while we could scale current solution to process thousands of devices in seconds, using futures took instead minutes.

Regarding py36+ syntax, go for it. I have a PR open already to get rid of anything <py3.6. Even though it’s going to make it harder for some people to use I think it’s worth it. Just for the sake of completeness, the comparison with black is not fair as you run black in your development machine or CI but nornir will end up running in bastions and control machines which sometimes are… heavily outdated. In any case, I think we should encourage people to containarize their nornir applications so we can focus on writing clean and modern code.

[dbarrosop]

Closing this as I think it’s completed