Skip to content

Conversation

@echarrod
Copy link
Contributor

@echarrod echarrod commented Oct 23, 2025

Summary

  • Add module docstrings to all Python files for better documentation
  • Add class and method docstrings where missing
  • Fix docstring formatting to use imperative mood and proper punctuation
  • Remove unused imports (requests, six)
  • Improve test error matching with pytest.raises match parameter
  • Configure bandit to skip B107 for empty credential defaults (legitimate use case)
  • All pre-commit hooks now pass successfully

Summary by CodeRabbit

  • Documentation

    • Added and improved module, class and method docstrings across the SDK and example scripts to improve clarity and usage guidance.
  • Chores

    • SDK version bumped to 0.0.10.
    • Security tooling configuration updated with additional rule exclusions.
  • Tests

    • Test docstrings enhanced.
    • Test assertions tightened to validate specific error behaviour.

- Add module docstrings to all Python files
- Add class and method docstrings where missing
- Fix docstring formatting (imperative mood, periods)
- Remove unused imports
- Improve test error matching with pytest.raises
- Configure bandit to skip B107 for empty credential defaults
- All pre-commit hooks now pass

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@coderabbitai
Copy link

coderabbitai bot commented Oct 23, 2025

Walkthrough

This pull request adds or refines documentation across the repository: module, class and method docstrings were added to several files (examples/readonly.py, luno_python/init.py, luno_python/base_client.py, luno_python/client.py, luno_python/error.py, setup.py, tests/init.py, tests/test_client.py). A public constant VERSION = "0.0.10" was introduced in luno_python/init.py. A minor refactor adjusts error-message formatting in base_client. Tests tighten an exception match in test_client_do_basic. pyproject.toml updates Bandit skips to include B107.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Changes are largely repetitive documentation edits with a few small, isolated functional tweaks (VERSION addition, minor error-message refactor, tightened test assertion, Bandit config). Verification is straightforward and low complexity.

Poem

🐰
I hopped through docs with ink and cheer,
Added lines so purpose’s clear,
A VERSION tucked in, tests refined,
A tiny tweak to errors signed,
Hooray — the README garden’s near! 🌷

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The pull request title "precommit: Fix all pre-commit violations" is directly aligned with the main objective and changeset of this PR. The changes across all modified files—including the addition of module, class, and method docstrings to multiple Python files, adjustments to docstring formatting for imperative mood compliance, configuration of Bandit to skip B107, and improvements to test error matching—are all concrete steps taken to resolve pre-commit hook violations. The title is concise, clear, and uses specific descriptive language that accurately conveys the primary purpose of the changeset without vague terminology.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch edharrod-precommit-fixes

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1aec6cd and d3fefc2.

