Question: Can I get mypy to type check in "strict and safe" as opposed to "best effort" style?

[axch]

I don't know how typical a user of mypy I am, in that the thing I am using it for is to lean on its type system to give me feedback about a complex new program from the beginning, as opposed to retrofitting types onto an existing project to look for bugs in it. In my case, false negatives (i.e., failing to type check something, or silently giving something the wrong type) are much worse than false positives (loudly claiming a type error in code that actually executes fine). I am also willing to adjust my program to a considerable degree to make it type-check, in part because I expect the result to be easier to read as well (and in part because I am used to programming in Haskell). In return for that, I am looking for confidence that the program does not commit type errors, and therefore the architecture is reasonably sound, at least at the type level.

I can, however, imagine a large community of mypy users that are trying to use mypy to look for type errors in large existing programs, presumably incrementally. In this case, false positives are very problematic, because too many too early would make the task of typing a program too difficult up front, without showing enough value early enough to make it seem worth it. In light of this use case, I can certainly understand that mypy would lean toward admitting false negatives to reduce the rate of false positives by default (silently skipping non-annotated functions, silently inserting the Any type, etc).

My question is this: Is mypy intended to support the "no false negatives" use style? If so, how can I get it to be as aggressive as possible? I already found --strict-optional --disallow-untyped-calls --check-untyped-defs, but those seem like isolated "stricter" decisions in a sea of "best effort" defaults. Ideally, I would like to get mypy to complain loudly about every little place where some construct is problematic.

One specific example is Issue #2776. That is a situation where the "right thing to do" depends on whether the user wants to avoid false positives or false negatives. It is also a sufficiently specific situation that it probably doesn't warrant a command line flag of its own, but it could reasonably be influenced by a global --avoid-false-negatives flag.

Full disclosure: my real use case is a mixture. The reason I am writing the program I want to type check so strictly in Python in the first place is because I want it to be able to call out to a substantial pile of (not type-checked) Python code my research group has already written (which I am willing to add type annotations to, and to modify locally, but less willing to substantially refactor based on feedback from the type checker). So what I really want is per-file or per-function selection of whether to prefer a low false-negative or a low false-positive rate; but I can make do with a global setting :)

[JukkaL]

Github master now supports the --strict flag (it's not officially released yet) which may be helpful for your use case and enables a bunch of 'strict' options. It's still not perfect and we have some ideas about how to improve it further -- see #2696, for example. If you find other cases where you get unexpected false negatives, please open an issue. We'd like to fix these and make mypy more robust, though not always when using the default configuration. You can also vary type checking options on a per-module basis using a config file.

Mypy is intended to support both writing new statically typed code and adding static types to existing code, though our current development focus is to make it easier to retrofit existing large codebases, since that is what the core team is working on at Dropbox.

[axch]

Thank you. That is an answer to my question.