[pylint] disabled messages with --errors-only
Hi, Since command line flags are processed after config file directives, error messages that are disabled in a config file (or in a command line flag that appears before --errors-only) are not respected when running in errors-only mode. This appears to be because errors-only mode unconditionally enables all messages with a category of 'E' or 'F'. We have a config file that has the messages that has a few error messages disabled (because of highly-dynamic features that we use that pylint can't interpret correctly), but we do run pylint in errors-only mode quite often. A patch that works for us is to change PyLinter.disable_noerror_messages not to ever enable messages (but only to disable non error messages). That seems like quite a large change though, since a user who only passes --enable (or enables messages through the config file) would not get messages in --errors-only that they haven't asked for. Is there an opinion on what patch might be acceptable for the project? Would it work to add an extra flag or put extra state in the PyLinter object so that it knows which messages have been explicitly disabled? Thanks, tjs -- Tim Stumbaugh Operations Hudson River Trading
On Wed, Jul 20, 2016 at 8:20 PM, Tim Stumbaugh <stum@hudson-trading.com> wrote:
Hi,
Since command line flags are processed after config file directives, error messages that are disabled in a config file (or in a command line flag that appears before --errors-only) are not respected when running in errors-only mode.
This appears to be because errors-only mode unconditionally enables all messages with a category of 'E' or 'F'.
We have a config file that has the messages that has a few error messages disabled (because of highly-dynamic features that we use that pylint can't interpret correctly), but we do run pylint in errors-only mode quite often.
A patch that works for us is to change PyLinter.disable_noerror_messages not to ever enable messages (but only to disable non error messages). That seems like quite a large change though, since a user who only passes --enable (or enables messages through the config file) would not get messages in --errors-only that they haven't asked for.
Is there an opinion on what patch might be acceptable for the project? Would it work to add an extra flag or put extra state in the PyLinter object so that it knows which messages have been explicitly disabled?
Thanks, tjs
Hi, I think we should not touch the error-only mode, especially since it does not provide any guarantee that the previous configured disables or enables are respected, being a mode selection rather than a verbatim shortcut towards disable=all enable=E (the same way with --py3k), the mode being to activate all the known errors. This problem can be of course solved without touching any code, at least on the CLI level that would be equivalent to --disable=all --enable=E,F --disable=m1,m2,m3., while in the configuration this would be equivalent to disable=all enable=E,F disable=m1,m2,m3 with the only caveat that this is currently not possible, due to the fact that we do not support duplicate options in the config files. We still can support this feature with a custom dict type for the config parser, so that is not necessarily an unavoidable problem. These two solutions though have the disadvantages that you will have to repeat the mantra all the time, but I can't find right now an alternative. Having the CLI pragma controls take in account what was activated or deactivated in the config file leads to confusion (if I disable X in config file and with the CLI I am doing --enable=E, should the last part enable X if it was already disabled? If not, why? How do you detect the rule and what gets enabled and what not.) This turns into a slippery slope of edge cases and behavior for which we have to check the documentation all the time. I would rather introduce a DSL that would alleviate our current limitations with the binary world of enabled and disabled messages (with something that can manage to hand pick only those messages from a category of messages, while satisfying some conditions). Claudiu
OK, that's fair. I totally understand the concern that it becomes a slippery slope. It's just a bit annoying to have to remember to get the order of -E and --disable right. :) Thanks for the consideration, anyway! tjs On Wed, Jul 20, 2016 at 6:14 PM, Claudiu Popa <pcmanticore@gmail.com> wrote:
Hi,
Since command line flags are processed after config file directives, error messages that are disabled in a config file (or in a command line flag
On Wed, Jul 20, 2016 at 8:20 PM, Tim Stumbaugh <stum@hudson-trading.com> wrote: that
appears before --errors-only) are not respected when running in errors-only mode.
This appears to be because errors-only mode unconditionally enables all messages with a category of 'E' or 'F'.
We have a config file that has the messages that has a few error messages disabled (because of highly-dynamic features that we use that pylint can't interpret correctly), but we do run pylint in errors-only mode quite often.
A patch that works for us is to change PyLinter.disable_noerror_messages not to ever enable messages (but only to disable non error messages). That seems like quite a large change though, since a user who only passes --enable (or enables messages through the config file) would not get messages in --errors-only that they haven't asked for.
Is there an opinion on what patch might be acceptable for the project? Would it work to add an extra flag or put extra state in the PyLinter object so that it knows which messages have been explicitly disabled?
Thanks, tjs
Hi,
I think we should not touch the error-only mode, especially since it does not provide any guarantee that the previous configured disables or enables are respected, being a mode selection rather than a verbatim shortcut towards disable=all enable=E (the same way with --py3k), the mode being to activate all the known errors.
This problem can be of course solved without touching any code, at least on the CLI level that would be equivalent to
--disable=all --enable=E,F --disable=m1,m2,m3.,
while in the configuration this would be equivalent to
disable=all enable=E,F disable=m1,m2,m3
with the only caveat that this is currently not possible, due to the fact that we do not support duplicate options in the config files. We still can support this feature with a custom dict type for the config parser, so that is not necessarily an unavoidable problem.
These two solutions though have the disadvantages that you will have to repeat the mantra all the time, but I can't find right now an alternative. Having the CLI pragma controls take in account what was activated or deactivated in the config file leads to confusion (if I disable X in config file and with the CLI I am doing --enable=E, should the last part enable X if it was already disabled? If not, why? How do you detect the rule and what gets enabled and what not.) This turns into a slippery slope of edge cases and behavior for which we have to check the documentation all the time.
I would rather introduce a DSL that would alleviate our current limitations with the binary world of enabled and disabled messages (with something that can manage to hand pick only those messages from a category of messages, while satisfying some conditions).
Claudiu
-- Tim Stumbaugh Operations Hudson River Trading
participants (2)
-
Claudiu Popa
-
Tim Stumbaugh