Pylint: Can't disable bad-option-value

[mirkovich0]

Steps to reproduce

1. Write code on a computer with a somewhat new pylint (2.4.3 in my example). Get a warning like useless-object-inheritance that I want to ignore, as I'm writing code compatible with python2 and python3.
2. Disable said warning with # pylint: disable=useless-object-inheritance.
3. Get a "Bad option value" when other people run their pylint version (example: 2.3.1; and by people, sometimes I mean docker instances ran from Jenkins that I would rather not rebuild or that depend on other people and I can't modify)
4. Try to disable said error with a global # pylint: disable=bad-option-value

Current behavior

# pylint: disable=bad-option-value is ignored
# pylint: disable=E0012 is ignored

Expected behavior

To be able to write code that works on several versions of pylint and not having to make sure every computer in the company and every docker container has the same pylint version.

[PCManticore]

Thanks for the report, this is definitely something we should be able to fix.

[mirkovich0]

Hi. It seems to work when it's on the same line but not globally (which could be useful but I didn't found anything on the documentation). So I have to do:
# pylint: disable=bad-option-value,useless-object-inheritance
If I later want to use another option, I have to repeat it again:
# pylint: disable=bad-option-value,consider-using-sys-exit

[dbaty]

My (unwarranted) two cents: I don't quite see the point of allowing to run different versions of pylint on the same code base.

Different versions of pylint are likely to yield different warnings, because checks are added (and sometimes removed) between versions, and bugs (such as false positives) are fixed. So if your teammate does not run the same version as you do, they may have a "perfect pylint score", while your version gets warnings. Surely you'd rather have a reproducible output, and the best way to achieve that is to warrant a specific version of pylint across the team and your CI environment.

[vestronge]

@dbaty Running different versions of pylint helps when porting code from Python2 to Python3

[socketpair]

So, what's the status ?

[Knio]

Dropping support for an option, and also having a bad-option-value be an error makes pylint not backwards compatible. It looks like you expect everyone to be able to atomically update their pylint version and all of their code annotations in all of their environments at the same time.

I maintain packages supporting python 2.7, 3.4-3.10, and since pylint no longer supports all of those, I'm forced to use older versions of pylint in some environments, which now are not compatible with the latest. I don't know if this is a new behavior or has always been this way, but today was the first time I've had any problem with pylint , and am going to have to disable it in CI now.