Type check untyped code using correspoding stub

[movermeyer]

I have a file I don't want to add type annotations to (not my code, core.py) and a stub for that file (core.pyi).
I would like mypy to check for type issues in the file, pulling in the types from the stub as needed.

Example workflow:

Untyped code (core.py):

def foo():
    return '123'

Corresponding stub file (core.pyi):

def foo() -> int: ...

Note that if the type annotations were in the code, it would catch the type issue;

$>mypy core_with_type_annotations.py
mypy_test.py:2: error: Incompatible return value type (got "str", expected "int")

It would be useful if mypy core.py would pull in type annotations as necessary from the corresponding stub file (possibly by supplying a flag on the command-line):

$>mypy --use-self-stubs core.py
mypy_test.py:2: error: Incompatible return value type (got "str", expected "int")

Since this feature does not exist, I currently have to modify the source directly and add the type annotations, and then back out those changes if I need to make a commit against the source (being careful not to commit the annotations).

[adewes]

Seconded. I have the following use case in mind:

For some projects (e.g. https://github.com/DCSO/flor.git) I need to keep the code compatible with Python 2, which therefore makes using type hints directly in the code impossible. However, by adding stub files for each library file (https://github.com/DCSO/flor/tree/feature/stubbed_type_hints), I can create type annotations that can be used to check external code calling my library (in this sense the .pyi files are like C/C++ header files). Now, to make sure that the definitions in the pyi files match those found in the actual modules it would be amazing if there was a way to check the stub file against the actual Python code (btw this would be useful in general when building stubs in order to detect mistakes in the provided signatures). Like that it would be possible to check the un-annotated Python code using mypy while keeping it compatible with Python 2.

[msullivan]

I don't think we're going to do this. I think something could be hacked up using a third-party tool

[DylanYoung]

What are the stub files for then? Genuinely curious. I thought this was the whole point of mypy...

[JelleZijlstra]

@DylanYoung the purpose of stub files is to enable type checkers to understand third-party or otherwise inaccessible code being used in the code that's being typechecked. For example, mypy uses the Python standard library stub files to understand which types Python standard library functions accept.

[DylanYoung]

I understand that purpose. But I've been told form the beginning that an alternative to inline annotations was to use stub files (a much cleaner alternative in the opinion of many). The functionality doesn't seem to have parity though with inline annotations. I've never seen this mentioned before stumbling on an article that led me to this obscure issue. So, maybe it's just a matter of clarifying some documentation (and unfortunately, loads of third-party articles, lol).

I guess what I'm saying is: this is huge barrier to adoption. It's somewhat ironic in that it will lead to a proliferation of third-party stubs because they simply don't provide much first-party benefit without this fix.

[DylanYoung]

As for a third-party tool. What's the vision there? Run MyPy on both the original source and the stub file and then compare the two ASTs (or whatever MyPy uses internally)?