Upgrade pylint to 2.2.2

[scop]

Description:

Upgrade to pylint 2.2.1, address new flagged issues.

http://pylint.pycqa.org/en/latest/whatsnew/changelog.html#what-s-new-in-pylint-2-2

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.

[cdce8p]

IMO we should leave pass as it is. It might not be necessary, but it certainly improves readability.

[bachya]

I agree. Seeing bare lines after a : gives me the willies.

[balloob]

I agree

[scop]

FWIW I do not agree. But anyway I don't think there's a clean way to omit just these particular unnecessary passes, it would have to be done to all of them. And I think doing that would probably make things worse also in eyes of some people who would like to keep just the unnecessary passes that would have been removed in this PR. I certainly think that would make things worse overall. So I'm afraid we're a bit stuck with the upgrade here, then.

[bachya]

You can still look at upgrading – just disable unnecessary-pass in pylintrc.

[balloob]

I think that just disabling unnecessary-pass is fine. We might get some extra pass in places it really shouldn't be, but I think that's fine.

[scop]

Pylint has a lot of opinionate cleanup-like options, it does much more than helps catch common mistakes. Many (most?) of those are enabled for HA, even though what they do have only cosmetic/aesthetic value. Opinions vary whether those are liked or are a good thing, and we've now hit one here where they vary.

As said, I don't personally think that a global unnecessary-pass disable would be a good thing to do, so it wouldn't make sense for me to do that. Others seem to have different opinions on the matter, so I suggest someone first does that along with their reasoning in pylintrc in a separate PR, and afterwards I'll rebase this PR, keeping only the uncontroversial changes. Will take a look at upgrading to 2.2.2 meanwhile.

[cdce8p]

#18985

[balloob]

I wish PyLint was a bit more configurable. A config option for unnecessary-pass to not count doc strings as statements when determining if a pass is needed would have helped here.

[scop]

Yeah, but then again I don't think there's much to blame them for here -- these passes are unnecessary after all, people are just accustomed to seeing them. I found their flagging and looks after removal somewhat odd at first sight too, but after thinking about it for a bit, this is consistent and justifiable so I've tweaked my personal preference instead.