Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Allowing convenient selection of checked error codes #96
In this issue, I'm going to list a number of related features that I feel deserve a clear solution that can't be achieved by solving each one independently. I also suggest a possible solution. *I highly encourage anyone to criticize the features and the solution. Of course everyone is also encouraged to suggest alternative solutions, use cases or related features. In short - show me where I'm wrong.
Right now, the only implemented feature is (2):
#3 Proposed Solution
For the sake of the following use cases, assume that there exists two mutually
Also assume that there are many more errors of either of these types.
4.1 As the user, I want to use the PEP257 convention
4.2 As the user, I want to use the PEP257 convention, but also check for D104
4.3 As the user, I want to use the PEP257 convention, but check D102 instead of D101
4.4 As the user, I don't care about specific conventions. I just want to specifically check for D100 and D102
4.5 As the user, I want to use the numpy convention, but also check for D103
4.6 As the user, I want to use the numpy convention, but also ignore D104
4.7 As the user, I want to use the numpy convention, but check D101 instead of D102
The following flags should achieve this:
4.8 As the user, I want to usually check for D100, D102 and D104, but sometimes ignore D104 when I run pep257 manually
4.9 As the user, I want to usually check for D100, D102 and D104, but sometimes also check for D103 when I run pep257 manually
4.10 As the user, I want to usually check for D100, D102 and D104, but sometimes I want to check by numpy standards instead.
referenced this issue
Jan 20, 2015
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)
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:
@xZise I think the main point of difference is your sentence:
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.
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.
referenced this issue
Aug 2, 2015
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: