11

I'm in the process of cleaning up code with pylint in order to be able to use it for pre-commit validation. I have a lot of "unused-argument" warning when in fact they are used. Here is an example triggering a false positive.

def addSeven(foo): #Here I have a warning "Unused argument 'foo'"
    foo += [7]

example = [3, 4, 5, 6]

addSeven(example)
print example

I do not wish to suppress globally this warning because i would like to see the times when an argument is really unused. Is there an other option that manually adding a disable comment in each occurence? Is it a known problem with pylint?

Rudy Bunel
  • 784
  • 1
  • 7
  • 15
  • 2
    According to http://lists.logilab.org/pipermail/python-projects/2009-March/001800.html, that's because `foo` is not actually used inside the function (apart from being the left operand of `+=`). – Frédéric Hamidi Jan 02 '14 at 11:22
  • 1
    Here, you can change the code to use `extend` instead of `+=`. There may be other such transformations you can perform to eliminate other warnings. – user2357112 Jan 02 '14 at 11:33
  • Ok. That still leaves me to modify each occurence but it's a bit cleaner than using pylint comments – Rudy Bunel Jan 02 '14 at 11:45
  • 1
    This is definlity a bug in pylint. The argument *is used*, the problem being that the '+=' operator is not properly handled. You should submit an issue on the pylint tracker (https://bitbucket.org/logilab/pylint/issue) and you may want to disable the message as suggested by @holy-mackerel in the mean time. – sthenault Jan 06 '14 at 09:17

3 Answers3

14

You can disable it for any scope by adding:

def myfunc(a):
    # pylint: disable=W0612,W0613

see https://pylint.readthedocs.io/en/latest/faq.html#is-it-possible-to-locally-disable-a-particular-message

Holy Mackerel
  • 3,259
  • 1
  • 25
  • 41
5

This is reasonable behavior from pylint; if the object passed is immutable then the statement given is essentially a no-op. Only when is mutable does it seem incorrect.

Unfortunately if you don't want to globally disable the warning then you will need to disable it per instance.

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • You mean "correct no-op", or just a no-op that pylint is blind about? And instead of staying silent it raises "just in case"? BTW, this is probably a bug from long ago, because now I don't get the warning from pylint when checking examples in this post. – Tomasz Gandor Nov 22 '17 at 11:08
4

pylint is generally a good indicator of bad style. Even when it gives a "false positive", it is probably due to doing things against convention. I am no expert, but I'd say a function that only has a side effect is not optimal. Some people (Robert Martin in Clean Code, for example), go as far as saying all side effects are lies.

I'd recommend (again, I am no expert):

def addSeven(foo):
    return foo + [7]

example = [3, 4, 5, 6]

example = addSeven(example)

Arguments should be input-only, and output should be via return value. Output arguments are bad practice, as far as I know.

isilanes
  • 149
  • 1
  • 2