[code-quality] [pylint] disabled messages with --errors-only

[Tim Stumbaugh]

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 at gmail.com> wrote:

> On Wed, Jul 20, 2016 at 8:20 PM, Tim Stumbaugh <stum at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20160720/8297115b/attachment-0001.html>