Repository navigation
--strict is too strict to be useful #7767
Description
We provide a --strict flag that is strict enough that we can not use it in mypy itself, which is one of the most carefully typed projects I know of.
We should possibly consider removing some flags from strict.
- disallow_return_any? (see False negative when using the power (**) operator #7765)
Activity
jstasiak commentedon Oct 27, 2019
I've been thinking about something related recently – I think it'd be useful to have a way to disable some specific checks while enabling strict mode. So hypothetically
--strict --allow-return-anywould enable all strict checks but--disallow-return-any. Ideally strict could also go in the config file but that's another issue.As it is now I often have mypy configurations that are quite repetitive and when a new check is introduced there's no way to have it enabled automatically after upgrading mypy (although I understand some people wouldn't like it).
Michael0x2a commentedon Oct 28, 2019
@jstasiak -- I think overriding specific parts of
--strictis actually currently supported. For example, I can suppress the return-any errors by doingmypy --strict --no-warn-return-any blah.py.Somewhat tangentially: maybe we should rename
--warn-return-anyto--disallow-return-any. It'd definitely be more consistent that way.jstasiak commentedon Oct 28, 2019
Lovely, I completely missed that! (+1 on renaming here)
JukkaL commentedon Oct 28, 2019
I like the idea of making
--strictonly strict enough that we can reasonably use it in mypy. We could also support an ever stricter mode, such as--strict --strictthat would enable more options still.SyntaxColoring commentedon May 25, 2022
Having seen how this turned out with C and C++, be careful going down this path.
In C++, this is a common incantation to compile with the equivalent of "strict mode":
-std=c++17selects the variant of the C++ standard to check against. In particular, this says to exclude non-standard GNU extensions.-Wallenables all warnings.-Wextraenables more warnings because I lied before;-Walldoesn't actually enable all warnings.-Wpedanticenables more warnings on top of that!That's a lot of arcane options to get the compiler to help you code better.
The end result is that unwary programmers write worse code because they don't know the magic words to get the compiler to help them.
tony commentedon Aug 5, 2022
For anyone who happens upon this from google / searching, here's a recent example of mypy-ifying a project of mine so users can have an idea:
Warning:
--strictdiff is huge.libvcs: Basic diff,
--strictdifflibtmux: Basic diff,
--strictdiffunihan-etl: Basic diff,
--strictdifftmuxp: Basic diff, More.
--strictdiffsteve-mavens commentedon Jan 6, 2023
@SyntaxColoring That said, I would actually use an option that enables absolutely everything, and is guaranteed to do so in future. The reason is that when I'm writing a mypy config, I could enable that and then disable anything I need to. That is, every rule that's too strict for me, and I don't want to have to
# type: ignorecase by case. As it is, if I usestrict = truethere's no easy way to see whether there are any rules in mypy that are useful but that I need to opt into. So I end up browsing the config docs and then comparing everything that looks nice against the list of what's included in "strict".When I bump mypy to a new version, I might have to exclude some new rules. But that's fine for me, because I only do that when I'm ready to tinker with the code and/or config. I won't come complaining that the latest mypy broke my build etc ;-)
yokomotod commentedon Jan 17, 2023
With #13464, mypy project started to use
--strictoption, sois no longer true.
Is that means
--strictoption is enough useful and recommended for normal users (who like the type safe) too?I am currently considering enabling this option, but by finding this issue I am concerned that it is overly strict.
hauntsaninja commentedon Jan 17, 2023
Plenty of people use strict on their projects.
By and large I'd define strict as "mostly the set of checks needed to ensure that you do not have any type unsoundness without an explicit circumvention of the type system, like type ignore, explicit use of Any or cast"
Note that you can turn on strict, then turn off individual checks that don't yet work well for you. I recently wrote up some advice to get to
--strictover here: https://mypy.readthedocs.io/en/stable/existing_code.html#introduce-stricter-options