Add --strict

[alexjurkiewicz]

Changes mypy behaviour re: strict checking flags from opt-in to opt-out.
Also adds --no-* options for all affected flags.

Fixes #2585.

This isn't fully tested yet, but I wanted to get feedback on whether this approach would be acceptable.

[gvanrossum]

Thanks for looking into this!

I think the naming of the various no_xxx special_opts variables is confusing though.

Also, e.g. --no-disallow-untyped-defs has a double negative -- maybe --allow-untyped-defs? (Or do you think that consistently having no as a prefix is better?)

Also as long as we're going to add --no-xxx flags they should also work when the corresponding option is selected from the config file, e.g. if mypy.ini has

[mypy]
strict_optional = true

then

mypy --no-strict-optional file.py

should check file.py without the strict optional flag.

[alexjurkiewicz]

Thanks for the feedback! I've made --no-* args work properly in all situations (including config files).

Regarding the argument format, I was originally thinking of GCC's-Wall -Wno-foo approach, so I favour a consistent --no- prefix even when it makes arguments ugly.

EDIT: I'm a little concerned by the new boilerplate that --no- options have added to main.py. Adding another option to --strict requires:

1. Add option to if special_opts.strict: block
2. Add corresponding --no-foo option following existing examples
3. Add handling for --no-foo option following existing examples

But a cleaner way isn't immediately obvious...

[ddfisher]

You shouldn't need to have a separate explicit assignment step for the negated arguments: set dest in the add_argument call instead.

Also, I'd prefer to see an abstraction for negatable flags over adding more boilerplate (which will be easier to forget when adding new arguments). This abstraction could potentially specify if they're supposed to be part of strict mode, too.

[alexjurkiewicz]

Thanks for the feedback. Added a new commit which uses ternary flags for strict options. This simplifies logic a lot!

This still requires boilerplate for affected options:

• Two options (one hidden, with custom dest and default)
• Special type for mypy.options.Options entry
• Entry in mypy.options.Options.STRICT_OPTIONS dict

But I think the design is cleaner overall and we can cut down the boilerplate further.

[alexjurkiewicz]

The CI failures are due to changing the default value for these params in types.py... not sure what the best approach here is.

[ddfisher]

I think this still isn't quite the right approach. I have a pretty good idea of how we might avoid boilerplate nicely -- I think it'll be easier to implement than to explain, so I'm going to take a shot at it myself and you can tell me what you think.

[alexjurkiewicz]

Closing in favour of #2710