Simplify _verify_rules() and reduce max-complexity=10

[ogenstad]

This PR breaks apart _verify_rules() into smaller components and returns the max-complexity rule to its original setting (the old pylama rule was disabled at some point)

Looking at this function signature it looks a bit fishy where both "data" and "value" are defined as an Any.

In one instance we assume that "data" has a method called .get() and we also assume that "value" is an iterable. It could be that this is always the case but it doesn't look like it using the function signature. And I guess mypy just assumes that anyone using Any has the best of intentions :)

[ktbyers]

I am against having this max-complexity rules enabled. I think it is a net negative for a project (in a pretty meaningful way). Makes you rewrite working/usable code without much value (for fairly arbitrary reasons).

Separately we can decide if we want to refactor the one function/method or not, but I definitely vote to disable the max-complexity rule/check.

[dbarrosop]

I am personally in favor of such linters. I don't know if the right level is 12, 10 or something else but while sometimes they are a bit annoying it prevents people from writing 200 line long methods that are very hard to follow forcing you to think a bit better how to break the code down into something that makes the linter happy.

This PR is a good example of that and given that it hasn't broken anything else [surprisingly] I'd say this is a nice addition.

[ogenstad]

Given that the previous ruleset for pylama was setup with a max complexity of 10 I figured that this was the intention and that the ignore rule for C901 to disable it all together was either a mistake or a shortcut specifically to get around the violation caused by the _verify_rules() method.

I guess it comes down to personal taste, in my mind the value of the update is that the code is clearer and easier to follow. Though if you feel strongly about it I can close the PR. I am curious though regarding the comment about the net negative part are you referring to linters in general or just these type of complexity rules? What negative outcome is it that you see?

[dbarrosop]

I think we should merge as the improvements in this PR are good regardless and if we want to discuss removing complexity linters (or any other kind) we can do it in another issue.

[coveralls]

Pull Request Test Coverage Report for Build 10063961663

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 3 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.1%) to 56.813%

---

Files with Coverage Reduction	New Missed Lines	%
core/filter.py	3	88.61%
<!--	Total:	3		-->

Totals
Change from base Build 9903117464:	0.1%
Covered Lines:	542
Relevant Lines:	954

---

💛 - Coveralls