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 <pcmantic...@gmail.com> wrote: > On Wed, Jul 20, 2016 at 8:20 PM, Tim Stumbaugh <s...@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 > -- Tim Stumbaugh Operations Hudson River Trading
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
