Add a flag --enable-all-error-codes, which enables all error codes
#19048
Conversation
This comment has been minimized.
This comment has been minimized.
d07c6fd to
fde8f9a
Compare
This comment has been minimized.
This comment has been minimized.
|
OK, I don't really understand the whole situation here with the stubs, but I guess I have to add @overload to a number of them. Whatever they're for. |
This comment has been minimized.
This comment has been minimized.
872aeb1 to
f1a4650
Compare
This comment has been minimized.
This comment has been minimized.
1 similar comment
This comment has been minimized.
This comment has been minimized.
|
IMO this is less discoverable than a flag (e.g. |
|
Agree with @A5rocks - there was a ticket for |
|
@sterliakov, yeah, Although, implementing this as a pseudo error code was pretty easy, which is why I did it. I also think it's a good interface for people already involved in enabling error codes — you just specify |
|
That's an unprecedented behavior for error codes: any existing error code can be used in a suppression comment. I don't think introducing a "meta" error code that isn't usable in I somehow can't find the issue for |
|
@sterliakov Such a reporter should have the purpose of specifying error codes explained to them 🤭 Regardless, I'm a pragmatist about these things, and don't actually care much about the exact flag. While continuing to advocate for the PR in its current state (--enable-error-code all), I'll see if I can easily adapt it into --all-checks, if people like that better. |
|
Also related (and closable by any implementation of this idea) #14143 |
|
True... I'll try to remember to update the documentation to mention this in the documentation of --strict as an alternative. |
|
yes, I agree that a new flag is better than |
…and line although I actually have no idea why that would be the case, as the error for using it in configuration seems inexplicable, since it consults the same list of error codes in the end 🤷
…itives.pyi instead my plan after this, if this doesn't work, is to go to [typing fixtures/typing-full.pyi] ; I'm just blindly trying things
per the advice of the discussors of the github issue
2a80c35 to
0b32309
Compare
|
|
all, which enables all error codes--enable-all-error-codes, which enables all error codes
| See :ref:`error-codes` and :ref:`error-codes-optional` | ||
| for more information. | ||
|
|
||
| This flag will override disabled error codes from the |
There was a problem hiding this comment.
We should not do that. --disable-error-code should work as-is. Otherwise, it would be hard to use.
There was a problem hiding this comment.
Makes sense to me. I'll make the change.
I don't know why the overriding behavior for the extant *able-error-code flags is the way it currently is, anyway. Maybe just happenstance?
| codes, including any that may be experimental, wrongheaded, or | ||
| contradictory. | ||
|
|
||
| Enabling all codes is not the same as enabling all checks that mypy could |
There was a problem hiding this comment.
I would also mention that specifing both --enable-error-code and --enable-all-error-codes must be an error. It is either or.
There was a problem hiding this comment.
I guess if I take your previous suggestion about how --disable-error-code should supersede, then one could use --enable-all-error-codes --disable-error-code x --enable-error-code x, which would be no more erroneous than using --disable-error-code x --enable-error-code x is already. 🤔
| @@ -50,6 +50,10 @@ and :option:`--disable-error-code <mypy --disable-error-code>` | |||
| to enable or disable specific error codes that don't have a dedicated | |||
| command-line flag or config file setting. | |||
|
|
|||
| :option:`--enable-all-error-codes <mypy --enable-all-error-codes>` enables | |||
| all optional error codes. (Remember that enabling takes priority over | |||
| disabling, so other --disable-error-code flags will not countermand this.) | |||
There was a problem hiding this comment.
| disabling, so other --disable-error-code flags will not countermand this.) | |
| disabling, so other :option:`--disable-error-code` flags will not countermand this.) |
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
(edit:
--enable-error-code allis now "spelled"--enable-all-error-codes, thanks to the feedback I received on this PR.)This code change allows users to use
--enable-error-code allto enable all error codes. This "fixes" #2376 (which was closed as not planned — but a decade of hindsight has, I think, revealed that the idea for a flag like this is more practical than it initially seemed). It also addresses a feature request that was mentioned in the course of discussing #18078 (it does not fix #18078, which is an issue about something else).My main motivation to add this feature is that it's very easy to add and somewhat useful to me and others, who sometimes want to see what the effect of enabling all error codes is, whether we decide to check our code with that every time or just want to evaluate all of the codes at once to see which are worthwhile.
I don't think this PR closes further discussion on whether, eg, --strict should also enable every error code, which I also think should be true, but for other reasons; nor what flags should control what other error codes, which is also a fertile grounds for discussion. I conceptualize
--enable-error-codes allas sort of a "low-level" command line option that does something simple to define (all), whereas other flags do something more ergonomic like give you some recommended set of error codes.This code change seems like it should allow not just command line usage but also configuration file usage, but for some opaque reason (perhaps my machine configuration is just cursed?) this did not work for me (it resulted in an "invalid error code" error message). So it's documented as only a command line feature.(edit: this works fine, now)The test for this feature spotchecks that
--enable-error-code allenabledexplicit-overrideand a couple other errors.