Skip to content
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

Warn about unnecessary "cast"s or "# type: ignore"s #1470

Closed
rwbarton opened this issue May 3, 2016 · 2 comments
Closed

Warn about unnecessary "cast"s or "# type: ignore"s #1470

rwbarton opened this issue May 3, 2016 · 2 comments
Labels

Comments

@rwbarton
Copy link
Contributor

rwbarton commented May 3, 2016

casts and # type: ignore comments are unpleasant things, and have the potential to mask future type errors. Some particular instances of these in a program may become obsolete over time, either due to type changes in the rest of the program, or due to mypy becoming smarter (see #1447 for some instances of the latter). It would be nice if mypy could point out such instances in the modules it type checks. For cast(T, expr) this could mean checking whether expr already has inferred type T, and for # type: ignore, which works by silencing error messages reported on the line of the comment, this could mean checking whether any such error messages were actually generated (and then discarded).

One issue is how to avoid false positives in a situation where a cast or # type: ignore comment is needed when type checking under certain configurations, but not others (for example, dependent on the python version or the version of a dependency). A special case of this issue is type checking generic functions with type variables with value restrictions, which are type checked once for each combination of legal values; a cast might be needed when specializing AnyStr to bytes but not str, for example. This case could be handled entirely by mypy with some extra care, but the general issue remains.

@gvanrossum
Copy link
Member

See also #958 (maybe mark one as duplicate?)

@rwbarton
Copy link
Contributor Author

rwbarton commented May 5, 2016

Ah yes. I'll make this a duplicate and move relevant comments to that issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants