Type annotations
See original GitHub issue🚀 Feature
Type annotations.
Motivation
Right now, if a project depends on torchvision
and you want to static type check it, you have no choice but either ignore it or write your own stubs. torch
already has partial support for type annotations.
Pitch
We could add type annotations for torchvision
as well.
Additional context
If we want this, I would take that up.
Issue Analytics
- State:
- Created 3 years ago
- Comments:44 (29 by maintainers)
Top Results From Across the Web
typing — Support for type hints — Python 3.11.1 documentation
Source code: Lib/typing.py This module provides runtime support for type hints. The most fundamental support consists of the types Any, Union, Callable, ...
Read more >Understanding type annotation in Python - LogRocket Blog
Python lists are annotated based on the types of the elements they have or expect to have. Starting with Python ≥3.9, to annotate...
Read more >Type Annotation in TypeScript - TutorialsTeacher
TypeScript - Type Annotations. TypeScript is a typed language, where we can specify the type of the variables, function parameters and object properties....
Read more >Type Annotations and Pluggable Type Systems
This means that annotations can be used anywhere you use a type. A few examples of where types are used are class instance...
Read more >7. Type Annotations | Python Tutorial
If you are using an IDE, such as Visual Studio Code, typing the type annotations would allow you to access the built-in functions...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@NicolasHug and I had a similar offline discussion a while back and I want to just add my two cents to the examples:
The problem stems from the fact that you are mixing typed and untyped definitions here. In these cases,
mypy
is very lenient by default. Multiple options out here:--disallow-untyped-calls
:--warn-return-any
So if you want this strictness, it is only one flag away.
This example looks quite non-sensical to me. Could you link the original code so I can have a look at the “real” example?
In general, if you hit such an obscure case this either warrants a refactor of the current implementation or simply a
# type: ignore[foo]
comment.Speaking of
#type: ignore
comments, I’m not sure why you basically insist onmypy
being perfect. If the implementation is logically correct and you are happy with it butmypy
is not, just silence it. I mean for other static checkers such asflake8
we also flat-out ignore some error codes and this doesn’t seem to bother you.https://github.com/pytorch/vision/blob/8e2bd0e070dbac1011134b0a71e88313a406c2b6/setup.cfg#L12
Plus
git grep '# noqa' | wc -l
reveals 14 instances where we silenceflake8
locally.@frgfm @oke-aditya thanks a lot for your recent PRs
I just wanted to point out something: we should only add types to files that we can effectively check types for. Otherwise, we risk having having incorrect type annotation, which is much worse than not having annotations in the first place.
So, when submitting a PR, please make sure that this file is properly covered by mypy.ini (which you may need to edit) so that it can be checked by the CI