PyAnnotate – Auto-generate type annotations for mypy

PyAnnotate – Auto-generate type annotations for mypy
mypy-lang.blogspot.com

The main difference is that pytype is a static analyzer (i.e. it inspects the code and tries to figure out what types various things are), whereas PyAnnotate is a profiler hook, so you have to run your code and it observes types as your code runs.

Both have their pros and cons. While static analysis (in my personal opinion) would be ideal because you don't have to run your code, and in theory it can be much more complete, it's also much harder (often impossible) in Python. The runtime analysis of PyAnnotate has a lot of downsides (it doesn't give you types for code that it didn't observe run and it can't know if it has seen all the particular types for a parameter or return). The upside is that it was quick to implement something useful and it gets you quickly to pretty descent type annotations for your main code paths. Which is nice, because in a large untyped codebase it effectively lays down a rough draft of type annotations, making it a lot easier to fix up and fill in edge cases by hand.

Pytype is similar to mypy that it can do type checking with proper annotations. In addition to use annotations, pytype can also do inference based on static analysis.

I don't have much experience with mypy but the last time I used it, it cannot infer from `return x == y` that the function returns a bool. Pytype can correctly infer many simple forms of function argument types and return type, and even some more complex form.

From reading the project, PyAnnotate completely rely on runtime profiling info to _help_ you get to the first round of annotations. We also have similar project that gathers types from runtime and help people to annotate the code. The type information gathered this way has its limitations (PyAnnotate project called this out as well, that you should only use it on legacy code but not on newly written code).

To give an example: if PyAnnotate observe a function below to accept a list of ints and returns an int, it may conclude that the type of this function is `Callable[[List[int]], int]`

``` def foo(xs): ret = 0 for x in xs: ret += x return ret ```

But it can actually work on any iterable (because of the for-in loop), and the item in `xs` is number (because the `__iadd__` call on integer 0). With static analysis, the correct inferred type might be `Callable[[Iterable[Union[int, float]]], Union[int, float]]`

This allows for fast prototyping, and when done correctly, easy to add type safety. For example, you can prototype the code, make sure it works, add more tests, then add type checking while cleaning it up and documenting it. That would be my ideal workflow.