-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type check untyped code using correspoding stub #3505
Comments
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 |
I don't think we're going to do this. I think something could be hacked up using a third-party tool |
What are the stub files for then? Genuinely curious. I thought this was the whole point of mypy... |
@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. |
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. |
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)? |
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):
Corresponding stub file (core.pyi):
Note that if the type annotations were in the code, it would catch the type issue;
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):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).
The text was updated successfully, but these errors were encountered: