Clarified strict documentation#18903
Conversation
for more information, see https://pre-commit.ci
sterliakov
left a comment
sterliakov
left a comment
There was a problem hiding this comment.
This also fixes/improves documentation aspect of #14143. Thanks!
docs/source/command_line.rst
Outdated
|
|
||
| If both strict and strict-included flags are set, strict does not take precedence | ||
| nor override corresponding flags. You can see the list of flags enabled by strict | ||
| mode in the full :option:`mypy --help` output. |
There was a problem hiding this comment.
I think --warn-unreachable deserves explicit mention here as something many (most?) of the users should be interested in enabling separately. It may become part of --strict in future, but isn't now (see #18078)
Co-authored-by: Stanislav Terliakov <[email protected]>
docs/source/command_line.rst
Outdated
| If both strict and strict-included flags are set, strict does not take precedence | ||
| nor override corresponding flags. You can see the list of flags enabled by strict |
There was a problem hiding this comment.
Can this be summarized as "all other error-checking flags have precedence over strict, regardless of the order in which they are passed"?
(that's right, right?)
There was a problem hiding this comment.
I believe you are right, but I think specifying that only the strict-related flags take precedence makes it clearer because they would be otherwise unrelated/wouldn't override. I have updated it to be:
"The strict flag does not take precedence over other strict-related flags. Directly specifying a flag of alternate behavior will override the behavior of strict, regardless of the order in which they are passed."
Although I was going for clarity, does this still seem too verbose?
for more information, see https://pre-commit.ci
4 participants
Fixes #18760
This documentation change basically clarifies strict's behavior as described in the issue, adding precedence of the strict flag with respect to other error-checking flags