global: conflicting D211 and D203

[nharraud]

Scenario:

• install kwalitee and the git hooks
• commit a file containing a class with its docstring
  Kwalitee commit hook will output error D211 or D203 depending on if you added a blank line before the class docstring or not. The two messages conflict because the PEP257 standard changed, see PEP257 changeset.

This has been fixed in pep257 (search for Added check D211) but apparently fails in Kwalitee.

Environment:
Python 3.5.0

[tiborsimko]

@nharraud Can you please provide a test case?

[nharraud]

@tiborsimko I don't seem to be able to reproduce the issue (kwalitee 0.2.0rc8). Maybe it was a mistake on my side as Kwalitee didn't change since I created this issue.
I think that we can close this issue.

[tiborsimko]

@nharraud Thanks, closing it then.

[helix84]

Reopening. Just ran into this when running tests on the kwalitee codebase itself:

$ kwalitee check files
...
kwalitee/cli/check.py
42: D203 1 blank line required before class docstring (found 0)
...
# added the blank line, but "kwalitee check files" still complains about D203
$ ./run-tests.sh 
kwalitee/cli/check.py:42 in public class `Repo`:
        D211: No blank lines allowed before class docstring (found 1)

[jirikuncar]

@tiborsimko @nharraud what about removing pydocstyle and pycodestyle (pep8) completely from kwalitee since we can use pytest integration?

[tiborsimko]

OT1H, it's nice to have all tests included in kwalitee, i.e. also PEP-8/PEP-257, because then we can tell developers "just run kwalitee and if it passes, things are ready for PR". This was the historical way of looking at things.

OTOH, it's also nice not to repeat tests that people are running elsewhere, e.g. we recommend plugging PEP-8 and PEP-257 checking tools in people's code editors, e.g. we have pycodestyle/pydocstyle/pytest usually plugged in run-tests.sh script and visible in CI reports...

From this point of view, if kwalitee does only additional checks and no PEP-8/PEP-257, we could simply plug thusly stripped kwalitee into run-scripts.sh as another checker to run. That would make sense.

But we'd have to be really clear that this does not mean abandoning the ideal of having PEP-8/PEP-257 compliant code 😄 for those people who may retain the historical look mentioned above.