proper type annotation #409
Conversation
WalkthroughThe changes across various files in the The modifications streamline the return types by allowing methods to return their results directly from internal method calls without explicit type casting. This includes methods such as In the Lastly, in the test file Possibly related PRs
TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #409 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 49 49
Lines 1111 1101 -10
=========================================
- Hits 1111 1101 -10
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Sentry.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 24
Outside diff range comments (9)
cuenca/resources/user_credentials.py (1)
Line range hint
1-43: Summary: Improved type handling and code simplicityThe changes in this file align well with the PR objective of proper type annotation. By removing the
castcalls in bothcreateandupdatemethods, the code becomes more straightforward while maintaining type safety through the existing type annotations.These modifications:
- Simplify the code by removing redundant type casting.
- Rely on the correct return types of the underlying
_createand_updatemethods.- Maintain the existing type annotations, which provide clear type information.
To further improve type safety and code clarity:
- Consider adding type annotations to the
_createand_updatemethods if they don't already have them.- If not already present, add a
__init__method with type annotations for all attributes of theUserCredentialclass.- Consider using
from __future__ import annotationsat the top of the file to enable postponed evaluation of annotations, which can help with circular dependencies and improve readability.These suggestions will enhance the overall type safety and readability of the
UserCredentialclass.cuenca/resources/kyc_validations.py (1)
Line range hint
26-41: LGTM: Improved type annotation in thecreatemethod.The removal of the
castfunction simplifies the code while maintaining type safety through the method's return type annotation. This change aligns well with the PR objective of proper type annotation.For even better clarity, consider adding a type annotation to the
_createmethod if it doesn't already have one. This would make the type consistency more explicit throughout the class. For example:@classmethod def _create(cls, *args, **kwargs) -> 'KYCValidation': # implementationThis ensures that
_createexplicitly declares its return type, matching the annotation in thecreatemethod.cuenca/resources/card_activations.py (1)
Line range hint
52-56: Consider removingcastfrom thecardproperty for consistencyFor consistency with the change made in the
createmethod, consider removing thecastfunction from thecardproperty. The type annotation on the property should be sufficient for type checking.Here's a suggested change:
@property def card(self) -> Optional[Card]: result = None if self.card_uri: - result = cast(Card, retrieve_uri(self.card_uri)) + result = retrieve_uri(self.card_uri) return resultThis change maintains the correct type annotation while simplifying the code.
Tools
Ruff
48-48: Missing type annotation for
selfin method(ANN101)
cuenca/resources/user_logins.py (1)
Line range hint
1-48: Suggest consistent use of actual types for annotations.To improve type hinting consistency and provide better IDE support, consider using actual types instead of string literals for type annotations throughout the file. This aligns with the PR objective of proper type annotation.
Apply the following changes:
- Update the
createmethod's return type annotation:- ) -> 'UserLogin': + ) -> UserLogin:
- If there are any other occurrences of string literal type annotations in the file (e.g., in base classes or other methods not shown in this diff), update them similarly.
These changes will make the type annotations more consistent and easier for static type checkers and IDEs to process.
cuenca/resources/kyc_verifications.py (1)
Line range hint
45-51: Approved: Removal of redundant type casting and suggestion for consistencyThe removal of the
castfunction from the return statement is a good improvement. This change:
- Simplifies the code.
- Relies on the existing return type hint
-> 'KYCVerification'for type checking.- Aligns with the PR objective of "proper type annotation".
The
_updatemethod (likely defined in theUpdateableparent class) should already return an instance ofKYCVerification, making the explicit cast unnecessary.For consistency with the
createmethod, consider moving the return statement to a single line:- req = KYCVerificationUpdateRequest(curp=curp) - return cls._update(id=kyc_id, **req.dict()) + return cls._update(id=kyc_id, **KYCVerificationUpdateRequest(curp=curp).dict())This change would make both methods more consistent in their implementation style.
cuenca/resources/api_keys.py (1)
Incomplete Removal of
castFunction DetectedThe verification script identified multiple instances of the
castfunction remaining in the codebase outside ofcuenca/resources/api_keys.py. These residual usages indicate that the removal ofcastis not yet comprehensive and may require additional updates to ensure consistency and prevent potential type-related issues.Files with remaining
castusages:
cuenca/resources/base.pycuenca/resources/users.pycuenca/resources/wallet_transactions.pycuenca/resources/transfers.pycuenca/resources/card_activations.pycuenca/resources/whatsapp_transfers.pycuenca/resources/otps.pycuenca/resources/card_validations.pycuenca/resources/card_transactions.pycuenca/resources/bill_payments.pycuenca/resources/commissions.pycuenca/resources/deposits.pycuenca/resources/balance_entries.pycuenca/__init__.pyAdditionally, several methods continue to use string literal type annotations, which may need review to maintain consistency across the codebase.
Analysis chain
Line range hint
39-77: Verify the impact of removingcaston the broader codebase.The consistent removal of the
castfunction across all methods suggests a broader change in the codebase, possibly in the base classes or the API response handling. While these changes simplify the code and remove unnecessary type casting, it's important to ensure that this doesn't introduce any unintended side effects.To verify the impact of these changes, please run the following script:
This script will help identify:
- Any remaining usages of the
castfunction that might need similar updates.- The return types of
_createand_updatemethods in base classes to ensure they align with these changes.- Other classes using string literal type annotations, to consider a consistent approach across the codebase.
Please review the results and consider updating other parts of the codebase if necessary to maintain consistency.
Adjust Verification Scripts to Correctly Target Python Files
The previous scripts encountered issues due to the unsupported
--type pythonoption inrg. To effectively verify the impact of removingcast, please run the following updated script:This script has been adjusted to:
- Use Glob Patterns with
rg: Replaced the--type pythonflag with-g "*.py"to correctly target Python files.- Exclude Specific Files Appropriately: Ensured that the
cuenca/resources/api_keys.pyfile is excluded from thecastfunction search.- Refine
ast-grepPatterns: Simplified the patterns to more accurately match class and method definitions without unnecessary complexity.Please execute this script and provide the output for further analysis.
Correcting Verification Scripts for Accurate Results
The previous scripts encountered issues due to incorrect usage of
rgoptions and malformedast-greppatterns. Please run the following updated script to accurately verify the impact of removingcast:This script includes the following corrections:
Proper File Exclusion with
rg:
- Replaced the incorrect
--ignore-fileoption with-g "!cuenca/resources/api_keys.py"to exclude the specified file from the search.Refined
ast-grepPatterns:
- Corrected the patterns to accurately match classes inheriting from
CreatableandUpdateable, and their respective_createand_updatemethods.- Ensured that the patterns are syntactically correct and do not include any extraneous text.
Enhanced Readability and Separation:
- Added distinct echo statements for each
ast-greptest to improve clarity in the output.Please execute this updated script and provide the output for further analysis.
Refining Verification Scripts to Resolve Pattern Errors
The previous script encountered syntax errors with
ast-grepdue to malformed patterns. To accurately verify the return types of_createand_updatemethods inCreatableandUpdateableclasses, please run the following updated script:This updated script includes the following corrections:
Corrected
ast-grepPatterns:
- Removed unintended text from the patterns to ensure valid syntax.
- Accurately matches classes inheriting from
CreatableandUpdateable, along with their_createand_updatemethods.Separated Tests for Clarity:
- Added distinct echo statements for each
ast-greptest to improve output readability.Please execute this updated script and provide the output for further analysis.
Fixing Shell Script Patterns for Accurate Verification
The previous shell scripts encountered issues with the
ast-greppatterns, causing syntax errors. To accurately verify the return types of_createand_updatemethods inCreatableandUpdateableclasses, please run the following updated script:Corrections Made:
Corrected
ast-grepPatterns:
- Removed all unintended text from the patterns to ensure they are valid.
- Ensured that the patterns accurately match classes inheriting from
CreatableandUpdateable, along with their respective_createand_updatemethods.- Used single quotes for the
ast-greppatterns to prevent shell interpretation issues.Shell Script Syntax:
- Ensured that each
ast-greppattern is enclosed within single quotes.- Removed any trailing periods or characters that may cause syntax errors.
Maintained Test Separation:
- Kept each test distinct with clear echo statements for better readability of the output.
Please execute this updated script and provide the output for further analysis.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other usages of 'cast' function in the codebase and verify the return types of base class methods. # Test 1: Search for other usages of 'cast' function echo "Searching for other usages of 'cast' function:" rg --type python "cast\(" -g '!cuenca/resources/api_keys.py' # Test 2: Check the return types of _create and _update methods in base classes echo "Checking return types of _create and _update methods in base classes:" ast-grep --lang python --pattern $'class $CLASS(Creatable): $$$ def _create($$$): $$$ return $_' ast-grep --lang python --pattern $'class $CLASS(Updateable): $$$ def _update($$$): $$$ return $_' # Test 3: Search for other classes using string literal type annotations echo "Searching for other classes using string literal type annotations:" rg --type python "def \w+\(.*\) -> '[A-Z]\w+'"Length of output: 801
Script:
#!/bin/bash # Description: Check for other usages of 'cast' function in the codebase and verify the return types of base class methods. # Test 1: Search for other usages of 'cast' function echo "Searching for other usages of 'cast' function:" rg "cast\(" -g "*.py" --ignore-file cuenca/resources/api_keys.py # Test 2: Check the return types of _create and _update methods in base classes echo "Checking return types of _create and _update methods in base classes:" ast-grep --lang python --pattern "class $_(Creatable): $$ def _create($_): $$ return $_" ast-grep --lang python --pattern "class $_(Updateable): $$ def _update($_): $$ return $_" # Test 3: Search for other classes using string literal type annotations echo "Searching for other classes using string literal type annotations:" rg "def \w+\(.*\) -> '[A-Z]\w+'" -g "*.py"Length of output: 6586
Script:
#!/bin/bash # Description: Check for other usages of 'cast' function in the codebase and verify the return types of base class methods. # Test 1: Search for other usages of 'cast' function, excluding 'cuenca/resources/api_keys.py' echo "Searching for other usages of 'cast' function:" rg "cast\(" -g "*.py" -g "!cuenca/resources/api_keys.py" # Test 2: Check the return types of _create and _update methods in base classes echo "Checking return types of _create methods in Creatable classes:" ast-grep --lang python --pattern "class $_(Creatable): $$ def _create($_): $$ return $_" . echo "Checking return types of _update methods in Updateable classes:" ast-grep --lang python --pattern "class $_(Updateable): $$ def _update($_): $$ return $_" . # Test 3: Search for other classes using string literal type annotations echo "Searching for other classes using string literal type annotations:" rg "def \w+\(.*\) -> '[A-Z]\w+'" -g "*.py"Length of output: 5027
Script:
#!/bin/bash # Description: Check for other usages of 'cast' function in the codebase and verify the return types of base class methods. # Test 1: Search for other usages of 'cast' function, excluding 'cuenca/resources/api_keys.py' echo "Searching for other usages of 'cast' function:" rg "cast\(" -g "*.py" -g "!cuenca/resources/api_keys.py" # Test 2: Check the return types of _create methods in Creatable classes echo "Checking return types of _create methods in Creatable classes:" ast-grep --lang python --pattern "class $_(Creatable): $$ def _create($_): $$ return $_" . # Test 3: Check the return types of _update methods in Updateable classes echo "Checking return types of _update methods in Updateable classes:" ast-grep --lang python --pattern "class $_(Updateable): $$ def _update($_): $$ return $_" . # Test 4: Search for other classes using string literal type annotations echo "Searching for other classes using string literal type annotations:" rg "def \w+\(.*\) -> '[A-Z]\w+'" -g "*.py"Length of output: 5027
Script:
#!/bin/bash # Description: Check for other usages of 'cast' function in the codebase and verify the return types of base class methods. # Test 1: Search for other usages of 'cast' function, excluding 'cuenca/resources/api_keys.py' echo "Searching for other usages of 'cast' function:" rg "cast\(" -g "*.py" -g "!cuenca/resources/api_keys.py" # Test 2: Check the return types of _create methods in Creatable classes echo "Checking return types of _create methods in Creatable classes:" ast-grep --lang python --pattern 'class $_(Creatable): $$ def _create($_): $$ return $_' . # Test 3: Check the return types of _update methods in Updateable classes echo "Checking return types of _update methods in Updateable classes:" ast-grep --lang python --pattern 'class $_(Updateable): $$ def _update($_): $$ return $_' . # Test 4: Search for other classes using string literal type annotations echo "Searching for other classes using string literal type annotations:" rg "def \w+\(.*\) -> '[A-Z]\w+'" -g "*.py"Length of output: 3276
Tools
Ruff
57-57: Unnecessary
dictcall (rewrite as a literal)Rewrite as a literal
(C408)
cuenca/resources/transfers.py (2)
Line range hint
78-86: Consider consistent type handling increate_manymethodWhile reviewing the changes in the
createmethod, I noticed that thecreate_manymethod still usescast('Transfer', transfer)on line 85. For consistency with the changes made to thecreatemethod, consider reviewing this usage as well.If the decision is to remove
castfor improved code clarity, you might want to apply the same change here. However, ifcastis deemed necessary for type safety, it might be worth reconsidering its removal in thecreatemethod.If you decide to remove the cast, the line could be changed to:
transfers['submitted'].append(transfer)Please ensure that this change, if made, doesn't impact type safety or the overall objective of proper type annotation.
Tools
Ruff
75-75: Missing type annotation for
clsin classmethod(ANN102)
Line range hint
1-99: Overall type annotation usageThe file generally makes good use of type annotations, which aligns with the PR objective of "proper type annotation". However, the inconsistent use of
cast(removed increatebut retained increate_many) might need attention.Consider the following points for improving type annotations throughout the file:
- Consistency: Ensure consistent use of type casting and annotations across similar methods.
- Return types: Verify that all method return types are explicitly annotated, especially for public methods.
- Variable annotations: Consider adding type annotations to local variables where their types might not be obvious.
- Use of
Optional: The file correctly usesOptionalfor parameters that can be None. Ensure this is consistently applied.To maintain and improve type safety, consider using a static type checker like mypy in your development process. This can help catch type-related issues early and ensure consistency in type annotations across the codebase.
Tools
Ruff
75-75: Missing type annotation for
clsin classmethod(ANN102)
cuenca/resources/users.py (1)
Line range hint
1-177: Summary: Improved type annotations and removed redundant castsThe changes in this file consistently remove unnecessary type casting, which aligns well with the PR objective of proper type annotation. This improves code clarity and reduces redundancy. Here's a summary of the improvements:
- Removed redundant
cast()in thebalanceproperty.- Removed redundant
cast()in thecreateclass method.- Removed redundant
cast()in theupdateclass method.These changes enhance the code quality by relying on the correct types returned by the methods rather than using explicit casts. To further improve the code, consider implementing the suggested type annotation improvements in the previous comments.
As a general recommendation, continue to review and improve type annotations throughout the codebase. This will enhance type safety, improve IDE support, and make the code more self-documenting. Consider using tools like mypy for static type checking to catch any potential type-related issues early in the development process.
Tools
Ruff
61-61: Missing type annotation for
selfin method(ANN101)
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (28)
- cuenca/resources/api_keys.py (4 hunks)
- cuenca/resources/arpc.py (2 hunks)
- cuenca/resources/base.py (7 hunks)
- cuenca/resources/card_activations.py (1 hunks)
- cuenca/resources/cards.py (4 hunks)
- cuenca/resources/clabes.py (2 hunks)
- cuenca/resources/curp_validations.py (2 hunks)
- cuenca/resources/endpoints.py (3 hunks)
- cuenca/resources/file_batches.py (2 hunks)
- cuenca/resources/files.py (2 hunks)
- cuenca/resources/kyc_validations.py (2 hunks)
- cuenca/resources/kyc_verifications.py (3 hunks)
- cuenca/resources/limited_wallets.py (2 hunks)
- cuenca/resources/login_tokens.py (2 hunks)
- cuenca/resources/platforms.py (2 hunks)
- cuenca/resources/questionnaires.py (2 hunks)
- cuenca/resources/resources.py (2 hunks)
- cuenca/resources/savings.py (3 hunks)
- cuenca/resources/sessions.py (2 hunks)
- cuenca/resources/transfers.py (1 hunks)
- cuenca/resources/user_credentials.py (3 hunks)
- cuenca/resources/user_lists_validation.py (2 hunks)
- cuenca/resources/user_logins.py (2 hunks)
- cuenca/resources/users.py (3 hunks)
- cuenca/resources/verifications.py (3 hunks)
- cuenca/resources/wallet_transactions.py (1 hunks)
- cuenca/version.py (1 hunks)
- tests/resources/test_api_keys.py (1 hunks)
Additional context used
Ruff
cuenca/resources/base.py
38-38: Trailing comma missing
Add trailing comma
(COM812)
43-43: Missing type annotation for
selfin method(ANN101)
52-52: Missing type annotation for
**data(ANN003)
52-52: Trailing comma missing
Add trailing comma
(COM812)
64-64: Missing type annotation for
**data(ANN003)
64-64: Trailing comma missing
Add trailing comma
(COM812)
75-75: Missing type annotation for
**data(ANN003)
75-75: Trailing comma missing
Add trailing comma
(COM812)
81-81: Missing type annotation for
selfin method(ANN101)
118-118: Missing type annotation for
**data(ANN003)
140-140: Missing type annotation for
**query_params(ANN003)
140-140: Trailing comma missing
Add trailing comma
(COM812)
154-154: Missing type annotation for
**query_params(ANN003)
154-154: Trailing comma missing
Add trailing comma
(COM812)
168-168: Missing type annotation for
**query_params(ANN003)
168-168: Trailing comma missing
Add trailing comma
(COM812)
176-176: Missing type annotation for
**query_params(ANN003)
176-176: Trailing comma missing
Add trailing comma
(COM812)
Additional comments not posted (39)
cuenca/version.py (2)
1-1: Version update looks good.The version has been correctly updated from '1.0.2' to '1.0.3', following semantic versioning for a patch update.
1-3: Verify if type annotations were intended.The PR objective mentions "proper type annotation", but no type annotations have been added to the variables in this file. Please confirm if type annotations were intended to be added to
__version__,CLIENT_VERSION, andAPI_VERSION.If type annotations are needed, consider updating the variables as follows:
__version__: str = '1.0.3' CLIENT_VERSION: str = __version__ API_VERSION: str = '2020-03-19'cuenca/resources/clabes.py (1)
12-14: Approve removal ofcast, but suggest adding return type annotationThe removal of the
castfunction aligns with the PR objective of "proper type annotation". This change is good as it eliminates unnecessary type casting.However, to fully achieve proper type annotation, please consider the following suggestions:
Add a return type annotation to the
createmethod. This will make the method's contract clearer and help with type checking.Verify the return type of the
_createmethod in the parent class (likelyCreatable) to ensure type consistency.Here's a suggested improvement:
@classmethod - def create(cls, session: Session = global_session): + def create(cls, session: Session = global_session) -> 'Clabe': return cls._create(session=session)To verify the return type of the
_createmethod, please run the following script:This will help ensure that the return type of
creatematches the return type of_create.Verification successful
Approve removal of
castand add return type annotationThe removal of the
castfunction aligns with the PR objective of "proper type annotation," eliminating unnecessary type casting.To fully achieve proper type annotation, please consider the following:
Add a return type annotation to the
createmethod:@classmethod - def create(cls, session: Session = global_session): + def create(cls, session: Session = global_session) -> R_co: return cls._create(session=session)Ensure that
R_cois correctly defined to represent the intended return type in the context of theClabeclass.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the return type of the _create method in the parent class # Test: Search for the _create method definition in potential parent classes rg --type python -A 5 'def _create\('Length of output: 70
Script:
#!/bin/bash # Description: Search for the _create method definition in parent classes using the correct file type # Attempt 1: Using the correct --type identifier for Python rg --type py -A 5 'def _create\(' # If the above fails, use a glob pattern to search within .py files # rg 'def _create\(' --glob '*.py' -A 5Length of output: 364
Tools
Ruff
13-13: Missing return type annotation for classmethod
create(ANN206)
13-13: Missing type annotation for
clsin classmethod(ANN102)
cuenca/resources/login_tokens.py (1)
20-20: Approved: Improved type handling by removing unnecessary castThe change to directly return
cls._create(session=session)without using acastfunction is a good improvement. This aligns well with the PR objective of "proper type annotation". Here's why this change is beneficial:
- It simplifies the code by removing an unnecessary type cast.
- It relies on the type system to correctly infer the return type, which should be
LoginTokenbased on the method's return type annotation.- It potentially improves static type checking, as modern type checkers can often infer types correctly without explicit casts.
- It maintains consistency with the base
Creatableclass, assuming_createis defined there and returns the correct type.This change demonstrates good practices in Python type hinting and should lead to more maintainable and type-safe code.
cuenca/resources/resources.py (3)
3-3: LGTM: Improved type annotationsThe addition of
DictandListto the import statement fromtypingis appropriate and consistent with their usage in the file. This change, along with the existing type annotations, contributes to better type checking and code clarity.
Line range hint
1-24: Summary: Improved type annotations and code simplificationThe changes in this file successfully achieve the PR objective of "proper type annotation". The removal of the
castfunction inretrieve_urisimplifies the code while relying on the type system's inference capabilities. The import statements have been updated to include necessary types, and existing type annotations are appropriate and helpful.These changes contribute to better type checking, code clarity, and maintainability. Great job on improving the type annotations and simplifying the code!
Tools
Ruff
14-14: Avoid specifying long messages outside the exception class
(TRY003)
16-16: LGTM: Simplified return statementThe removal of the
castfunction simplifies the code while maintaining type safety. This change suggests that the type system can now correctly infer the return type without explicit casting, which aligns with the PR objective of "proper type annotation".To ensure type consistency across the codebase, please run the following script:
This script will help verify that all resource classes implementing
Retrievablehave aretrievemethod with a consistent return type.cuenca/resources/file_batches.py (1)
25-25: Approved: Improved type annotation and code simplificationThe removal of the
castfunction from the return statement is a positive change that aligns with the PR objective of "proper type annotation". This modification:
- Simplifies the code by removing redundant type casting.
- Maintains type safety through the existing return type annotation
-> 'FileBatch'.- Improves readability without sacrificing type information for static type checkers.
The change is correct and beneficial to the codebase.
cuenca/resources/wallet_transactions.py (1)
Line range hint
1-1: Verify if thecastimport is still needed.With the removal of the type cast in the
createmethod, thecastimport fromtypingmight no longer be necessary. However, it's still used in thewalletproperty.Let's verify if
castis used elsewhere in the file:If the script confirms that
castis only used in thewalletproperty, consider keeping it. Otherwise, if it's completely unused, you can remove the import.cuenca/resources/limited_wallets.py (1)
40-40: Approval: Improved type handling and code simplificationThe removal of the explicit type cast
cast('LimitedWallet', ...)is a positive change that aligns well with the PR objective of "proper type annotation". This modification offers several benefits:
- It simplifies the code by removing redundant type casting.
- It maintains type safety through the method's return type annotation
-> 'LimitedWallet'.- It demonstrates trust in the class hierarchy and the
cls._createmethod's implementation.- It adheres to Python's principle of "explicit is better than implicit" by relying on the natural type returned by
cls._create.This change improves code readability and maintainability while preserving type information for static type checkers.
cuenca/resources/user_credentials.py (2)
43-43: LGTM! Verify return type ofcls._update()The removal of the
castcall simplifies the code and aligns with the PR objective of proper type annotation. The method signature already includes correct type annotations.To ensure type consistency, please verify that
cls._update()returns aUserCredentialobject. Run the following script to check the return type:#!/bin/bash # Description: Verify the return type of cls._update() in the UserCredential class # Test: Search for the _update method implementation ast-grep --lang python --pattern $'class UserCredential($$$): $$$ def _update($$$): $$$ return $$$'If
cls._update()doesn't return aUserCredentialobject, consider adding a type annotation to the_updatemethod to ensure type consistency.
28-28: LGTM! Verify return type ofcls._create()The removal of the
castcall simplifies the code and aligns with the PR objective of proper type annotation. The method signature already includes correct type annotations.To ensure type consistency, please verify that
cls._create()returns aUserCredentialobject. Run the following script to check the return type:If
cls._create()doesn't return aUserCredentialobject, consider adding a type annotation to the_createmethod to ensure type consistency.cuenca/resources/kyc_validations.py (2)
Line range hint
1-24: LGTM: Imports and class definition are properly annotated.The imports and class definition, including attribute type annotations, are correctly implemented. This aligns well with the PR objective of proper type annotation.
Line range hint
1-41: Summary: Successful implementation of proper type annotationsThe changes in this file effectively improve type annotations, particularly in the
createmethod. The removal of thecastfunction simplifies the code while maintaining type safety through return type annotations. This aligns perfectly with the PR objective of implementing proper type annotations.The imports, class definition, and method signatures are all correctly annotated, contributing to a well-typed and clear codebase. Great job on improving the type safety and readability of the code!
cuenca/resources/card_activations.py (1)
Line range hint
1-56: Summary: Good progress on improving type annotationsThe changes in this file align well with the PR objective of proper type annotation. The simplification in the
createmethod improves code clarity while maintaining correct type information.Two minor suggestions were made to further improve consistency:
- Remove the unused
castimport.- Remove the redundant
castin thecardproperty.Overall, these changes and suggestions contribute to better type annotation practices in the codebase.
Tools
Ruff
48-48: Missing type annotation for
selfin method(ANN101)
cuenca/resources/user_lists_validation.py (1)
39-39: Excellent improvement in type annotation!The removal of the
castfunction is a positive change. It aligns with the PR objective of "proper type annotation" and improves code clarity. Here's why this change is beneficial:
- The method already has a return type annotation
-> 'UserListsValidation', making thecastfunction redundant.- Removing
castsimplifies the code without losing any type information.- It relies on the type system to infer the correct return type, which is a good practice in modern Python development.
This change maintains type safety while reducing unnecessary code, which is an excellent improvement.
cuenca/resources/user_logins.py (1)
Line range hint
1-48: Summary: Approved changes with minor suggestions for improvementThe changes in this file align well with the PR objective of proper type annotation. The removal of redundant casting in the
createmethod is a good improvement. The suggested minor changes to use actual types instead of string literals for type annotations will further enhance the consistency and effectiveness of type hinting in the file.Overall, the modifications contribute to cleaner and more maintainable code with proper type annotations.
cuenca/resources/savings.py (2)
54-54: Approve changesThe removal of the
castfunction aligns with the PR objective of proper type annotation. This change is good as it removes unnecessary type casting, assuming thatcls._updatealready returns the correct type.The method already has an explicit return type annotation, which is excellent for type safety and code readability.
Line range hint
1-54: Overall approval with a minor suggestionThe changes in this file align well with the PR objective of proper type annotation. The removal of unnecessary
castfunctions in bothcreateandupdatemethods improves code clarity without compromising type safety.Key points:
- Good use of type hints throughout the file.
- Proper input validation using
SavingRequestandSavingUpdateRequest.- Correct usage of class methods.
The only minor suggestion is to add an explicit return type annotation to the
createmethod, as mentioned in a previous comment.Great job on improving the type annotations and maintaining clean, well-structured code!
cuenca/resources/kyc_verifications.py (2)
41-42: Approved: Removal of redundant type castingThe removal of the
castfunction from the return statement is a good improvement. This change:
- Simplifies the code.
- Relies on the existing return type hint
-> 'KYCVerification'for type checking.- Aligns with the PR objective of "proper type annotation".
The
_createmethod (likely defined in theCreatableparent class) should already return an instance ofKYCVerification, making the explicit cast unnecessary.Tools
Ruff
41-41: Missing type annotation for
clsin classmethod(ANN102)
Line range hint
1-51: Summary: Improved type annotations and code simplificationThe changes in this file successfully achieve the PR objective of "proper type annotation" by:
- Removing redundant
castfunctions from bothcreateandupdatemethods.- Relying on the existing return type hints (
-> 'KYCVerification') for type checking.These modifications result in cleaner, more maintainable code without sacrificing type safety. The changes are consistent across both methods and align well with Python's type hinting system.
Great job on improving the code quality!
Tools
Ruff
41-41: Missing type annotation for
clsin classmethod(ANN102)
cuenca/resources/sessions.py (1)
53-53: Approval: Improved type handling by removing redundant castThe removal of
cast('Session', ...)from the return statement is a positive change that aligns with the PR objective of "proper type annotation". This modification:
- Simplifies the code by removing a redundant operation.
- Relies on the type checker rather than runtime type casting, which is a good practice.
- Maintains type safety through the existing return type annotation
-> 'Session'.This change effectively improves the code without compromising type information or safety.
cuenca/resources/verifications.py (1)
Line range hint
1-57: Overall, good improvements to type annotations.The changes in this file successfully remove unnecessary
castfunctions, simplifying the code and improving type annotations. This aligns well with the PR objective of "proper type annotation".Key improvements:
- Simplified return statements in both
createandverifymethods.- Reliance on the correct return types of
_createand_updatemethods.These changes make the code cleaner and more maintainable while preserving type safety. The suggestions to add type annotations to the parent class methods (
_createand_update) would further enhance type safety and code clarity.Tools
Ruff
45-45: Trailing comma missing
Add trailing comma
(COM812)
cuenca/resources/arpc.py (1)
55-55: Approval: Improved type annotation usageThe removal of
cast('Arpc', ...)from the return statement is a positive change that aligns with the PR objective of "proper type annotation". This modification is beneficial for the following reasons:
- It simplifies the code without changing its functionality.
- It removes unnecessary use of
cast, which is primarily meant for static type checking and doesn't perform runtime type conversion.- The method's return type is already correctly annotated as
'Arpc'in the method signature, making thecastredundant.This change demonstrates a better understanding and usage of Python's type hinting system.
cuenca/resources/files.py (2)
47-47: Approve the simplification, but verify_uploadmethod's return type.The removal of the
castfunction simplifies the code and aligns with the PR objective of proper type annotation. This change is good as it reduces unnecessary type casting.However, to ensure type safety:
- Verify that
cls._uploadalways returns an instance of theFileclass.- If not already present, consider adding a return type annotation to the
_uploadmethod:@classmethod def _upload(cls, ...) -> 'File': # method implementationThis will help catch any potential type mismatches at compile-time rather than runtime.
To verify the
_uploadmethod's implementation and type annotations, run the following script:#!/bin/bash # Description: Check the _upload method implementation and type annotations # Search for the _upload method definition ast-grep --lang python --pattern $'class File($$$): $$$ @classmethod def _upload(cls, $$$): $$$' # Search for any type annotations on _upload rg --type python '_upload.*\).*->'
Line range hint
1-70: Overall type annotations look good, with a minor suggestion.The file demonstrates good use of type annotations throughout:
- Proper imports from
typing- Class variables and attributes are well-annotated
- Methods have appropriate return type annotations
To further improve type safety:
- Verify that the
downloadmethod (likely defined in a parent class) has proper type annotations:def download(self, file_id: str) -> BytesIO: # method implementationThis ensures consistency with its usage in the
fileproperty.To verify the
downloadmethod's implementation and type annotations, run the following script:Tools
Ruff
50-50: Missing type annotation for
selfin method(ANN101)
cuenca/resources/platforms.py (1)
79-79: Approved: Improved type handling by removing redundant castThe removal of the
castfunction from the return statement is a positive change that aligns with the PR objective of "proper type annotation". This modification:
- Simplifies the code by eliminating redundant type casting.
- Relies on Python's type inference and the method's return type annotation (
-> 'Platform').- Assumes correct implementation of the
_createmethod in the parentCreatableclass.This change enhances code readability without compromising type safety, as long as the
_createmethod is correctly implemented in the parent class.cuenca/resources/transfers.py (1)
72-72: Clarify the removal ofcastand its impact on type safetyThe removal of
cast(Transfer, ...)simplifies the code, but it might affect type checking and seems to contradict the PR objective of "proper type annotation". Please address the following points:
Type safety: Can we guarantee that
cls._create(**req.dict())always returns aTransferobject? If not, removingcastmight lead to less strict type checking.Return type consistency: The method is annotated to return
'Transfer'. Ensure thatcls._createis consistent with this return type annotation.PR objective alignment: The PR aims for "proper type annotation". How does removing an explicit type cast align with this objective?
To help verify the return type of
cls._create, please run the following script:This will help us understand the implementation of
_createand ensure type consistency.Verification successful
Verified Removal of
castincreateMethodThe
cls._create(**req.dict())call in thecreatemethod is type-safe and consistently returns aTransferinstance by inheriting the_createmethod from the base class. Removing the explicitcastaligns with the PR objective of "proper type annotation" and simplifies the code without compromising functionality.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the implementation of _create method in the base classes # Search for _create method in potential base classes rg --type python -A 10 'def _create' # Search for Transfer._create if it's defined in the class ast-grep --lang python --pattern 'class Transfer($_) { $$$ def _create($_) { $$$ } $$$ }'Length of output: 662
Script:
#!/bin/bash # Description: Corrected scripts to check the implementation of _create method in base classes # Search for _create method in potential base classes using the correct file type rg --type py -A 10 'def _create' # Search for Transfer._create within the Transfer class using a valid ast-grep pattern ast-grep --lang python --pattern 'class Transfer { ... def _create($ARGS): ... ... }'Length of output: 1128
cuenca/resources/endpoints.py (2)
75-75: Approval: Improved type handlingThe removal of the
castfunction from the return statement is a positive change. It simplifies the code and relies on Python's type system to infer the correct return type. This aligns well with the PR objective of "proper type annotation".The method still correctly annotates its return type as
'Endpoint', which is sufficient for type checking purposes. This change maintains the intended functionality while improving code readability.
Line range hint
1-99: Summary: Improved type annotations and code clarityThe changes in this file successfully achieve the PR objective of "proper type annotation". By removing the
castfunction from bothcreateandupdatemethods, the code becomes cleaner and more idiomatic. These changes:
- Simplify the return statements in both methods.
- Rely on Python's type system to infer the correct types.
- Maintain the correct return type annotations.
- Improve code readability without affecting functionality.
These modifications align well with modern Python type hinting practices and should make the code easier to maintain and understand. The changes are subtle but impactful, demonstrating a good understanding of Python's type system.
cuenca/resources/cards.py (4)
Line range hint
1-120: Summary of changes and recommendationsThe changes in this PR align well with the objective of "proper type annotation" by removing unnecessary
castfunctions. This improves code readability and relies more on Python's type inference capabilities. However, to further enhance type safety and code clarity, consider the following recommendations:
- Add explicit return type annotations to the
create,update, anddeactivatemethods.- In the
deactivatemethod, consider adding a comment to explain the assumption made when usingcls(**resp).These changes will make the type hints more explicit and the code more self-documenting, which aligns with the goal of proper type annotation.
109-109: Verify return type annotation forupdatemethodThe removal of
cast('Card', ...)improves code clarity. To ensure proper type annotation, we should explicitly annotate the return type of the method.Please run the following script to check the method signature:
#!/bin/bash # Description: Check the update method signature for proper return type annotation ast-grep --lang python --pattern 'def update($$$) -> $_: $$$'If the script doesn't return any results, consider updating the method signature to include an explicit return type annotation:
@classmethod def update( cls, card_id: str, status: Optional[CardStatus] = None, pin_block: Optional[str] = None, is_dynamic_cvv: bool = False, *, session: Session = global_session, ) -> 'Card': # ... method body ...
120-120: Verify return type annotation and reviewcls(**resp)usage
- To ensure proper type annotation, we should explicitly annotate the return type of the method.
Please run the following script to check the method signature:
#!/bin/bash # Description: Check the deactivate method signature for proper return type annotation ast-grep --lang python --pattern 'def deactivate($$$) -> $_: $$$'If the script doesn't return any results, consider updating the method signature to include an explicit return type annotation:
@classmethod def deactivate( cls, card_id: str, *, session: Session = global_session ) -> 'Card': # ... method body ...
- The use of
cls(**resp)assumes that therespdictionary keys match the class attributes exactly. While this is likely the case, it's worth noting that this approach might be less robust than the previous_from_dictmethod if the API response structure changes.Consider adding a comment to explain this assumption:
# Assume that the API response keys match the Card class attributes return cls(**resp)
84-84: Verify return type annotation forcreatemethodThe removal of
cast('Card', ...)is a good step towards cleaner code. However, to ensure proper type annotation, we should explicitly annotate the return type of the method.Please run the following script to check the method signature:
If the script doesn't return any results, consider updating the method signature to include an explicit return type annotation:
@classmethod def create( cls, issuer: CardIssuer, funding_type: CardFundingType, user_id: str = 'me', card_holder_user_id: Optional[str] = None, is_dynamic_cvv: bool = False, *, session: Session = global_session, ) -> 'Card': # ... method body ...Verification successful
Return type annotation for
createmethod is correctly specifiedThe
createmethod incuenca/resources/cards.pyis properly annotated with an explicit return type'Card'.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the create method signature for proper return type annotation ast-grep --lang python --pattern 'def create($$$) -> $_: $$$'Length of output: 2134
Script:
#!/bin/bash # Description: Verify if the create method in cuenca/resources/cards.py has an explicit return type annotation ast-grep --lang python --pattern 'def create($$$) -> $_: $$$' cuenca/resources/cards.pyLength of output: 1777
cuenca/resources/curp_validations.py (2)
Line range hint
1-101: Overall type annotations in the file look goodThe file demonstrates consistent use of type annotations throughout the
CurpValidationclass. All attributes and method parameters have appropriate type hints, which contributes to code clarity and helps prevent type-related errors. TheConfiginner class provides useful field descriptions and an example, further enhancing the documentation of the class.
101-101: Approved: Removal of explicit cast improves type annotationsThe removal of the
castfunction from the return statement is a good change. It aligns with the PR objective of "proper type annotation". The return type hint'CurpValidation'in the method signature should be sufficient for type checking without explicit casting.Let's verify the return type of the
_createmethod to ensure it's compatible withCurpValidation:This script will help us confirm that the
_createmethod's return type is compatible withCurpValidation, ensuring that the removal of the explicit cast doesn't introduce any type-related issues.Verification successful
Verified:
_createmethod's return type is compatible withCurpValidationThe analysis confirms that the
_createmethod in theCreatableclass returns an instance compatible withCurpValidation. The removal of the explicitcastfunction aligns with proper type annotations and does not introduce any type-related issues.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the return type of the _create method in the Creatable class # Search for the Creatable class definition echo "Searching for Creatable class definition:" rg --type python -A 10 "class Creatable" # Search for the _create method definition echo "\nSearching for _create method definition:" rg --type python -A 5 "def _create" # Search for any type hints related to _create method echo "\nSearching for type hints related to _create method:" rg --type python "_create.*->|_create.*:.*="Length of output: 525
Script:
#!/bin/bash # Description: Check the return type of the _create method in the Creatable class # Search for the Creatable class definition echo "Searching for Creatable class definition:" rg --type py -A 10 "class Creatable" # Search for the _create method definition echo "\nSearching for _create method definition:" rg --type py -A 5 "def _create" # Search for any type hints related to _create method echo "\nSearching for type hints related to _create method:" rg --type py "_create.*->|_create.*:.*="Length of output: 1456
cuenca/resources/users.py (1)
138-138: Approved: Removal of unnecessary type castingThe removal of
cast()in thecreatemethod is appropriate and aligns with the PR objective of proper type annotation. The_createmethod should already return aUserobject, making the cast redundant.cuenca/resources/base.py (2)
20-20: Introduction of covariant 'R_co' enhances type safetyThe addition of
R_co = TypeVar('R_co', bound='Resource', covariant=True)improves type safety and ensures that type annotations are correctly inferred in methods returning instances of resources.
28-29: Setting 'extra = Extra.ignore' in 'Config' is appropriateBy configuring Pydantic's
Configwithextra = Extra.ignore, any unexpected fields in the data will be ignored. This prevents potential errors when parsing API responses that include additional fields not defined in the model.
There was a problem hiding this comment.
Actionable comments posted: 14
Outside diff range comments (2)
cuenca/resources/transfers.py (1)
Line range hint
1-95: Overall improvement in type annotations with suggestion for broader reviewThe changes in this file successfully remove unnecessary type casting in the
createandcreate_manymethods, aligning well with the PR objectives. These modifications will improve type inference for linters and make the code more maintainable.To further enhance the type safety across the codebase:
- Review parent classes (Transaction, Creatable) and ensure their methods have appropriate return type annotations.
- Check if similar type casting removals can be applied to other resource classes that might have a similar structure.
- Consider adding type annotations to class variables and properties if they're missing.
These additional steps would ensure consistency across the entire resource module and maximize the benefits of the improved type annotations.
Tools
Ruff
75-75: Missing type annotation for
clsin classmethod(ANN102)
cuenca/resources/endpoints.py (1)
Line range hint
78-100: LGTM: Improved type handling and documentationThe changes in the
updatemethod are positive:
- Removing the
castfunction from the return statement simplifies the code and improves readability.- Adding the
eventsparameter to the method signature and docstring enhances the documentation.These changes align well with the PR objective of "proper type annotation" and maintain the intended functionality.
Minor suggestion: Add a trailing comma after the last item in the
EndpointUpdateRequestconstructor for consistency with Python style guidelines:req = EndpointUpdateRequest( - url=url, is_enable=is_enable, events=events + url=url, is_enable=is_enable, events=events, )Tools
Ruff
98-98: Trailing comma missing
Add trailing comma
(COM812)
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (9)
- cuenca/init.py (1 hunks)
- cuenca/resources/base.py (7 hunks)
- cuenca/resources/card_validations.py (1 hunks)
- cuenca/resources/endpoints.py (3 hunks)
- cuenca/resources/otps.py (2 hunks)
- cuenca/resources/savings.py (3 hunks)
- cuenca/resources/transfers.py (2 hunks)
- cuenca/resources/users.py (4 hunks)
- cuenca/resources/wallet_transactions.py (1 hunks)
Additional context used
Ruff
cuenca/resources/base.py
46-46: Missing type annotation for
selfin method(ANN101)
58-58: Dynamically typed expressions (typing.Any) are disallowed in
**data(ANN401)
74-74: Dynamically typed expressions (typing.Any) are disallowed in
**data(ANN401)
89-89: Dynamically typed expressions (typing.Any) are disallowed in
**data(ANN401)
95-95: Missing type annotation for
selfin method(ANN101)
132-132: Dynamically typed expressions (typing.Any) are disallowed in
**data(ANN401)
157-157: Dynamically typed expressions (typing.Any) are disallowed in
**query_params(ANN401)
174-174: Dynamically typed expressions (typing.Any) are disallowed in
**query_params(ANN401)
191-191: Dynamically typed expressions (typing.Any) are disallowed in
**query_params(ANN401)
202-202: Dynamically typed expressions (typing.Any) are disallowed in
**query_params(ANN401)
cuenca/resources/endpoints.py
98-98: Trailing comma missing
Add trailing comma
(COM812)
Additional comments not posted (11)
cuenca/resources/otps.py (3)
1-1: LGTM: Removal of unused importThe removal of the unused
castimport from thetypingmodule is a good cleanup. This change aligns with the PR objective of eliminating the necessity for usingtyping.cast()and helps in keeping the imports clean and relevant.
Line range hint
1-24: Summary: Improved type handling in Otp classThe changes in this file successfully implement the PR objective of enhancing type annotations and eliminating unnecessary
typing.cast()usage. Thecreatemethod now returns the result ofcls._create(session=session)directly, which simplifies the code while maintaining type safety through the return type annotation. These modifications should improve code readability and maintainability without compromising type inference capabilities.
Line range hint
19-24: LGTM: Simplified return statement increatemethodThe removal of the
castfunction in the return statement aligns with the PR objective of eliminating the necessity for usingtyping.cast(). This change simplifies the code and improves readability while maintaining the return type annotation-> 'Otp'for static type checking.To ensure this change doesn't negatively impact type inference elsewhere in the codebase, please run the following verification script:
This script will help identify any potential issues with type inference that might have been introduced by this change.
cuenca/resources/wallet_transactions.py (1)
32-32: LGTM! Great improvements to type annotations.The changes in the
createmethod are excellent:
- The addition of the explicit return type annotation
-> 'WalletTransaction'improves code clarity and type safety.- The removal of the type cast in the return statement aligns with the PR objective of eliminating unnecessary
typing.cast()usage.These changes maintain the existing functionality while enhancing type inference and code readability. The suggestion from the past review comment has been successfully addressed.
Also applies to: 38-38
cuenca/resources/savings.py (1)
30-37: Excellent implementation of proper type annotations!The changes in the
createmethod align perfectly with the PR objectives:
- The removal of the
castfunction simplifies the code and improves readability.- The addition of the
-> 'Saving'return type annotation enhances type safety.These modifications will allow for better type inference and eliminate the need for explicit casting. Great job implementing the suggestion from the previous review!
cuenca/__init__.py (1)
97-97: Excellent improvement in type handling!The removal of the explicit
cast()function aligns well with the PR objectives. This change:
- Simplifies the code, making it more readable and maintainable.
- Indicates improved type inference, likely due to enhanced type annotations in the
BalanceEntryclass.- Maintains the existing functionality while potentially offering a slight performance improvement by eliminating the casting overhead.
Great job on streamlining the code while preserving its behavior!
cuenca/resources/card_validations.py (1)
54-54: Approve the removal of unnecessary type castingThe removal of the
castfunction from the return statement aligns with the PR objective of improving type annotations and simplifying the code. This change enhances readability and maintainability.To ensure type safety, let's verify the return type annotation of the
_createmethod:This will help confirm that the
_createmethod is properly annotated to return aCardValidationobject, ensuring type safety without the need for explicit casting.cuenca/resources/transfers.py (1)
72-72: Approved: Improved type inference by removing explicit castingThe removal of
cast(Transfer, ...)aligns well with the PR objectives. This change will allow for better type inference by linters and eliminates the need for explicit type casting. The functionality remains unchanged, which is excellent for maintaining backwards compatibility.cuenca/resources/endpoints.py (1)
Line range hint
64-75: LGTM: Improved type handlingThe removal of the
castfunction from the return statement is a positive change. It simplifies the code and relies on Python's type system to infer the correct return type. This aligns well with the PR objective of "proper type annotation".The method still correctly annotates its return type as
'Endpoint', which is sufficient for type checking purposes. This change maintains the intended functionality while improving code readability.cuenca/resources/users.py (1)
Line range hint
1-182: Summary: Improvements in type annotations with suggestions for further enhancementsThe changes in this file successfully remove unnecessary type casting, aligning with the PR objective of improving type annotations. These modifications simplify the code and make it more maintainable.
To further enhance the type safety and readability of the code, consider implementing the suggested return type annotations for the
balanceproperty,create, andupdatemethods.Overall, these changes represent a positive step towards better type handling in the
Userclass.Tools
Ruff
61-61: Missing type annotation for
selfin method(ANN101)
cuenca/resources/base.py (1)
38-42: Improved type safety inretrievemethodThe updated method signature of
retrievenow usescls: Type[R_co]and returnsR_co, leveraging the covariant type variable. This enhances type safety and clarity.
| be = BalanceEntry.first(user_id=self.id) | ||
| return be.rolling_balance if be else 0 |
There was a problem hiding this comment.
Approved: Removal of unnecessary type casting with suggestion for further improvement
The removal of cast() is appropriate and aligns with the PR objective of proper type annotation. This change simplifies the code without affecting its functionality.
Consider updating the return type annotation of the balance property to be more specific:
@property
def balance(self) -> int:
be = BalanceEntry.first(user_id=self.id)
return be.rolling_balance if be else 0This change would make the type annotation more precise and consistent with the actual return value.
| 'User', | ||
| cls._update(id=user_id, **request.dict(), session=session), | ||
| ) | ||
| return cls._update(id=user_id, **request.dict(), session=session) |
There was a problem hiding this comment.
Approved: Removal of unnecessary type casting with suggestion for further improvement
The removal of cast() in the update method is appropriate and aligns with the PR objective of proper type annotation. This change simplifies the code without affecting its functionality.
Consider adding an explicit return type annotation to the update method:
@classmethod
def update(
cls,
user_id: str,
# ... other parameters ...
) -> 'User':
# ... method body ...
return cls._update(id=user_id, **request.dict(), session=session)This change would make the return type explicit and consistent with the actual return value.
Improves type annotations for Resource class and subclasses, focusing on return types. Enhances type inference, allowing linters to accurately recognize return types from Resource methods and subclasses, removing the need for
typing.cast()Summary by CodeRabbit
Release Notes for Version 1.0.3
New Features
Bug Fixes
Documentation