-
-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix pep8 violations #329
Fix pep8 violations #329
Conversation
It doesn't seem like following this rule will lead to clearer code in the violations in this codebase.
The E402 module level import appears to be an error of some kind in flake8?
It seems like this hasn't been consistently followed in this codebase, and the number of changes was fairly large.
Codecov Report
@@ Coverage Diff @@
## master #329 +/- ##
=======================================
Coverage 98.42% 98.42%
=======================================
Files 2 2
Lines 254 254
=======================================
Hits 250 250
Misses 4 4
Continue to review full report at Codecov.
|
Seems like there are no objections, and this seems like an incremental improvement, so I'm going to merge this. The line length thing can be figured out later. |
@tony @carljm
Problem
One of the checkboxes in the PR checklist ("Write PEP8 compliant code.") wasn't covered in #317, since there were many pep8 violations already present in the repo. I said I would fix flake8 violations in another pull request.
Solution
I added a
flake8
tox environment which runs flake8 to enforce pep8-style code formatting. I've ignored the following errors:E731 do not assign a lambda expression, use a def
Personally this one always struck me as sort of silly and pedantic. I don't think it improves code readability, and can sometimes detract from it. I can fix the violation of this rule if requested.
W503 line break before binary operator
I think this actually leads to less readable code in many cases, since violating this allows showing the operator connecting the two lines at the beginning of the line (emphasized) rather than the end (deemphasized). As before, I can fix the violation of this rule if requested.
E402 module level import not at top of file
This seems to have been a false positive. I think
flake8
dislikes this conditional import, but it looks fine to me:django-model-utils/model_utils/models.py
Lines 7 to 15 in 16dec4d
If requested, I can either exclude this particular set of imports, or alter the ordering of execution, though it doesn't seem like a win for code clarity.
E501 line too long
There are a large number of violations of the 80 character line length limit, which argues against fixing this. In particular, it would likely introduce difficult merge conflicts with most of the open pull requests.
One option would be to pick a longer limit, like the 88 characters preferred by Black, or some other higher value like 100 or 120. The longest line is 114 characters, so choosing 120 would require no code changes. Choosing 100 would require few code changes (6 lines).