pylint
pylint copied to clipboard
pylint-dev
Refactors related to separating ast creating and linting
- [x] Add yourself to CONTRIBUTORS if you are a new contributor.
- [x] Write a good description on what the PR does.
Type of Changes
| Type | |
|---|---|
| ✓ | :hammer: Refactoring |
Description
Refs https://github.com/PyCQA/pylint/issues/7263.
Pull Request Test Coverage Report for Build 2856995021
- 9 of 9 (100.0%) changed or added relevant lines in 1 file are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage increased (+0.002%) to 95.245%
| Totals | |
|---|---|
| Change from base Build 2852974969: | 0.002% |
| Covered Lines: | 16844 |
| Relevant Lines: | 17685 |
💛 - Coveralls
🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉
This comment was generated for commit 00f65c2a9d5088f4e046867439cd342c05b6c393
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This would require another refactor but wouldn't it be a good thing to create à 'FileGatherer' class to have something testable and decoupled from the configuration in order to decrease the responsabilities of the PyLinter class ?
Wouldn't that be a bit overkill? I think it makes more sense to focus on creating a FileChecker which is a step somewhere in this refactoring process 😄
🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉
This comment was generated for commit 9461ce4a9cafb5caad2825a04b98bf51a0169bdf
I think it makes more sense to focus on creating a FileChecker which is a step somewhere in this refactoring process
I'm not opinionated about creating a particular class or about a particular design, you know this part of the code better than me so you'll know better than me what to do :)
But I think we need to be able to test those changes at some point, right now we need to test through the PyLinter which means it's hard and we don't. The core internal of pylint (like pylint.message, and some part of the PyLinter) should be unitary tested (well, unitary testable is a first step) .
I'm not opinionated about creating a particular class or about a particular design, you know this part of the code better than me so you'll know better than me what to do :)
That's not necessarily true 😅
But I think we need to be able to test those changes at some point, right now we need to test through the PyLinter which means it's hard and we don't. The core internal of pylint (like pylint.message, and some part of the PyLinter) should be unitary tested (well, unitary testable is a first step) .
Yeah agreed. For now I'd say let's merge this and #7288. That would definelty set us up for the creation of FileChecker or something like that.
Yeah agreed. For now I'd say let's merge this and https://github.com/PyCQA/pylint/pull/7288. That would definelty set us up for the creation of FileChecker or something like that.
👍
🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉
This comment was generated for commit b7fc900e9b65b9cabf04fd58b0795e26cc680ef6