-
-
Notifications
You must be signed in to change notification settings - Fork 94
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
feat: use ruff #275
feat: use ruff #275
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR Type: Refactoring
PR Summary: The pull request introduces several changes aimed at modernizing the codebase and improving readability. It includes the use of Python's future annotations for type hinting, adopting a more consistent documentation style across different modules, and refining the structure of various classes and methods. Additionally, the PR incorporates error handling improvements by refactoring error messages into separate variables before raising exceptions. These changes are spread across multiple files within the project, including core modules and test suites.
Decision: Comment
📝 Type: 'Refactoring' - not supported yet.
- Sourcery currently only approves 'Typo fix' PRs.
✅ Issue addressed: this change correctly addresses the issue or implements the desired feature.
No details provided.
📝 Complexity: the changes are too large or complex for Sourcery to approve.
- Unsupported files: the diff contains files that Sourcery does not currently support during reviews.
- Big diff: the diff is too large to approve with confidence.
General suggestions:
- Consider verifying the consistency of documentation across the entire codebase to match the newly adopted style for improved readability.
- Review the use of type hinting across all modules to ensure it aligns with the changes introduced in this PR, leveraging Python's future annotations where applicable.
- Evaluate the error handling strategy across the project to ensure that error messages are consistently managed and provide clear, actionable information to the users.
Thanks for using Sourcery. We offer it for free for open source projects and would be very grateful if you could help us grow. If you like it, would you consider sharing Sourcery on your favourite social media? ✨
master_doc = "index" | ||
|
||
# General information about the project. | ||
project = "Python MSS" | ||
copyright = f"{__date__}, {__author__} & contributors" | ||
author = "Tiger-222" | ||
copyright = f"{mss.__date__}, {mss.__author__} & contributors" # noqa:A001 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue (rule): Sourcery has identified the following issue:
- Don't assign to builtin variable
copyright
(avoid-builtin-shadow
)
Explanation
Python has a number ofbuiltin
variables: functions and constants thatform a part of the language, such as
list
, getattr
, and type
(See https://docs.python.org/3/library/functions.html).
It is valid, in the language, to re-bind such variables:
list = [1, 2, 3]
However, this is considered poor practice.
- It will confuse other developers.
- It will confuse syntax highlighters and linters.
- It means you can no longer use that builtin for its original purpose.
How can you solve this?
Rename the variable something more specific, such as integers
.
In a pinch, my_list
and similar names are colloquially-recognized
placeholders.
with pytest.raises(ScreenShotError): | ||
mss.mss() | ||
monkeypatch.undo() | ||
|
||
with mss.mss() as sct: | ||
assert isinstance(sct, mss.darwin.MSS) # For Mypy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue (rule): Sourcery has identified the following issue:
- Extract code out into function (
extract-method
)
dd7e10d
to
8a1ec3b
Compare
No description provided.