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
Support Flake8 3.0.1 #1621
Support Flake8 3.0.1 #1621
Conversation
Set flake8 to ignore E501 (long lines) Ran the following on graphite/webapp/ autopep8 . --ignore=E501 --recursive --in-place --pep8-passes 2000 --verbose
* ignore E402,E731 and F841 * Slight indent changes * Revert logic from if not <var> in <thing> to if <var> not in <thing>
Set flake8 to ignore E501 on the tests subdir Ran the following on webapp/tests/ autopep8 . --ignore=E501 --recursive --in-place --pep8-passes 2000 --verbose
This doesn't surprise me at all since we've never enforced pep8 indentation. I'll try and review later tonight but it would be good to have some extra sets of 👀 on this. /cc @graphite-project/committers |
Thanks for this − not a fun patch to make! :) I’d suggest going through this in two passes − one ignoring E111, and one only fixing E111. Otherwise the diff makes it insane to spot issues (although autopep8 should be fairly safe to use). P.S. My slightly preferred way to control flake8 ignores is via a dedicated entry in
|
Splitting into multiple pull requests can be done. I'll attempt it this morning. I did attempt to add a |
I usually put a |
Turns out that's where the By the looks of things, it isn't being respected. |
Here's the bug in flake8 https://gitlab.com/pycqa/flake8/issues/181 Fixed in 3.0.2 which was released last night. Since we're already headed down the path of being pep8 compliant let's keep going for now. |
Whoa we are ok with supporting general Python coding standards?! One of the things that always made me sad hacking on graphite was the very anti-pythonic coding style. I'm +1000 on any patches which make graphite project code look like the overwhelming majority of Python projects you see out there. |
Yup. Looks like it. Consistency is good. I opened #1623 for a more staged approach at converting the code base to pep8 compliance. Please review that one. I'm closing this without merging as it accomplished what was intended. |
The only issue is that so much code changes that all currently open pull requests will have to be rebased or redone. I think that was the main counter-argument so far, not opposition to adopting more widely used standards. |
That is a good point − did not think of that. Given how @obfuscurity is on a spree to tackle open pull-requests, might be a good plan to wait for the backlog to further slim down. |
That might be a good idea. Although most of them seem to require rebasing anyways, I think it would make it a fair bit more challenging to throw that into the mix. |
I'm of the opinion that we make the change now. We have the most test coverage we ever have and the backlog is as small as I've ever seen it. |
Note giant style changes like this will break git blame and make merges and I'll encourage a re-reading of pep8's first section... but I'm going to let On Jul 27, 2016 7:21 AM, "Christopher Bowman" notifications@github.com
|
And a lot of the old 1-2 year old PRs likely never will be debased unfortunately. |
Not true, I've been doing this work myself. Jason Dixon
|
My vote would be to hold off until we can get all the PRs in milestone 1.0.0 rebased and merged. I'm 💯 on the spirit of this change, but I also dread the notion of losing git blame. |
P.S. At least until we reach the 1.0.0 milestone. 😉 |
This exceeds hilarious. Opening just for discussion sake for now.
I ran stuff through autopep8 which eliminated most of the noise from the newer flake8. Manually ignored some errors for now, since fixing them isn't easy.
The pep8 statistics from current master are:
On this branch:
All programmatic tests ran clean. There are 2 lint errors in the test files:
The first is from an import that has a # NOQA comment on it. Thoughts on a fix?
The second is because the check doesn't have an assert on the result value. So, that's an oops. I just need time to determine what the check should be.