chore: configure Black as the default Python code formatter #372
Conversation
WalkthroughThis set of changes updates code style and formatting configurations to enforce a line length of 88, adopts Black as the code formatter, and aligns related tooling and documentation. It modifies linting and CI workflows, VSCode settings, and the contributing guide. Code files are reformatted for consistency, with no changes to logic or public APIs. Changes
Possibly related PRs
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (4)
🧰 Additional context used🧬 Code Graph Analysis (1)routes/player_route.py (3)
🪛 Ruff (0.11.9)routes/player_route.py45-45: Do not perform function call (B008) 46-46: Do not perform function call (B008) 77-77: Do not perform function call (B008) 106-106: Do not perform function call (B008) 137-137: Do not perform function call (B008) 172-172: Do not perform function call (B008) 173-173: Do not perform function call (B008) 206-206: Do not perform function call (B008) ⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (11)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (3)
routes/health_route.py (1)
16-16:⚠️ Potential issueWrap docstring lines to respect 88-character limit
Current line exceeds the configured max line length (100 > 88), causing flake8 E501 failure.Please apply the following diff to split the text:
- Simple health check endpoint. Returns a JSON response with a single key "status" and value "ok". + Simple health check endpoint. Returns a JSON response with a single key "status" + and value "ok".🧰 Tools
🪛 GitHub Actions: Python CI
[error] 16-16: flake8 E501: line too long (100 > 88 characters)
services/player_service.py (2)
30-30:⚠️ Potential issueFix line length violation in docstring.
This line exceeds the 88-character limit (89 characters) and is causing pipeline failures. The docstring parameter description needs to be reformatted.
- player_model (PlayerModel): The Pydantic model representing the Player to create. + player_model (PlayerModel): The Pydantic model representing the Player to + create.🧰 Tools
🪛 GitHub Actions: Python CI
[error] 30-30: flake8 E501: line too long (89 > 88 characters)
110-110:⚠️ Potential issueFix line length violation in docstring.
This line exceeds the 88-character limit (89 characters) and is causing pipeline failures. The docstring parameter description needs to be reformatted.
- player_model (PlayerModel): The Pydantic model representing the Player to update. + player_model (PlayerModel): The Pydantic model representing the Player to + update.🧰 Tools
🪛 GitHub Actions: Python CI
[error] 110-110: flake8 E501: line too long (89 > 88 characters)
🧹 Nitpick comments (8)
routes/player_route.py (7)
45-47: Extract dependency defaults to module‐level constants.
Ruff B008 flags callingBody()andDepends()as defaults inside the signature.
Consider:-from fastapi import Body, Depends +from fastapi import Body, Depends +# move these out of the signature +_PLAYER_BODY = Body(...) +_SESSION_DEP = Depends(generate_async_session) async def post_async( - player_model: PlayerModel = Body(...), - async_session: AsyncSession = Depends(generate_async_session), + player_model: PlayerModel = _PLAYER_BODY, + async_session: AsyncSession = _SESSION_DEP, ):This removes function calls from default arguments.
🧰 Tools
🪛 Ruff (0.11.9)
45-45: Do not perform function call
Bodyin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
46-46: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
74-77: ExtractDepends()from signature forget_all_async.
Apply the same module‐level constant refactor for the session dependency.🧰 Tools
🪛 Ruff (0.11.9)
76-76: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
100-106: ExtractDepends()inget_by_id_async.
Use the same_SESSION_DEPconstant to satisfy Ruff B008.🧰 Tools
🪛 Ruff (0.11.9)
105-105: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
127-136: ExtractDepends()inget_by_squad_number_async.
Apply the module-level_SESSION_DEPfor consistency.🧰 Tools
🪛 Ruff (0.11.9)
135-135: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
161-170: Extract dependencies input_async.
Move bothBody(...)andDepends(...)calls to module constants.🧰 Tools
🪛 Ruff (0.11.9)
169-169: Do not perform function call
Bodyin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
170-170: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
193-202: ExtractDepends()indelete_async.
Refactor session dependency to_SESSION_DEP.🧰 Tools
🪛 Ruff (0.11.9)
201-201: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
1-118: Docstring line-length violations.
The CI reports multiple E501 errors (lines 52, 118, 148, 177, 181, 211) due to docstring lines exceeding 88 characters.
Please reflow long docstrings or add explicit# noqa: E501on those lines so that flake8 passes.🧰 Tools
🪛 Ruff (0.11.9)
45-45: Do not perform function call
Bodyin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
46-46: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
76-76: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
105-105: Do not perform function call
Dependsin argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable(B008)
🪛 GitHub Actions: Python CI
[error] 52-52: flake8 E501: line too long (89 > 88 characters)
[error] 118-118: flake8 E501: line too long (90 > 88 characters)
CONTRIBUTING.md (1)
13-16: Remove spaces inside code span elements for consistency
Per markdownlint MD038, avoid leading/trailing spaces inside backticks. Update these to`feat:`,`fix:`, and`chore:`.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
14-14: Spaces inside code span elements
null(MD038, no-space-in-code)
15-15: Spaces inside code span elements
null(MD038, no-space-in-code)
16-16: Spaces inside code span elements
null(MD038, no-space-in-code)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (16)
.flake8(1 hunks).github/workflows/python-app.yml(3 hunks).vscode/extensions.json(1 hunks).vscode/settings.json(1 hunks)CONTRIBUTING.md(1 hunks)databases/player_database.py(2 hunks)main.py(3 hunks)models/player_model.py(3 hunks)pyproject.toml(1 hunks)requirements-lint.txt(1 hunks)routes/health_route.py(1 hunks)routes/player_route.py(9 hunks)schemas/player_schema.py(2 hunks)services/player_service.py(5 hunks)tests/player_stub.py(2 hunks)tests/test_main.py(16 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
routes/player_route.py (3)
models/player_model.py (1)
PlayerModel(32-60)databases/player_database.py (1)
generate_async_session(35-43)services/player_service.py (2)
retrieve_by_squad_number_async(82-98)delete_async(139-158)
tests/test_main.py (2)
tests/player_stub.py (3)
existing_player(33-49)nonexistent_player(52-68)unknown_player(71-81)tests/conftest.py (1)
client(11-22)
🪛 GitHub Actions: Python CI
routes/health_route.py
[error] 16-16: flake8 E501: line too long (100 > 88 characters)
models/player_model.py
[error] 26-26: flake8 E501: line too long (100 > 88 characters)
[error] 44-44: flake8 E501: line too long (93 > 88 characters)
[error] 47-47: flake8 E501: line too long (96 > 88 characters)
routes/player_route.py
[error] 52-52: flake8 E501: line too long (89 > 88 characters)
[error] 118-118: flake8 E501: line too long (90 > 88 characters)
[error] 148-148: flake8 E501: line too long (109 > 88 characters)
[error] 177-177: flake8 E501: line too long (89 > 88 characters)
[error] 181-181: flake8 E501: line too long (99 > 88 characters)
[error] 211-211: flake8 E501: line too long (99 > 88 characters)
services/player_service.py
[error] 30-30: flake8 E501: line too long (89 > 88 characters)
[error] 110-110: flake8 E501: line too long (89 > 88 characters)
🪛 Ruff (0.11.9)
routes/player_route.py
45-45: Do not perform function call Body in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable
(B008)
46-46: Do not perform function call Depends in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable
(B008)
76-76: Do not perform function call Depends in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable
(B008)
105-105: Do not perform function call Depends in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable
(B008)
135-135: Do not perform function call Depends in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable
(B008)
169-169: Do not perform function call Body in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable
(B008)
170-170: Do not perform function call Depends in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable
(B008)
201-201: Do not perform function call Depends in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable
(B008)
🪛 markdownlint-cli2 (0.17.2)
CONTRIBUTING.md
14-14: Spaces inside code span elements
null
(MD038, no-space-in-code)
15-15: Spaces inside code span elements
null
(MD038, no-space-in-code)
16-16: Spaces inside code span elements
null
(MD038, no-space-in-code)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (55)
requirements-lint.txt (1)
2-2: Add Black to linting requirements
Includingblack==25.1.0alongsideflake8ensures code formatting consistency with Black across the project.databases/player_database.py (3)
11-11: Insert blank line after module docstring
Adding a blank line improves readability and conforms to PEP 257/Black formatting style.
24-26: Reformatcreate_async_enginecall
Switching to a single-line argument style aligns with Black's default formatting.
28-30: Reformatsessionmakerinvocation
Adopting single-line parameters matches the project’s Black-enforced style.models/player_model.py (2)
9-9: Add blank line after module docstring
This aligns spacing with Black's formatting conventions.
28-28: Add blank line beforemodel_config
Improves readability and maintains consistency in class formatting.routes/health_route.py (2)
7-7: Add blank line after module docstring
Conforms to the repository’s Black-driven spacing conventions.
12-12: Add blank line after router declaration
Improves separation between imports, router setup, and endpoint definitions..vscode/extensions.json (1)
5-5: Recommend Black formatter extension
Adding"ms-python.black-formatter"ensures the team can easily adopt Black in VSCode..vscode/settings.json (2)
10-11: Set editor wrap and ruler at 88 characters.
This aligns your VSCode environment with Black’s default maximum line length.
13-14: Switch default Python formatter to Black.
Usingms-python.black-formatterwith format-on-save ensures consistent formatting across the team.tests/player_stub.py (2)
18-18: Add trailing comma for consistency.
The added comma afterstarting11=Nonealigns with Black’s preferred trailing-comma style.
80-80: Add trailing comma afterposition.
Ensures the function call inunknown_player()follows Black’s multi-line comma convention.main.py (3)
10-10: Insert blank line after module docstring.
This blank line improves separation between the docstring and imports per PEP 8.
21-21: Add blank line before@asynccontextmanager.
Enhances readability by visually separating imports from the decorator.
31-36: ReformatFastAPIinstantiation into a multi-line call.
This styling change improves readability without altering behavior.routes/player_route.py (2)
42-43: Approve added cache TTL constant.
DefiningCACHE_TTL = 600(10 minutes) is clear and readable.
42-42: Approve addedtags=["Players"].
Consistent tagging on each route helps with OpenAPI organization.pyproject.toml (2)
1-4: Add Black configuration section.
Defines a line length of 88, applies to.py/.pyifiles, and targets Python 3.13.
3-3:Details
✅ Verification successful
Verify Black’s
target-versionsupport.
Ensure that specifying'py313'is recognized by the Black version in CI and locally.
🌐 Web query:
Does Black support specifying 'py313' in the `target-version` setting of `pyproject.toml`?💡 Result:
As of Black version 23.1.0, released in January 2023, the
--target-versionoption in thepyproject.tomlconfiguration file accepts Python version identifiers in the formatpyXY, whereXandYrepresent the major and minor version numbers, respectively. (ichard26.github.io)Therefore, specifying
py313in thetarget-versionsetting of yourpyproject.tomlfile is valid and will configure Black to format code compatible with Python 3.13.For example, your
pyproject.tomlfile would include:[tool.black] target-version = ['py313']This configuration ensures that Black formats your code to be compatible with Python 3.13 syntax and features.
Citations:
Confirm Black’s
py313target-version support
Specifying[tool.black] target-version = ['py313']is valid in Black v23.1.0+ and will format code for Python 3.13. No further changes required.
schemas/player_schema.py (1)
34-40: LGTM! String formatting aligns with Black standards.The changes from single quotes to double quotes in SQLAlchemy column name parameters are purely stylistic and align with Black's formatting preferences. No functional changes were made.
.github/workflows/python-app.yml (3)
34-34: Good improvement to step naming clarity.Renaming the step to "Install lint dependencies" improves workflow readability and clearly distinguishes between different dependency types.
43-45: Excellent addition of Black formatting enforcement.Adding the Black formatting check to the CI pipeline ensures code consistency. Using
black --check .is the correct approach for CI environments as it will fail the build if formatting issues are detected.
60-60: Good improvement to step naming clarity.Renaming the step to "Install test dependencies" improves workflow readability and clearly distinguishes between different dependency types.
.flake8 (1)
2-7: Excellent flake8 configuration for Black integration.The configuration changes properly align flake8 with Black formatting standards:
max-line-length = 88matches Black's defaultselect = E,F,Wenables comprehensive lintingextend-ignore = E203, W503are standard Black compatibility ignores- Per-file ignore for tests allows reasonable flexibility
These are industry best practices for Black + flake8 integration.
services/player_service.py (2)
14-14: Good formatting improvement.Adding blank lines after docstrings aligns with Black formatting standards and improves readability.
82-84: Good multi-line function signature formatting.Breaking the function signature across multiple lines improves readability and aligns with Black's formatting for long function signatures.
CONTRIBUTING.md (9)
19-20: Approve logical commits guidance
The wording succinctly emphasizes grouping by purpose and squashing noise.
21-30: Approve Python formatting & style section
Clear instructions on using Black (88-char line length), flake8, and Python 3.13.x are correctly aligned with the project configuration.
31-33: Approve testing instructions
Explicitly running pytest and enforcing coverage non-regression matches CI requirements.
38-38: Approve rebase/squash guidance
Rebasing or squashing before opening keeps history clean.
40-42: Approve PR title & description guidelines
Conventional Commit format and concise “what & why” instructions are on point.
45-47: Approve issue reporting improvements
Encouraging search, clear repro steps, and focused issues is beneficial.
51-58: Approve automation & checks section
Listing commitlint, Black, flake8, and pytest ensures contributors know CI expectations.
62-63: Approve Code of Conduct & support section
References to CODE_OF_CONDUCT.md and discussion etiquette are clear.
65-67: Approve closing remarks
The separator and thank-you note effectively wrap up the guidelines.tests/test_main.py (19)
27-35: Consistent test naming and docstring style
Alltest_given_*functions and theirGiven/when/thendocstrings follow the project’s concise style conventions.
45-52: Approve GET /players/ initial request test rename
The function name and docstring have been updated for clarity and consistency.
61-67: Approve GET /players/ subsequent request test rename
Naming and docstring changes correctly reflect the scenario.
78-84: Approve GET /players/ no-ID status code test rename
The updated identifier and docstring align with the style guide.
92-98: Approve GET /players/ no-ID body test rename
Renaming improves readability without altering logic.
113-119: Approve GET nonexistent ID status code test rename
Consistent naming and concise docstring.
129-135: Approve GET existing ID status code test rename
Function name and docstring updates are spot on.
145-151: Approve GET existing ID body test rename
Clarity in naming/documentation enhances maintainability.
165-171: Approve GET nonexistent squad number status code test rename
Renamed identifier and docstring match project conventions.
181-187: Approve GET existing squad number status code test rename
Docstring and name are concise and clear.
197-203: Approve GET existing squad number body test rename
Naming consistency maintained.
217-223: Approve POST empty body status code test rename
Updated naming/docstring correctly reflect the test.
233-239: Approve POST existing player conflict test rename
The concise style is consistently applied.
250-256: Approve POST new player created test rename
Function name and docstring are improved for readability.
270-276: Approve PUT empty body status code test rename
Naming and docstring are aligned with guidelines.
287-293: Approve PUT unknown ID status code test rename
Clear and consistent naming/documentation.
305-311: Approve PUT existing ID no-content test rename
Maintains the concise Given/when/then pattern.
328-334: Approve DELETE unknown ID status code test rename
The update follows style conventions perfectly.
344-350: Approve DELETE existing ID no-content test rename
Function and docstring changes are consistent and clear.
nanotaboada
force-pushed
the
feature/black
branch
from
244f06a to
cc61d5a
Compare
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #372 +/- ##
=======================================
Coverage 89.65% 89.65%
=======================================
Files 3 3
Lines 116 116
=======================================
Hits 104 104
Misses 12 12
🚀 New features to boost your workflow:
|
This change is
Summary by CodeRabbit
New Features
Style
Documentation
Tests