Why doesn't Pylint like built-in functions?

I have a line like this:

filter(lambda x: x == 1, [1, 1, 2])

Pylint is showing a warning:

W:  3: Used builtin function 'filter'

Why is that? is a list comprehension the recommended method?

Of course I can rewrite this like this:

[x for x in [1, 1, 2] if x == 1]

And I get no warnings, but I was wondering if there's a PEP for this?

Pylint often chatters on about stuff it shouldn't. You can disable the warning in a .pylintrc file.

This page http://pylint-messages.wikidot.com/messages:w0141 indicates the problem is that filter and map have been superseded by list comprehensions.

A line like this in your pylintrc file will quiet the warning:

disable=W0141

> Why is that? is a list comprehension the recommended method?

List comprehension is recommended in [the tutorial example][1], which states

> it’s more concise and readable.

and by most answerers on SO's https://stackoverflow.com/questions/1247486/python-list-comprehension-vs-map/6407222#6407222 where [it is][2]

1. more efficient to use list comprehension than filter if you are defining a lambda each time
2. maybe more readable (and with similar efficiency) to use filter if the function is pre-defined
3. necessary to use filter and map if you

• map map,
• curry map, or
• use functional programming

TL;DR: use list comprehension in most cases [1]: https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions [2]: https://stackoverflow.com/a/6407222/1587329

I ran into the same problem and could not figure out

why the built-in function `input' is bad. I you intend

to disable it:

> pylint --bad-functions="[map,filter,apply]" YOUR_FILE_TO_CHECK_HERE

Once you like the settings:

pylint --bad-functions="[map,filter,apply]" --some-other-supercool-settings-of-yours
--generate-rcfile > test.rc

Verify that your settings are in the file, e.g.:

cat test.rc | grep -i YOUR_SETTING_HERE

After that you can use this file locally

pylint --rcfile test.rc --your-other-command-line-args ...

or even use it as your default rcfile. For this I kindly refer you to

pylint --long-help

I've got the same warning on my project. I'm changing the source code to be py2/3 compatible, and pylint helps a lot.

Running pylint --py3k shows only errors about compatibility.

In python 2, if use filter, it returns a list:

>>> my_list = filter(lambda x: x == 1, [1, 1, 2])
>>> my_list
[1, 1]
>>> type(my_list)
<type 'list'>

But in python 3, filter and other similar methods (map, range, zip, ..) return a iterator, that is incompatible types and perhaps cause bugs in your code.

>>> my_list = filter(lambda x: x == 1, [1, 1, 2])
>>> my_list
<filter object at 0x10853ac50>
>>> type(my_list)
<class 'filter'>

To make your code python 2/3 compatible, I use a cheat sheet from python future site

To avoid this warning, you can use 4 approaches, that works on python 2 and 3:

1 - Using a list comprehension like you said.

2 - Using a list function, grant that return always is a materialized list, result is same on both python versions

>>> list(filter(lambda x: x == 1, [1, 1, 2]))
[1, 1]

3 - Using lfilter, that's a future package import. It always return a list, uses filter on py2, and list(filter(..) on py3. So, both pythons got the same behaviour and you got a cleaner syntax.

>>> from future.utils import lfilter
>>> lfilter(lambda x: x == 1, [1, 1, 2])
[1, 1]

4 - The best! Use filter always on a loop, this way pylint don't give warnings, and it have a nice performance boost on python 3.

>>> for number in filter(lambda x: x == 1, [1, 1, 2]):
>>>     print(number)
>>> 1
>>> 1

Always prefer functions that works on python 3, because python 2 will be retired soon.