Enforce linting via the test suite #79
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Most readers are users, not contributors. Only contributors ought to run the test suite.
Run Pylint on every project Python file. Dynamically generate a test case for every Pylint failure. Require Pylint for development via requirements.txt. References: * http://blog.jameskyle.org/2014/05/pep8-pylint-tests-with-nose-xunit/ * http://stackoverflow.com/a/20870875/62269 * http://stackoverflow.com/a/33714768/62269
* Relax function name length. I like self-descriptive function names, which can be long, in moderation. * Relax docstring-min-length. Code that short should be self-documenting. Relatedly, test cases don't need a docstring. * Relax min-public-methods. I understand the OOP lecture Pylint is trying to give. This project and its collaborators aren't at risk of that. * Allow GAE constant name * Allow TODOs. I can grep for those myself just fine.
Remove obsolete HTTP RPC route to run the test suite. Travis CI does that now.
Jumping through hoops for an old version of Python isn't worth it. Pylint 1.4 is superior to Pylint 1.3. It's the same code for all versions. If we have to skip Python 2.6 lint checks, so be it. This mostly reverts commit 8882913. Keep the Pylint subprocess stderr checking.
Skip linting for Pylint's unsupported Python versions, 2.6 and 3.5
john-kurkowski
force-pushed
the
pylint
branch
from
8882913 to
8fb5ddd
Compare
Document _get_tld_extractor's recipe and split it into several private methods.
john-kurkowski
changed the title
|
Nice work!!! |
|
Thank you. I clearly didn't have anything better to do this weekend. 😄 |
john-kurkowski
added a commit
that referenced
this pull request
Nov 16, 2015
Enforce linting via the test suite
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After many contributions, tldextract's feature set has largely solidified. However its code became a patchy mess. Not much left to do, except make tldextract a sterling work of art. 😉
One approach is to make sure the coding style is relatively uniform. So this PR adds the developer requirement of Pylint.
It has wide editor support. It has a nicely restrictive default set of rules, yet can be customized per folder. It detects code complexity. It can be invoked programmatically.
I found no off-the-shelf way to enforce linting across all a Python project's contributors. Local Git hooks have to be installed per person. Can't edit GitHub's remote Git hooks. Editor support has to be installed per person. What's the one thing left, that every contributor's code funnels through? CI.
This PR programmatically generates the tests for every Python lint error in the project. It relaxes some of Pylint's default rules. But it embraces most of them, and fixes the project's violations, making tldextract significantly more uniform and readable.
Limitations
Tasks
References