Pylint prefers list comprehension over filter...

[pcmanticore at gmail.com]

On Tuesday, May 10, 2016 at 5:58:37 PM UTC+3, Steven D'Aprano wrote:
> Hi Claudiu,
> 
> 
> On Tue, 10 May 2016 11:51 pm, Claudiu Popa wrote:
> 
> > Thank you for letting us know. While pylint is indeed
> > opinionated in some cases, we're not trying to be
> > "arrogant", as you put it, towards Guido or the other core
> > developers. What's sad in this particular case is that the
> > feedback had to come in rather a harsh manner, on this group,
> > instead of being reported as a bug or an enhancement on pylint's
> > bug tracker.
> >
> > Anyway, I wanted to tell you that I agree with your opinion
> > regarding that message and as such, it is removed and won't be
> > emitted anymore in the next release (1.6)
> 
> Thanks for being so understanding!
> 
> Speaking for myself, I think that the test for filter versus list
> comprehensions is a reasonable test to include, so long as it is disabled
> by default. Does PyLint support opt-in checks?
> 
> 
> 
> -- 
> Steven


Hi Steven,

Yes, pylint is pretty configurable regarding its checks.
First of all, we have extensions, which are checks which were
found unsuitable to be part of the core, thus they need to be
manually activated, as in:

    $ pylint --load-plugins=pylint.extensions.name_of_the_extension

We also have a group of checks that are disabled by default, as
is the case of the Python 3 porting checker, recommended as well
by the Python 3 porting guide
(https://docs.python.org/3/howto/pyporting.html?highlight=pylint)
These needs to be enabled manually, as in:

    $ pylint --enable=python3
    $ pylint --enable=other_disabled_group

Last, but not least, each check can be (de)activated manually:

    $ pylint --disable=no-member
    # don't care about conventions and refactoring warnings
    $ pylint --disable=C,R
    $ pylint --disable=all --enable=no-member,other_check_I_want

The bad-builtin check is now an extension, so using the first case
would enable it.

Another thing that is going to change with the next release is
the introduction of tiers. Basically, pylint overwhelms the user
right now with its enabled checks and we're trying to split these
into tiers, as seen in the following:

    $ pylint myproject
    # core checkers enabled
    10/10 - Congrats, you're clean on a core. You might try with "--pedantic" now.

    $ pylint myproject --pedantic
    # pedantic checkers enabled.
    10/10 - Congrats, you're clean on pedantic. You might try with --refactoring now

    $ pylint myproject --refactoring
    # refactoring checkers enabled
    10/10 - Congrats, you're clean on refactoring. Last up, try with --style now.

    $ pylint myproject --style
    10/10 - Now you're pylint clean.

    Or running them all:

    $ pylint myproject --all

(The discussion and whatnot can be found here
https://github.com/PyCQA/pylint/issues/746)