`--strict` is too strict to be useful

[msullivan]

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)

[jstasiak]

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-any would 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]

@jstasiak -- I think overriding specific parts of --strict is actually currently supported. For example, I can suppress the return-any errors by doing mypy --strict --no-warn-return-any blah.py.

Somewhat tangentially: maybe we should rename --warn-return-any to --disallow-return-any. It'd definitely be more consistent that way.

[jstasiak]

Lovely, I completely missed that! (+1 on renaming here)

[JukkaL]

I like the idea of making --strict only strict enough that we can reasonably use it in mypy. We could also support an ever stricter mode, such as --strict --strict that would enable more options still.

[SyntaxColoring]

We could also support an ever stricter mode, such as --strict --strict that would enable more options still.

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":

g++ -std=c++17 -Wall -Wextra -Wpedantic my_source_file.cpp

• -std=c++17 selects the variant of the C++ standard to check against. In particular, this says to exclude non-standard GNU extensions.
• -Wall enables all warnings.
• -Wextra enables more warnings because I lied before; -Wall doesn't actually enable all warnings.
• -Wpedantic enables 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]

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: --strict diff is huge.

libvcs: Basic diff, --strict diff

libtmux: Basic diff, --strict diff

unihan-etl: Basic diff, --strict diff

tmuxp: Basic diff, More. --strict diff

[steve-mavens]

@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: ignore case by case. As it is, if I use strict = true there'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]

With #13464, mypy project started to use --strict option, so

We provide a --strict flag that is strict enough that we can not use it in mypy itself

is no longer true.

Is that means --strict option 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]

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 --strict over here: https://mypy.readthedocs.io/en/stable/existing_code.html#introduce-stricter-options