Allowing convenient selection of checked error codes

[pycqa]

Allowing convenient selection of checked error codes

[Nurdok]

This issue is probably a blocker for #91.

[jayvdb]

I would like to see pep257 using the same arg/config names as pep8 , and use roughly the same order of precedence of applying those args/config. Ideally this becomes a shareable library , so new tools can provide the same configuration options, and their code & time can focus on the linting rules. (flake8 does provide some level of normalisation across these tools, but it would be better they didnt all behave so differently on the cmdline)

[lvh]

This looks fine to me.

[ricordisamoa]

👍

[xZise]

I know I'm a bit late for the party, but I just want to mention this as this bug has been referenced in #91 in which I'm interested.

I find the mutually exclusive error codes handling cumbersome because if one of them is selected you need to disable one and enable the other. So quickly testing with the other mode involves to mention two codes. I'm not sure if it couldn't automatically ignore colliding codes implicitly. Unfortunately there are no examples for mutually exclusive error codes (afaik) so there is probably no current solution.

Regarding #91 which mentioned this bug, it seems like the issue there is a bit different from this here. If there are two different codes, one for 1 line separation and one for 0 lines separation they are not strictly exclusive (you could allow both separations). But especially when looking at that pull request, a new system could allow “options” for each specific code. This doesn't mean that the commands suggested here does need to provide this functionality as I've suggested some alternatives.

By the way there are a few inconsistencies in the examples above, which don't really pose a problem to be bug itself but may be (or in one case are still to me) confusing:

• Section 4: The introduction says D100 and D101 are exclusive but the list and examples use D101 and D102.
• Section 4: The sentence “PEP257 uses D100 (so it's on by default)” sounds superfluous compared to the list below it. As D100 is the only mentioned rule it sounds like D100 is some how special but it's not clear to me how. Is D100 always enabled so even if you choose --convention numpy it's enabled unless numpy specifically disables it? This seems counter intuitive to the --convention parameter which should afaik just be like a default list of selected xor ignored codes (basically a shortcut).
• Section 4.2: Uses --add-ignore=D104 to enable D104. I think you meant --add-select.
• Section 4.6: Uses --add-ignore=D103 to ignores D103 which is selected in numpy by default but header mentions D104.

[Nurdok]

@xZise I think the main point of difference is your sentence:

If there are two different codes, one for 1 line separation and one for 0 lines separation they are not strictly exclusive (you could allow both separations).

I disagree. If one error is for not having exactly 1 line breaks and one for not having exactly 0 line breaks, they are mutually exclusive. If you want to allow both, simply ignore both error codes. This will allow you to put any number of line breaks before class docstrings. I understand that you may want an option that allows 0 or 1 line breaks, but I don't think such an option is sensible in the same way that we don't allow other "count" issues to be configured. Standards are a way to make code look similar. If you allow to choose between several ways of doing something, it isn't really a standard.

Your comments about the inaccuracies of this issues are correct and will be edited.

[xZise]

Well the main reason to allow both is to allow a conversion time where the number may be 0 or 1 (but nothing else, which is not possible when we ignore both codes). In fact for Jenkins flake8 validation on pywikibot there could be two different tests. One non-voting one allow only 0 (the new standard) one one voting one allow both. Over time it'll drift towards 0 as new classes should follow the new style.

Now in the specific case of #91 there is only one additional line so in theory it would be possible to fix all at once relatively easy by just removing one newline. But other future changes to PEP257 might be more complex where it would be advantageous to support both the old and new standard.

[Nurdok]

I understand your position, but I believe that disabling both error codes for the transition is good enough, and a reasonable trade-off to keep a sensible and consistent error model. Your last paragraph seems to actually support this case. Other future change might be more complex in a way that treating each one of them with a specialized flag will bloat the script. They may also be more explicitly mutually exclusive, so this problem might happen again in the future.

My current strategy is this:

1. All error codes from all convention are included in a big list.
2. If more than one convention includes the same "rule", there will be only one error code representing it.
3. If there is a similar "rule" for several conventions, but the "configuration" is different (such as in this case), it should be reflected in multiple error codes.
4. Error codes may conflict.
5. The user can choose whichever error codes he wants from the list, as long as they are not mutually exclusive.
6. The default checked error codes are those in the most recent version of the PEP257 document.