Interest In Type Annotations

[dosisod]

Hi! I was wondering if there was any interest in adding type annotations to this library.

I saw on README that python2 is still supported, so this eliminates the option of having inline type annotations. As an alternative, we could have use type comments:

# add.py

def add(a, b):
    # type (int, int) -> int
    return a + b

Or make seperate .pyi type stub files:

# add.pyi

def add(a: int, b: int) -> int: ...

These files could be stored in this repository, or stored in typeshed. which allows type checkers access to type stubs for lots of standard and 3rd party libraries.

Let me know what you guys think! I dont mind putting in the effort, just thought I might ask before I get anything started.

[Flameeyes]

We're definitely interested in type annotations — Python 2 is not really supported in the master branch anymore, as we switched to Python 3.5 at a minimum, which means it still requires comment type annotations.

I'd go for commented types and py.typed files, as that would satisfy pretty much all type checkers expect pyre, and I would say that it's pyre's problem to solve there.

[dosisod]

Sorry for the late response, I am starting to work on a PR that will add type annotations. As for the style, we are going for commented types (inlined with the code)? Also, I do not know what py.typed files are, are they similar to .pyi files? I've always used mypy, so I am not super familiar with other type checker's conventions.

If we are wanting to use a different type checker, let me know. I can also add the type checking to the CI workflow. Also, are we wanting to add type annotations for the tests as well, or just the source code?

Thanks!

[Flameeyes]

Commented types inline are needed, as we still support Python <3.7 and that won't take the inline types just yet.

As for py.typed — no they are not .pyi, they are just a marker that the package is type-annotated and mypy can use it to know when type-checking a downstream package. See PEP 561 for details.

mypy as a checker is a good fit — the alternatives are not useful to us.

If you can get the tests to be typechecked, even better, but I wouldn't be holding my breath. I have had to fix assertion interfaces before, and would be surprise if no issue is left with those.