📒 Files selected for processing (9)
  • examples/readonly.py (1 hunks)
  • luno_python/__init__.py (1 hunks)
  • luno_python/base_client.py (9 hunks)
  • luno_python/client.py (47 hunks)
  • luno_python/error.py (1 hunks)
  • pyproject.toml (1 hunks)
  • setup.py (1 hunks)
  • tests/__init__.py (1 hunks)
  • tests/test_client.py (10 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
luno_python/client.py

📄 CodeRabbit inference engine (AGENTS.md)

luno_python/client.py: For API methods in luno_python/client.py, follow the existing docstring format including HTTP method, path, permissions, and parameter descriptions.
Each API method in luno_python/client.py must construct a req dict with parameters and call self.do() to perform the HTTP request.
Use ":type param: type_name" style type hints in docstrings for API methods to maintain Python 2 compatibility.
Use {param_name} syntax for path parameters in endpoint paths within API method definitions.
For GET requests, pass query parameters via the params field of the request.

Files:

  • luno_python/client.py
tests/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

Use requests_mock for HTTP mocking in tests: mount the adapter on the session and register URIs with adapter.register_uri(...).

Files:

  • tests/test_client.py
  • tests/__init__.py
luno_python/base_client.py

📄 CodeRabbit inference engine (AGENTS.md)

luno_python/base_client.py: Authenticate requests using HTTP Basic Auth with api_key_id and api_key_secret in the BaseClient.
In BaseClient.do(), parse JSON responses and raise APIError when the API returns an error_code/error.

Files:

  • luno_python/base_client.py
🧠 Learnings (3)
📚 Learning: 2025-10-23T11:07:39.162Z
Learnt from: CR
PR: luno/luno-python#0
File: AGENTS.md:0-0
Timestamp: 2025-10-23T11:07:39.162Z
Learning: Applies to luno_python/client.py : For API methods in luno_python/client.py, follow the existing docstring format including HTTP method, path, permissions, and parameter descriptions.

Applied to files:

  • luno_python/client.py
  • luno_python/base_client.py
📚 Learning: 2025-10-23T11:07:39.162Z
Learnt from: CR
PR: luno/luno-python#0
File: AGENTS.md:0-0
Timestamp: 2025-10-23T11:07:39.162Z
Learning: Applies to luno_python/base_client.py : Authenticate requests using HTTP Basic Auth with api_key_id and api_key_secret in the BaseClient.

Applied to files:

  • luno_python/base_client.py
📚 Learning: 2025-10-23T11:07:39.162Z
Learnt from: CR
PR: luno/luno-python#0
File: AGENTS.md:0-0
Timestamp: 2025-10-23T11:07:39.162Z
Learning: Applies to luno_python/client.py : Each API method in luno_python/client.py must construct a req dict with parameters and call self.do() to perform the HTTP request.

Applied to files:

  • luno_python/base_client.py
🧬 Code graph analysis (1)
tests/test_client.py (1)
luno_python/base_client.py (1)
  • set_base_url (49-56)
🔇 Additional comments (25)
luno_python/__init__.py (1)

1-3: LGTM!

The module docstring is clear and concise, and the VERSION constant provides appropriate package metadata.

pyproject.toml (1)

23-26: LGTM!

The addition of B107 to the Bandit skips is appropriate for this SDK, where empty string defaults for optional credentials are a legitimate pattern. The inline comment clearly explains the rationale.

tests/__init__.py (1)

1-1: LGTM!

The module docstring appropriately identifies the test package.

setup.py (1)

1-2: LGTM!

The module docstring appropriately describes the setup script.

examples/readonly.py (1)

1-2: LGTM!

The module docstring clearly describes the purpose of this example script.

luno_python/base_client.py (4)

1-24: LGTM!

The module and class docstrings are clear and follow the imperative mood style consistently.


27-66: LGTM!

The method docstrings are clear and consistently formatted using imperative mood. The parameter type documentation is well-maintained.


68-98: LGTM!

The docstring update for the do method is clear. The error message formatting change on lines 83-84 improves readability without altering functionality.


100-115: LGTM!

The method docstrings are clear and include appropriate return type documentation.

luno_python/client.py (5)

1-21: LGTM!

The module docstring appropriately describes the client implementation.


23-150: LGTM!

The docstring updates consistently use imperative mood ("Make a call" instead of "Makes a call") and maintain proper formatting. All parameter descriptions and permissions are well-documented.


152-418: LGTM!

The docstring updates are consistent and well-formatted. API method documentation includes appropriate HTTP method, path, permissions, and parameter descriptions as per the coding guidelines.


420-681: LGTM!

The docstring improvements maintain consistency across all API methods. The documentation clearly describes each endpoint's purpose, parameters, and requirements.


683-1152: LGTM!

The docstring updates consistently apply imperative mood and maintain comprehensive documentation for all API methods, including complex parameter descriptions.

tests/test_client.py (11)

1-2: LGTM!

The module docstring clearly identifies the test module's purpose.


86-97: LGTM!

The test docstring clearly describes the test's purpose.


99-123: LGTM!

The test docstring is clear, and the addition of match="unknown API error" on line 108 improves test precision by verifying the exact exception message.


125-140: LGTM!

The test docstring clearly describes the backward compatibility test case.


142-173: LGTM!

The test docstring appropriately describes the account_id filtering functionality.


175-188: LGTM!

The test docstring clearly indicates the expected behaviour for invalid account IDs.


190-210: LGTM!

The test docstring clearly describes the multiple parameter test case.


212-232: LGTM!

The test docstring appropriately describes the type conversion handling.


234-251: LGTM!

The test docstring clearly describes the empty response edge case.


253-270: LGTM!

The test docstring appropriately describes the malformed response handling.


272-295: LGTM!

The test validates proper error handling for non-JSON-serializable parameters, ensuring the improved error message from base_client.py is correctly surfaced.

@sonarqubecloud
Copy link

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
luno_python/error.py (1)

8-14: Method docstring is well-documented and addresses previous feedback.

The docstring now includes both parameter descriptions and type annotations using RST-style format, which aligns with codebase conventions. The previous review comment requesting type annotations has been addressed.

Consider calling super().__init__() to follow Python best practices for exception classes:

     def __init__(self, code, message):
         """Initialise APIError with code and message.
 
         :param code: Error code from the API
         :type code: str
         :param message: Error message from the API
         :type message: str
         """
+        super().__init__(message)
         self.code = code
         self.message = message
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d3fefc2 and eb0e58f.

📒 Files selected for processing (1)
  • luno_python/error.py (1 hunks)
🔇 Additional comments (2)
luno_python/error.py (2)

1-2: Module docstring is clear and well-formatted.

The module-level documentation is concise, follows PEP 257 conventions, and accurately describes the module's purpose.


5-6: Class docstring is clear and follows conventions.

The class documentation accurately describes the exception's purpose and follows PEP 257 conventions.

@echarrod echarrod merged commit 33f1933 into main Oct 24, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants