chore: format token examples with black

[thzthix]

Description:

Related issue(s):

Fixes #1119

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

Summary by CodeRabbit

Release Notes

• Style

  • Formatted all token example code with Black for consistent code style and improved readability.

• Bug Fixes

  • Enhanced error handling in token examples with environment variable validation.
  • Corrected NFT transfer implementation usage in examples.

• Refactor

  • Expanded token example implementations with more comprehensive functional demonstrations.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[github-actions]

Hi, this is WorkflowBot.
Your pull request cannot be merged as it is not passing all our workflow checks.
Please click on each check to review the logs and resolve issues so all checks pass.
To help you:

• DCO signing guide
• Changelog guide
• Merge conflicts guide
• Rebase guide
• Testing guide
• Discord
• Community Calls
  Thank you for contributing!
  From the Hiero Python SDK Team

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@           Coverage Diff           @@
##             main    #1127   +/-   ##
=======================================
  Coverage   91.04%   91.04%           
=======================================
  Files         139      139           
  Lines        8409     8409           
=======================================
  Hits         7656     7656           
  Misses        753      753           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[exploreriii]

Hi @thzthix I think you are missing a changelog entry please!
Read docs/sdk_developers/changelog_entry.md

I notice your branch is now behind the upstream main
please do fetch from upstream and pull changes and rebase your branch
docs/sdk_developers/training/workflow/03_staying_in_sync.md

[coderabbitai]

Walkthrough

This PR applies Black code formatter to standardize formatting across token example files in the Hiero Python SDK, including quote normalization, import restructuring, and whitespace adjustments. A CHANGELOG entry documents the formatting updates.

Changes

Cohort / File(s)	Summary
Documentation CHANGELOG.md	Added entry documenting Black formatting applied to token examples for consistent code style.
Token Examples — Formatting Only examples/tokens/token_burn_transaction_nft.py, token_create_transaction_admin_key.py, token_create_transaction_freeze_key.py, token_create_transaction_fungible_infinite.py, token_create_transaction_kyc_key.py, token_create_transaction_max_automatic_token_associations_0.py, token_create_transaction_nft_finite.py, token_create_transaction_pause_key.py, token_create_transaction_supply_key.py, token_create_transaction_token_fee_schedule_key.py, token_fee_schedule_update_transaction_nft.py, token_grant_kyc_transaction.py, token_mint_transaction_fungible.py, token_revoke_kyc_transaction.py, token_unfreeze_transaction.py, token_unpause_transaction.py, token_update_transaction_key.py, token_update_transaction_nft.py	Quote normalization (single to double quotes), import reformatting, whitespace and blank-line adjustments; no functional changes to logic or control flow.
Token Examples — Minor Formatting + Logic Tweaks examples/tokens/account_allowance_approve_transaction.py, token_associate_transaction.py, token_burn_transaction_fungible.py, token_create_transaction_pause_key.py, token_create_transaction_token_metadata.py, token_delete_transaction.py, token_fee_schedule_update_transaction_fungible.py, token_freeze_transaction.py, token_mint_transaction_non_fungible.py, token_pause_transaction.py, token_reject_transaction_fungible_token.py, token_reject_transaction_nft.py, token_update_transaction_fungible.py, token_wipe_transaction.py	Formatting adjustments combined with minor structural changes (print statement wrapping, parameter reformatting); core logic preserved.
Token Examples — Formatting + Significant Functional Changes examples/tokens/custom_fee_fixed.py	Added new fields (denominating_token_id, fee_collector_account_id, all_collectors_are_exempt) to CustomFixedFee instantiation; formatting adjustments.
Token Examples — Formatting + Logic Updates examples/tokens/custom_fee_fractional.py	Added environment variable validation; wrapped fee in list for TokenParams; added guard in print_fractional_fees for absent custom_fees; formatting updates.
Token Examples — Formatting Only (Minor Cleanup) examples/tokens/custom_fee_royalty.py	Blank lines and trailing newline adjustments; no functional changes.
Token Examples — Comprehensive Refactor examples/tokens/token_airdrop_claim_auto.py	Replaced skeleton implementations with full Hedera SDK calls (TokenCreateTransaction, TokenMintTransaction, TokenAirdropTransaction, AccountCreateTransaction); enhanced error handling and balance logging; reworked helpers to include concrete operations.
Token Examples — Formatting + Minor Adjustments examples/tokens/token_airdrop_claim_signature_required.py	Line breaks, trailing commas, and inline parameter annotations; no changes to public API or control flow.
Token Examples — Formatting Restructure examples/tokens/token_airdrop_transaction.py, token_airdrop_transaction_cancel.py	Import reorganization, environment variable double-quote normalization, multiline function signatures and calls; no changes to control flow.
Token Examples — Return Value & Call Signature Changes examples/tokens/token_create_transaction_fungible_finite.py	setup_client() now returns (client, operator_id, operator_key) tuple instead of None; formatting updates.
Token Examples — Return Tuple Reordering examples/tokens/token_dissociate_transaction.py	Reordered create_new_account return tuple; refactored token association to use add_token_id() per token instead of set_token_ids(); multiline formatting and environment variable normalization.
Token Examples — NFT Transfer API Update examples/tokens/token_create_transaction_wipe_key.py	Updated NFT transfer to use NftId(token_id, serial_number) instead of list-based serial reference; added NftId to imports; formatting adjustments.
Token Examples — Explicit Exit on Failure examples/tokens/token_create_transaction_nft_infinite.py	Added exit(1) on token creation failure (previously continued); formatting updates with double-quote normalization.
Token Examples — Multiline Import & Call Formatting examples/tokens/token_update_nfts_transaction_nfts.py	Import wrapping in parentheses, double-quote string literals, minor whitespace adjustments; no logic changes.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Areas requiring extra attention:

• token_airdrop_claim_auto.py — substantial refactoring with multiple new SDK call implementations; verify correctness of TokenCreateTransaction, TokenMintTransaction, and TokenAirdropTransaction usage.
• token_dissociate_transaction.py — return tuple reordering and token association refactoring; confirm all call sites properly destructure the new return order.
• custom_fee_fractional.py — new environment variable validation and custom_fees list wrapping; ensure logic handles both present and absent custom_fees correctly.
• token_create_transaction_fungible_finite.py — setup_client() now returns a tuple; verify all callers unpack correctly.
• token_create_transaction_wipe_key.py — NFT transfer API change to NftId constructor; verify syntax and behavior alignment with SDK.

Possibly related issues

• [Good First Issue]: black examples/tokens #1119: This PR directly implements the formatting work described in the issue by applying Black to examples/tokens/ files and adding a CHANGELOG entry as required.

Suggested reviewers

• exploreriii

Poem

🐰 With Black's brush, the tokens now shine so bright,
Quotes aligned, and indents set right,
From chaos to order, the examples now gleam,
Formatting's perfected—a developer's dream!
Hop along, reviewers, the code looks pristine. ✨

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'chore: format token examples with black' clearly describes the main change - applying Black code formatting to token examples, directly addressing issue #1119.
Linked Issues check	✅ Passed	The PR successfully implements Black formatting across all token example files as required by issue #1119, with a CHANGELOG.md entry added.
Out of Scope Changes check	✅ Passed	All changes are strictly formatting adjustments (quotes, whitespace, line wrapping) applied via Black to the examples/tokens directory, with no functional logic modifications or scope creep.
Docstring Coverage	✅ Passed	Docstring coverage is 93.81% 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

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 8

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

examples/tokens/token_delete_transaction.py (1)

63-63: Functional change in a formatting-only PR.

Adding .set_initial_supply(1) changes the token creation behavior by explicitly setting an initial supply. According to the PR objectives (issue #1119), this PR should only apply Black formatting with no behavioral changes.

If this functional change is intentional, please clarify in the PR description and consider updating the PR title/description to reflect that it includes functional changes beyond formatting. Otherwise, revert this line and create a separate PR for functional improvements.

examples/tokens/token_create_transaction_wipe_key.py (1)

309-313: Functional change exceeds Black formatting scope.

Line 311 introduces a functional change by using the NftId constructor instead of the previous approach. The comment "# FIX 2" indicates this is a bug fix, not formatting.

While the implementation appears correct based on the NftId class definition, this change should be:

1. Explicitly documented in the changelog as a functional fix (separate from formatting changes)
2. Possibly split into a separate commit or PR if project conventions require separating formatting from functional changes

The PR description states this is purely Black formatting for issue #1119, but this functional change may require additional documentation or justification.

🧹 Nitpick comments (12)

examples/tokens/token_unpause_transaction.py (1)

56-77: Note: Pre-existing exception handling patterns flagged by static analysis.

Two code quality hints from Ruff are worth considering for future improvements (not introduced by this formatting PR):

• TRY300 (Line 74): The return token_id followed by exception handling could be moved to an else block for clarity.
• BLE001 (Line 75 & others): Catching broad Exception is too permissive; consider catching specific exceptions (e.g., ValueError, TypeError).

These are optional refactors that can be addressed in a follow-up.

Consider verifying that the CI pipeline confirms all tests pass with these formatting changes, per the PR acceptance criteria.

Also applies to: 84-102

examples/tokens/token_fee_schedule_update_transaction_nft.py (1)

111-143: Token info query formatting is idiomatic; consider tightening exception scope.

Multi-line print statement (lines 131–133) is now more readable. The function correctly queries and displays token metadata. However, catching bare Exception at line 141 is overly broad; consider catching more specific exception types in a future refactor (e.g., QueryError or ValueError).

examples/tokens/token_create_transaction_token_metadata.py (1)

7-7: Optional: Fix pre-existing typos.

While reviewing, I noticed a few typos in the docstrings that pre-date this PR:

• Line 7: "succed" → "succeed"
• Line 160: "metadat_key" → "metadata_key"
• Line 230: same typos

These can be addressed in a follow-up commit if desired.

examples/tokens/token_create_transaction_supply_key.py (2)

80-94: Suggested refactor: Restructure try block per TRY300.

The return statement at line 90–91 is outside the error-checking if block but before the except clause. Consider restructuring to place the return in an else block for clearer intent, which improves readability when error paths call sys.exit().

if receipt.status != ResponseCode.SUCCESS:
    print(f"Token creation failed with status: {ResponseCode(receipt.status).name}")
    sys.exit(1)
else:
    token_id = receipt.token_id
    print(f" ✅ Token created successfully with ID: {token_id}")
    return token_id

---

152-166: Code quality: Restructure try block per TRY300 and narrow exception handling per BLE001.

Two improvements to this error handling block:

1. TRY300: Move the return statement (line 162–163) into an else block after the error-checking if, matching the pattern suggested in create_token_no_supply_key.

2. BLE001: Catching bare Exception at line 164 is too broad. Specify the exception type(s) you expect (e.g., ValueError, RuntimeError, or whatever the SDK raises on token creation failure).

🔎 Suggested refactor

try:
    receipt = transaction.execute(client)
    if receipt.status != ResponseCode.SUCCESS:
        print(
            f"Token creation failed with status: {ResponseCode(receipt.status).name}"
        )
        sys.exit(1)
    else:
        token_id = receipt.token_id
        print(f" ✅ Token created successfully with ID: {token_id}")
        return token_id, supply_key
except ValueError as e:
    print(f"Error during token creation: {e}.")
    sys.exit(1)

examples/tokens/token_airdrop_transaction_cancel.py (2)

49-51: LGTM: Black formatting applied correctly.

Function signatures have been properly wrapped to multiline format per Black's conventions.

Note: Static analysis flags line 50 for using a function call in the default argument (Hbar.from_tinybars(100_000_000)). While this is a pre-existing pattern and outside the scope of this formatting PR, you may consider refactoring it in a future change by moving the call inside the function body.

Also applies to: 70-72

---

94-96: LGTM: Black formatting applied correctly.

Print statements and method chains have been properly reformatted to multiline style, improving readability while maintaining the original logic.

Note: Static analysis suggests using f-string conversion flags on lines 115 and 148 (e.g., f"{t}" instead of f"{str(t)}"). While this is a pre-existing pattern and outside the scope of this formatting PR, it's a minor optimization you may consider in a future change.

Also applies to: 100-109, 114-116, 124-126, 133-142, 147-149

examples/tokens/token_delete_transaction.py (2)

97-98: Duplicate comment on consecutive lines.

Lines 97 and 98 both have the comment # Use the ID from the token we just made. The comment on line 98 appears to be a duplicate and doesn't contextually fit with the freeze_with(client) call. Consider removing the comment from line 98.

🔎 Apply this diff to remove the duplicate comment:

             .set_token_id(token_id_to_delete)  # Use the ID from the token we just made
-            .freeze_with(client)  # Use the ID from the token we just made
+            .freeze_with(client)
             .sign(operator_key)  # Operator must sign

---

30-39: Consider using an else block for clarity (optional).

The static analysis tool suggests moving the return statement to an else block after the except clause for better code structure, though the current implementation is clear and functional.

Based on static analysis hints, Ruff TRY300.

🔎 View suggested refactoring:

     try:
         operator_id = AccountId.from_string(os.getenv("OPERATOR_ID", ""))
         operator_key = PrivateKey.from_string(os.getenv("OPERATOR_KEY", ""))
         client.set_operator(operator_id, operator_key)
         print(f"Client set up with operator id {client.operator_account_id}")
-        return client, operator_id, operator_key
     except (TypeError, ValueError):
         print("Error: Please check OPERATOR_ID and OPERATOR_KEY in your .env file.")
         sys.exit(1)
+    else:
+        return client, operator_id, operator_key

examples/tokens/token_create_transaction_wipe_key.py (1)

62-62: Optional: Consider addressing static analysis hints in a future PR.

Static analysis identified code quality improvements that are out of scope for this Black formatting PR:

1. Lines 62 and 215: Consider moving return statements to else blocks after try/except (TRY300)
2. Line 217: Catching blind Exception is discouraged; consider catching specific exceptions (BLE001)

These are valid suggestions for future refinement but don't need to block this formatting PR.

Also applies to: 215-219

examples/tokens/custom_fee_fractional.py (1)

68-71: Consider renaming the list variable to avoid shadowing the parameter.

Line 71 reassigns fractional_fee to a list, which shadows the function parameter. While this works, it can be confusing to readers.

🔎 Suggested fix:

 def create_token_with_fee_key(client, operator_id, fractional_fee: CustomFractionalFee):
     """Create a fungible token with a fee_schedule_key."""
     print("Creating fungible token with fee_schedule_key...")
-    fractional_fee = [fractional_fee]
+    custom_fees = [fractional_fee]
 
     token_params = TokenParams(
         token_name="Fee Key Token",
         token_symbol="FKT",
         treasury_account_id=operator_id,
         initial_supply=1000,
         decimals=2,
         token_type=TokenType.FUNGIBLE_COMMON,
         supply_type=SupplyType.INFINITE,
-        custom_fees=fractional_fee,
+        custom_fees=custom_fees,
     )

examples/tokens/token_airdrop_claim_auto.py (1)

348-348: Unused variable receiver_key should be prefixed with underscore.

The receiver_key is unpacked but never used in this function. Per Python convention, prefix it with an underscore to indicate it's intentionally unused.

🔎 Suggested fix:

-    receiver_id, receiver_key = create_receiver(client, False, 10)
+    receiver_id, _receiver_key = create_receiver(client, False, 10)

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e73693c and f0476ce.

📒 Files selected for processing (44)

• CHANGELOG.md (1 hunks)
• examples/tokens/account_allowance_approve_transaction.py (7 hunks)
• examples/tokens/custom_fee_fixed.py (2 hunks)
• examples/tokens/custom_fee_fractional.py (7 hunks)
• examples/tokens/custom_fee_royalty.py (2 hunks)
• examples/tokens/token_airdrop_claim_auto.py (10 hunks)
• examples/tokens/token_airdrop_claim_signature_required.py (19 hunks)
• examples/tokens/token_airdrop_transaction.py (19 hunks)
• examples/tokens/token_airdrop_transaction_cancel.py (6 hunks)
• examples/tokens/token_associate_transaction.py (5 hunks)
• examples/tokens/token_burn_transaction_fungible.py (4 hunks)
• examples/tokens/token_burn_transaction_nft.py (5 hunks)
• examples/tokens/token_create_transaction_admin_key.py (5 hunks)
• examples/tokens/token_create_transaction_freeze_key.py (5 hunks)
• examples/tokens/token_create_transaction_fungible_finite.py (3 hunks)
• examples/tokens/token_create_transaction_fungible_infinite.py (3 hunks)
• examples/tokens/token_create_transaction_kyc_key.py (15 hunks)
• examples/tokens/token_create_transaction_max_automatic_token_associations_0.py (2 hunks)
• examples/tokens/token_create_transaction_nft_finite.py (3 hunks)
• examples/tokens/token_create_transaction_nft_infinite.py (4 hunks)
• examples/tokens/token_create_transaction_pause_key.py (3 hunks)
• examples/tokens/token_create_transaction_supply_key.py (9 hunks)
• examples/tokens/token_create_transaction_token_fee_schedule_key.py (5 hunks)
• examples/tokens/token_create_transaction_token_metadata.py (2 hunks)
• examples/tokens/token_create_transaction_wipe_key.py (17 hunks)
• examples/tokens/token_delete_transaction.py (5 hunks)
• examples/tokens/token_dissociate_transaction.py (8 hunks)
• examples/tokens/token_fee_schedule_update_transaction_fungible.py (7 hunks)
• examples/tokens/token_fee_schedule_update_transaction_nft.py (9 hunks)
• examples/tokens/token_freeze_transaction.py (6 hunks)
• examples/tokens/token_grant_kyc_transaction.py (5 hunks)
• examples/tokens/token_mint_transaction_fungible.py (8 hunks)
• examples/tokens/token_mint_transaction_non_fungible.py (6 hunks)
• examples/tokens/token_pause_transaction.py (9 hunks)
• examples/tokens/token_reject_transaction_fungible_token.py (7 hunks)
• examples/tokens/token_reject_transaction_nft.py (7 hunks)
• examples/tokens/token_revoke_kyc_transaction.py (6 hunks)
• examples/tokens/token_unfreeze_transaction.py (10 hunks)
• examples/tokens/token_unpause_transaction.py (8 hunks)
• examples/tokens/token_update_nfts_transaction_nfts.py (5 hunks)
• examples/tokens/token_update_transaction_fungible.py (5 hunks)
• examples/tokens/token_update_transaction_key.py (6 hunks)
• examples/tokens/token_update_transaction_nft.py (5 hunks)
• examples/tokens/token_wipe_transaction.py (7 hunks)

🧰 Additional context used

🧬 Code graph analysis (25)

examples/tokens/token_fee_schedule_update_transaction_nft.py (4)

src/hiero_sdk_python/tokens/token_create_transaction.py (3)

• TokenCreateTransaction (207-585)
• TokenParams (36-67)
• TokenKeys (71-93)

src/hiero_sdk_python/tokens/token_type.py (1)

• TokenType (11-14)

src/hiero_sdk_python/tokens/supply_type.py (1)

• SupplyType (11-19)

src/hiero_sdk_python/tokens/token_fee_schedule_update_transaction.py (1)

• TokenFeeScheduleUpdateTransaction (24-100)

examples/tokens/token_update_transaction_key.py (2)

src/hiero_sdk_python/query/token_info_query.py (1)

• TokenInfoQuery (11-131)

tests/unit/token_info_test.py (1)

• token_info (19-33)

examples/tokens/token_create_transaction_admin_key.py (2)

src/hiero_sdk_python/response_code.py (1)

• ResponseCode (4-387)

src/hiero_sdk_python/query/token_info_query.py (1)

• TokenInfoQuery (11-131)

examples/tokens/token_create_transaction_freeze_key.py (4)

examples/tokens/token_create_transaction_max_automatic_token_associations_0.py (1)

• associate_token (163-181)

examples/tokens/token_grant_kyc_transaction.py (1)

• associate_token (78-96)

examples/tokens/token_revoke_kyc_transaction.py (1)

• associate_token (81-99)

examples/tokens/token_wipe_transaction.py (1)

• associate_token (111-131)

examples/tokens/token_burn_transaction_fungible.py (3)

src/hiero_sdk_python/client/client.py (2)

• Client (25-169)
• set_operator (63-68)

src/hiero_sdk_python/query/token_info_query.py (1)

• TokenInfoQuery (11-131)

src/hiero_sdk_python/tokens/token_burn_transaction.py (1)

• TokenBurnTransaction (20-183)

examples/tokens/token_airdrop_transaction_cancel.py (4)

src/hiero_sdk_python/response_code.py (1)

• ResponseCode (4-387)

src/hiero_sdk_python/account/account_id.py (1)

• AccountId (21-198)

src/hiero_sdk_python/query/account_balance_query.py (1)

• CryptoGetAccountBalanceQuery (10-138)

src/hiero_sdk_python/tokens/token_airdrop_transaction.py (1)

• TokenAirdropTransaction (21-125)

examples/tokens/token_reject_transaction_nft.py (3)

src/hiero_sdk_python/tokens/token_associate_transaction.py (1)

• TokenAssociateTransaction (23-176)

src/hiero_sdk_python/tokens/token_reject_transaction.py (1)

• TokenRejectTransaction (24-158)

src/hiero_sdk_python/tokens/nft_id.py (1)

• NftId (17-105)

examples/tokens/token_reject_transaction_fungible_token.py (5)

src/hiero_sdk_python/tokens/token_associate_transaction.py (1)

• TokenAssociateTransaction (23-176)

src/hiero_sdk_python/tokens/token_reject_transaction.py (1)

• TokenRejectTransaction (24-158)

src/hiero_sdk_python/account/account_id.py (1)

• AccountId (21-198)

src/hiero_sdk_python/transaction/transaction_receipt.py (1)

• account_id (86-98)

src/hiero_sdk_python/query/account_balance_query.py (1)

• CryptoGetAccountBalanceQuery (10-138)

examples/tokens/token_revoke_kyc_transaction.py (2)

src/hiero_sdk_python/tokens/token_associate_transaction.py (1)

• TokenAssociateTransaction (23-176)

src/hiero_sdk_python/tokens/token_revoke_kyc_transaction.py (1)

• TokenRevokeKycTransaction (21-152)

examples/tokens/token_grant_kyc_transaction.py (1)

src/hiero_sdk_python/tokens/token_grant_kyc_transaction.py (1)

• TokenGrantKycTransaction (21-153)

examples/tokens/token_delete_transaction.py (3)

examples/tokens/token_create_transaction_admin_key.py (1)

• setup_client (42-57)

examples/tokens/token_create_transaction_fungible_infinite.py (1)

• setup_client (35-50)

examples/tokens/token_create_transaction_nft_infinite.py (1)

• setup_client (25-38)

examples/tokens/token_airdrop_transaction.py (9)

src/hiero_sdk_python/account/account_id.py (1)

• AccountId (21-198)

src/hiero_sdk_python/crypto/private_key.py (1)

• PrivateKey (14-471)

src/hiero_sdk_python/hbar.py (1)

• Hbar (18-174)

src/hiero_sdk_python/tokens/token_create_transaction.py (1)

• TokenCreateTransaction (207-585)

src/hiero_sdk_python/tokens/token_airdrop_transaction.py (1)

• TokenAirdropTransaction (21-125)

src/hiero_sdk_python/tokens/token_associate_transaction.py (1)

• TokenAssociateTransaction (23-176)

src/hiero_sdk_python/response_code.py (1)

• ResponseCode (4-387)

src/hiero_sdk_python/query/transaction_record_query.py (1)

• TransactionRecordQuery (14-201)

src/hiero_sdk_python/query/account_info_query.py (1)

• AccountInfoQuery (11-131)

examples/tokens/token_create_transaction_token_fee_schedule_key.py (1)

src/hiero_sdk_python/tokens/token_fee_schedule_update_transaction.py (1)

• TokenFeeScheduleUpdateTransaction (24-100)

examples/tokens/token_unpause_transaction.py (4)

src/hiero_sdk_python/query/token_info_query.py (1)

• TokenInfoQuery (11-131)

src/hiero_sdk_python/account/account_id.py (1)

• AccountId (21-198)

src/hiero_sdk_python/client/client.py (1)

• Client (25-169)

src/hiero_sdk_python/tokens/token_id.py (1)

• TokenId (21-180)

examples/tokens/token_wipe_transaction.py (3)

src/hiero_sdk_python/account/account_id.py (1)

• AccountId (21-198)

src/hiero_sdk_python/response_code.py (1)

• ResponseCode (4-387)

src/hiero_sdk_python/transaction/transfer_transaction.py (1)

• TransferTransaction (23-226)

examples/tokens/custom_fee_fixed.py (2)

src/hiero_sdk_python/account/account_id.py (1)

• AccountId (21-198)

src/hiero_sdk_python/tokens/token_id.py (1)

• TokenId (21-180)

examples/tokens/custom_fee_royalty.py (4)

src/hiero_sdk_python/tokens/custom_fixed_fee.py (1)

• CustomFixedFee (21-288)

src/hiero_sdk_python/tokens/custom_royalty_fee.py (1)

• CustomRoyaltyFee (17-176)

src/hiero_sdk_python/account/account_id.py (1)

• AccountId (21-198)

src/hiero_sdk_python/tokens/token_id.py (1)

• TokenId (21-180)

examples/tokens/token_dissociate_transaction.py (2)

src/hiero_sdk_python/query/account_info_query.py (1)

• AccountInfoQuery (11-131)

src/hiero_sdk_python/tokens/token_dissociate_transaction.py (3)

• set_account_id (55-59)
• TokenDissociateTransaction (27-149)
• set_token_ids (67-72)

examples/tokens/token_burn_transaction_nft.py (2)

src/hiero_sdk_python/query/token_info_query.py (1)

• TokenInfoQuery (11-131)

src/hiero_sdk_python/tokens/token_burn_transaction.py (2)

• TokenBurnTransaction (20-183)
• set_serials (77-89)

examples/tokens/token_update_transaction_nft.py (2)

examples/tokens/account_allowance_approve_transaction.py (1)

• setup_client (32-43)

examples/tokens/token_airdrop_transaction.py (1)

• setup_client (32-48)

examples/tokens/token_create_transaction_wipe_key.py (2)

src/hiero_sdk_python/tokens/nft_id.py (1)

• NftId (17-105)

src/hiero_sdk_python/tokens/token_wipe_transaction.py (2)

• TokenWipeTransaction (22-170)
• set_serial (95-107)

examples/tokens/token_unfreeze_transaction.py (2)

src/hiero_sdk_python/crypto/private_key.py (1)

• PrivateKey (14-471)

src/hiero_sdk_python/response_code.py (1)

• ResponseCode (4-387)

examples/tokens/custom_fee_fractional.py (1)

src/hiero_sdk_python/tokens/token_create_transaction.py (2)

• TokenCreateTransaction (207-585)
• TokenParams (36-67)

examples/tokens/token_mint_transaction_non_fungible.py (1)

src/hiero_sdk_python/response_code.py (1)

• ResponseCode (4-387)

examples/tokens/token_mint_transaction_fungible.py (1)

src/hiero_sdk_python/response_code.py (1)

• ResponseCode (4-387)

🪛 Ruff (0.14.8)

examples/tokens/token_fee_schedule_update_transaction_nft.py

106-106: Do not catch blind exception: Exception

(BLE001)

examples/tokens/token_update_transaction_key.py

113-113: f-string without any placeholders

Remove extraneous f prefix

(F541)

examples/tokens/token_create_transaction_kyc_key.py

489-489: Local variable transfer_without_kyc_result is assigned to but never used

Remove assignment to unused variable transfer_without_kyc_result

(F841)

examples/tokens/token_update_transaction_fungible.py

116-116: f-string without any placeholders

Remove extraneous f prefix

(F541)

---

143-143: Possible hardcoded password assigned to: "update_token_name"

(S105)

---

144-144: Possible hardcoded password assigned to: "update_token_symbol"

(S105)

---

145-145: Possible hardcoded password assigned to: "update_token_memo"

(S105)

examples/tokens/token_airdrop_transaction_cancel.py

50-50: Do not perform function call Hbar.from_tinybars in argument defaults; instead, perform the call within the function, or read the default from a module-level singleton variable

(B008)

---

115-115: Use explicit conversion flag

Replace with conversion flag

(RUF010)

---

148-148: Use explicit conversion flag

Replace with conversion flag

(RUF010)

examples/tokens/token_create_transaction_supply_key.py

90-90: Consider moving this statement to an else block

(TRY300)

---

162-162: Consider moving this statement to an else block

(TRY300)

---

164-164: Do not catch blind exception: Exception

(BLE001)

examples/tokens/token_create_transaction_fungible_finite.py

42-42: Do not catch blind exception: Exception

(BLE001)

examples/tokens/token_delete_transaction.py

36-36: Consider moving this statement to an else block

(TRY300)

examples/tokens/token_airdrop_transaction.py

45-45: Consider moving this statement to an else block

(TRY300)

---

333-333: Do not catch blind exception: Exception

(BLE001)

---

489-489: Use explicit conversion flag

Replace with conversion flag

(RUF010)

---

489-489: Use explicit conversion flag

Replace with conversion flag

(RUF010)

---

489-489: Use explicit conversion flag

Replace with conversion flag

(RUF010)

---

492-492: Use explicit conversion flag

Replace with conversion flag

(RUF010)

---

492-492: Use explicit conversion flag

Replace with conversion flag

(RUF010)

---

492-492: Use explicit conversion flag

Replace with conversion flag

(RUF010)

---

492-492: Use explicit conversion flag

Replace with conversion flag

(RUF010)

examples/tokens/token_create_transaction_token_fee_schedule_key.py

148-148: Unpacked variable operator_key is never used

Prefix it with an underscore or any other dummy variable pattern

(RUF059)

---

179-179: Do not catch blind exception: Exception

(BLE001)

examples/tokens/token_unpause_transaction.py

74-74: Consider moving this statement to an else block

(TRY300)

---

75-75: Do not catch blind exception: Exception

(BLE001)

examples/tokens/token_airdrop_claim_auto.py

76-76: Avoid specifying long messages outside the exception class

(TRY003)

---

230-230: Do not catch blind exception: Exception

(BLE001)

---

300-302: Abstract raise to an inner function

(TRY301)

---

300-302: Avoid specifying long messages outside the exception class

(TRY003)

---

310-310: Avoid specifying long messages outside the exception class

(TRY003)

---

348-348: Unpacked variable receiver_key is never used

Prefix it with an underscore or any other dummy variable pattern

(RUF059)

examples/tokens/token_dissociate_transaction.py

107-107: Consider moving this statement to an else block

(TRY300)

examples/tokens/token_update_transaction_nft.py

116-116: f-string without any placeholders

Remove extraneous f prefix

(F541)

---

141-141: Possible hardcoded password assigned to: "update_token_name"

(S105)

---

142-142: Possible hardcoded password assigned to: "update_token_symbol"

(S105)

---

143-143: Possible hardcoded password assigned to: "update_token_memo"

(S105)

examples/tokens/token_create_transaction_wipe_key.py

62-62: Consider moving this statement to an else block

(TRY300)

---

215-215: Consider moving this statement to an else block

(TRY300)

---

217-217: Do not catch blind exception: Exception

(BLE001)

examples/tokens/custom_fee_fractional.py

49-49: Avoid specifying long messages outside the exception class

(TRY003)

examples/tokens/token_airdrop_claim_signature_required.py

83-83: Avoid specifying long messages outside the exception class

(TRY003)

---

362-364: Abstract raise to an inner function

(TRY301)

---

362-364: Avoid specifying long messages outside the exception class

(TRY003)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Codacy Static Code Analysis

🔇 Additional comments (99)

CHANGELOG.md (2)

67-67: Changelog entry properly formatted and positioned.

The entry is well-placed in the "Changed" section, correctly references issue #1119, and follows the project's changelog conventions.

---

67-67: Verify that functional changes are accounted for separately in the changelog.

The AI-generated summary indicates that some token example files contain functional/behavioral changes (e.g., token_create_transaction_fungible_finite.py now returns a tuple from setup_client, and token_create_transaction_nft_infinite.py has error handling changes), which extend beyond Black's formatting scope. If these are intentional changes included in this PR, they may warrant separate changelog entries under "Changed" or "Fixed" sections for clarity.

examples/tokens/token_mint_transaction_fungible.py (3)

1-147: Formatting changes approved—consistent with Black standards.

All modifications in this file are standard Black formatter output: quote normalization (single→double), trailing comma in multiline import (line 22), multi-line print wrapping (lines 123–125), and blank line adjustments. These changes have no semantic impact on runtime behavior or token minting logic. Code functionality remains identical.

---

22-22: String quote normalization applied consistently.

Black's default quote style (double quotes) has been applied uniformly across os.getenv() calls and the getattr() invocation. This is a cosmetic change with no functional impact.

Also applies to: 27-27, 37-38, 50-50, 86-86

---

123-125: Multi-line print statement wrapping improves readability.

The print statement spanning lines 123–125 follows Black's line-length guidelines. The logical structure and semantics remain unchanged.

examples/tokens/token_update_transaction_key.py (1)

1-145: Black formatting applied correctly.

The file has been properly formatted by Black with normalized quote styles, optimized whitespace, and multi-line statement restructuring. Apart from the f-string issue noted above, the formatting changes align with Black standards and preserve the original logic and functionality.

examples/tokens/token_create_transaction_pause_key.py (3)

109-111: Black formatting applied correctly.

The print statement has been properly wrapped to conform to Black's line length constraints. No logic changes.

---

215-217: Function signature reformatted per Black standards.

The function parameters have been wrapped across lines without any semantic changes. Parameter order and types are preserved.

---

235-238: Proper PEP 8 spacing applied.

Extra blank line added before the main section header aligns with Black's PEP 8 compliance standards.

examples/tokens/token_unpause_transaction.py (1)

1-142: ✅ Black formatting applied correctly.

The formatting changes conform to Black conventions: multi-line import restructuring, proper function spacing (2 blank lines between functions), and improved code organization. The TokenInfoQuery import addition (Line 22) is necessary—it's used in check_pause_status() at Line 107.

examples/tokens/token_fee_schedule_update_transaction_nft.py (5)

1-22: Black formatting applied correctly to imports and docstring.

The import restructuring (lines 10–14, 17–19) follows Black's multi-line import grouping standard for readability. Docstring and import organization are now idiomatic.

---

25-41: setup_client() formatting and structure are sound.

Function setup and environment loading follow the expected pattern. Exception handling is present, though catching bare Exception is broad.

---

44-77: create_nft() formatting preserves logic and improves readability.

Trailing commas (line 56) and consistent spacing maintain semantic equivalence. Token creation flow and key assignment are correct.

---

80-108: Fee schedule update logic and formatting are correct.

Multi-line chaining (line 91–95, 97) and custom fee construction (line 84–88) are formatted idiomatically. Execution and error handling flow as expected.

---

146-169: main() orchestration is clear after formatting.

Function flow, resource cleanup, and exception propagation are correct. Black formatting improves readability of the control flow.

examples/tokens/token_mint_transaction_non_fungible.py (1)

28-29: LGTM! Black formatting applied correctly.

All changes are cosmetic formatting improvements applied by Black, including quote normalization to double quotes, consistent blank line spacing, and multi-line statement formatting. These changes improve code consistency without affecting functionality.

Also applies to: 38-39, 51-51, 55-55, 57-57, 84-85, 111-111, 118-120, 128-128, 140-140

examples/tokens/token_create_transaction_token_metadata.py (2)

117-118: LGTM!

The formatting adjustment in the else branch is consistent with Black's output.

---

219-220: LGTM!

Whitespace normalization is consistent with Black formatting.

examples/tokens/token_unfreeze_transaction.py (6)

8-28: LGTM!

The formatting adjustments (blank line after docstring, consistent spacing) align with Black and PEP 8 conventions.

---

36-45: LGTM!

Environment variable retrieval and error handling logic unchanged. Formatting is correct.

---

48-81: LGTM!

Proper blank line spacing between functions and method chain formatting. No functional changes.

---

95-97: LGTM!

Print statement correctly wrapped to comply with line length. The f-string logic is preserved.

---

103-141: LGTM!

Multiple print statements wrapped for line length compliance. Nested exception handling and transfer logic remain intact.

---

143-155: LGTM!

Docstring formatting and blank line spacing before the entry point block follow Black conventions.

examples/tokens/token_reject_transaction_nft.py (1)

1-255: LGTM! Black formatting successfully applied.

All formatting changes are consistent with Black's code style standards, including quote normalization, multi-line import formatting, and proper whitespace adjustments. The code logic remains unchanged, and readability is improved through standardized formatting.

examples/tokens/token_create_transaction_supply_key.py (4)

18-55: ✅ Imports and setup formatting look good.

Black formatting applied cleanly with no functional changes to client initialization or environment variable retrieval.

---

97-122: ✅ Demonstrate mint fail formatting is clean.

Black formatting applied correctly with proper line wrapping and print statement expansion. No functional changes.

---

169-193: ✅ Demonstrate mint success formatting is correct.

Black formatting applied consistently. No functional changes.

---

195-223: ✅ Query and main function formatting is clean.

Black formatting applied correctly with proper line wrapping and spacing. No functional changes detected.

examples/tokens/account_allowance_approve_transaction.py (11)

20-22: LGTM! Import formatting improved.

Multi-line import format improves readability and is consistent with Black's formatting standards.

---

29-29: LGTM! Whitespace adjustment.

Added blank line improves code spacing per Black formatting standards.

---

60-62: LGTM! Print statement formatting improved.

Multi-line format enhances readability for the long error message.

---

107-109: LGTM! Consistent error message formatting.

Multi-line format matches the pattern used elsewhere in the file.

---

115-117: LGTM! Function signature formatting improved.

Multi-line parameter layout enhances readability.

---

126-128: LGTM! Consistent formatting.

Error message formatting matches the established pattern.

---

144-146: LGTM! Consistent error handling format.

Maintains the multi-line pattern for error messages throughout the file.

---

153-160: LGTM! Function signature readability improved.

One parameter per line format makes the function signature much clearer.

---

164-166: LGTM! Multi-line format with preserved comment.

The inline comment is properly maintained while improving line length.

---

181-183: LGTM! Print statement formatting.

Multi-line format improves readability of the success message.

---

223-225: LGTM! Method call formatting improved.

Multi-line format enhances readability of the chained method calls.

examples/tokens/token_airdrop_transaction_cancel.py (3)

22-22: LGTM: Black formatting applied correctly.

The trailing comma added to the import list aligns with Black's formatting conventions.

---

28-28: LGTM: Black formatting applied correctly.

Quote normalization from single to double quotes follows Black's default style conventions.

Also applies to: 38-39

---

91-91: LGTM: Black formatting applied correctly.

Spacing normalization and multiline function call formatting are consistent with Black's conventions.

Also applies to: 194-196, 203-203

examples/tokens/token_create_transaction_freeze_key.py (1)

199-203: LGTM! Black formatting applied correctly.

All changes are purely cosmetic formatting adjustments that improve code consistency and readability. The reformatted function signatures, multi-line function calls, and split print statements align with Black's style guidelines without altering any functional behavior.

Per the acceptance criteria in issue #1119, please confirm:

• All CI tests (unit/integration) pass
• A changelog entry has been added
• Commits are DCO and GPG signed

You can verify CI status and commit signatures with:

#!/bin/bash
# Check CI status for this PR
gh pr view 1127 --json statusCheckRollup --jq '.statusCheckRollup[] | select(.status != "COMPLETED" or .conclusion != "SUCCESS") | {name: .name, status: .status, conclusion: .conclusion}'

# Verify commit signatures
gh pr view 1127 --json commits --jq '.commits[] | {sha: .oid, message: .messageHeadline, signed: .committedViaWeb}'

Also applies to: 313-315, 326-332, 352-354, 402-404

examples/tokens/token_airdrop_claim_signature_required.py (3)

55-88: LGTM! Formatting changes align with Black style.

The import addition, quote normalization, and blank line adjustments are consistent with Black's formatting standards. The TransactionId import is properly used in function type hints (line 376).

---

90-91: LGTM! Multi-line formatting improves readability.

Black's multi-line formatting has been applied consistently across function signatures, query expressions, and long statements. This enhances code readability without altering functionality.

Also applies to: 123-131, 160-167, 197-201, 228-230, 236-243, 301-306, 331-339, 362-364, 375-377, 386-388, 400-408

---

453-541: LGTM! Consistent formatting applied throughout main() and helper calls.

The function call formatting, comment adjustments, and blank line spacing in the main execution flow are all consistent with Black's style guidelines. No functional changes detected.

examples/tokens/token_grant_kyc_transaction.py (1)

1-6: Cosmetic formatting update consistent with Black.

The import statement reformatting, quote normalization, and blank line adjustments are all standard Black formatter outputs. No functional changes detected.

examples/tokens/token_revoke_kyc_transaction.py (1)

1-33: Verify multi-line import formatting aligns with Black standards.

Import restructuring (lines 22–28) appears consistent with Black, but confirm that the parenthesized multi-line format matches your project's Black configuration (line length, trailing commas, etc.).

examples/tokens/token_wipe_transaction.py (1)

1-196: LGTM! Black formatting applied correctly.

All changes are cosmetic formatting improvements consistent with Black's preference for double quotes over single quotes:

• Blank lines added between logical sections and functions (PEP 8 compliance)
• Quote normalization in string literals
• Multi-line statement reformatting for consistency

No functional changes introduced.

examples/tokens/token_create_transaction_wipe_key.py (4)

46-46: LGTM - Black quote normalization.

The quote changes from single to double quotes for environment variable names are standard Black formatting. No functional impact.

Also applies to: 58-59

---

56-69: LGTM - Black formatting improvements.

The whitespace adjustments, line wrapping, and multi-line string formatting throughout the file are consistent with Black standards and improve readability without changing functionality.

Also applies to: 83-86, 105-107, 120-122, 147-150, 176-182, 209-212, 231-233, 331-333, 360-362

---

373-375: LGTM - Proper end-of-file formatting.

The file ends with a proper newline as per Black standards.

---

38-38: Remove trailing comma formatting note - NftId was already imported.

Line 38 contains only a formatting change: a trailing comma is added after NftId to comply with Black's multi-line import formatting. The NftId import was already present in the original file. This change is within scope and does not represent a new functional addition.

examples/tokens/token_create_transaction_fungible_infinite.py (1)

1-112: LGTM! Formatting changes look correct.

The Black formatting has been properly applied:

• Double quotes standardized for string literals
• Appropriate line wrapping for the success message print statement
• Consistent blank line spacing

examples/tokens/token_burn_transaction_nft.py (1)

1-143: LGTM! Black formatting correctly applied.

Formatting changes include:

• Consistent double-quote usage for environment variable defaults
• Proper blank line spacing between functions and code blocks
• Multi-line wrapping for the NFT burn success message

examples/tokens/custom_fee_royalty.py (1)

1-34: LGTM! Clean formatting adjustments.

Minor Black formatting changes applied:

• Docstring formatting updated
• Blank line spacing normalized
• Function call indentation adjusted

examples/tokens/token_burn_transaction_fungible.py (1)

1-120: LGTM! Formatting is consistent with Black standards.

Changes applied:

• Double-quote standardization for environment variable defaults
• Multi-line formatting for long print statements
• Consistent blank line spacing throughout

examples/tokens/token_create_transaction_nft_infinite.py (1)

1-112: LGTM! Black formatting properly applied.

Formatting updates include:

• Consistent blank line spacing around module-level docstrings and functions
• Multi-line wrapping for the success print statement
• Comment alignment adjusted

Note: The control flow logic (exit on missing token_id at lines 90-92) appears unchanged; only the success message print formatting above it was modified.

examples/tokens/token_create_transaction_nft_finite.py (1)

32-33: LGTM! Formatting changes align with Black's style.

The double-quote standardization and multi-line print formatting are consistent with Black's defaults and improve readability.

Also applies to: 42-43, 91-93

examples/tokens/token_associate_transaction.py (1)

29-29: LGTM! Consistent Black formatting applied.

The blank line adjustments and multi-line function signature formatting follow Black's style conventions.

Also applies to: 57-57, 98-98, 140-140, 176-178

examples/tokens/token_update_transaction_nft.py (1)

25-26: LGTM! Formatting changes are consistent with Black.

The double-quote standardization, multi-line function signatures, and call site formatting improve readability and follow Black conventions.

Also applies to: 34-35, 91-98, 145-152

examples/tokens/token_create_transaction_admin_key.py (1)

39-39: LGTM! Black formatting applied consistently.

The quote standardization, multi-line print formatting, and method chaining style are appropriate.

Also applies to: 49-50, 143-148, 176-178, 211-211

examples/tokens/custom_fee_fixed.py (1)

2-2: LGTM! Minor formatting adjustments applied.

The blank line and docstring formatting changes follow Black conventions.

Also applies to: 6-6, 11-11, 24-24, 26-29

examples/tokens/token_freeze_transaction.py (1)

26-27: LGTM! Comprehensive Black formatting applied.

The double-quote standardization, multi-line print formatting, and whitespace adjustments are consistent with Black's style.

Also applies to: 36-37, 49-49, 53-53, 65-65, 72-72, 92-92, 94-94, 97-100, 105-105, 124-130, 136-136, 144-146, 150-150

examples/tokens/token_create_transaction_kyc_key.py (1)

22-22: LGTM! Extensive Black formatting applied.

The multi-line imports, function signatures, and call site formatting improve readability while maintaining consistent style throughout the file.

Also applies to: 39-46, 52-52, 66-67, 103-104, 147-149, 230-232, 260-262, 271-273, 293-293, 320-322, 349-349, 375-375, 402-402, 428-430, 461-463, 466-469, 471-472, 475-477, 483-486, 494-494, 500-502, 505-505

examples/tokens/custom_fee_fractional.py (1)

2-2: LGTM! Black formatting and environment validation improvements.

The multi-line imports, double-quote standardization, and whitespace adjustments follow Black conventions. The added environment variable validation (lines 34-36) improves error handling.

Also applies to: 11-14, 29-29, 43-44, 54-54, 66-67, 83-83, 87-87, 91-91, 96-96, 106-106, 113-113, 119-119, 124-125

examples/tokens/token_create_transaction_fungible_finite.py (1)

1-131: LGTM! Black formatting applied successfully.

The formatting changes are purely cosmetic and improve code consistency across the file. Quote normalization to double quotes and multi-line formatting enhance readability without altering behavior.

examples/tokens/token_update_transaction_fungible.py (1)

1-162: LGTM! Formatting improvements applied consistently.

Black formatting has been applied throughout the file with quote normalization, improved line wrapping for function signatures and calls, and consistent blank line spacing. No behavioral changes detected.

examples/tokens/token_create_transaction_max_automatic_token_associations_0.py (1)

84-90: LGTM! Improved readability with Black formatting.

The multi-line function signature and print statement formatting enhance readability. The blank line before the if __name__ block follows PEP 8 conventions.

Also applies to: 245-247

examples/tokens/token_fee_schedule_update_transaction_fungible.py (1)

1-161: LGTM! Black formatting applied consistently.

Import statements, environment variable handling, and function calls have been reformatted for improved readability. All changes are cosmetic with no impact on functionality.

examples/tokens/token_reject_transaction_fungible_token.py (2)

76-76: Nice addition of type hint!

The type hint client: "Client" improves type safety and IDE support. This is a positive enhancement alongside the formatting changes.

---

1-223: LGTM! Black formatting applied with consistent improvements.

Quote normalization, import reformatting, and multi-line expression formatting have been applied consistently throughout the file. All changes are cosmetic and improve readability.

examples/tokens/token_update_nfts_transaction_nfts.py (1)

1-181: LGTM! Black formatting enhances consistency.

Import statements, function signatures, and return statements have been reformatted for improved readability. All changes are cosmetic with no behavioral impact.

examples/tokens/token_airdrop_transaction.py (1)

1-581: LGTM! Comprehensive Black formatting applied.

Extensive formatting improvements throughout, including multi-line imports, consistent quote usage, and well-structured multi-line expressions. The reformatting significantly enhances readability without altering any logic.

examples/tokens/token_dissociate_transaction.py (1)

1-223: LGTM! Black formatting applied with improved documentation.

Quote normalization, multi-line formatting for long expressions, and inline comments enhance both consistency and clarity. All changes are cosmetic improvements.

examples/tokens/token_airdrop_claim_auto.py (11)

34-51: LGTM!

Import formatting follows Black conventions with proper line breaks and trailing comma on the last import.

---

56-79: LGTM!

The setup_client function is correctly formatted. The static analysis hint about long exception messages (TRY003) is a style preference that's acceptable for example/demo code where verbose error messages aid understanding.

---

82-84: LGTM!

Function signature properly formatted by Black with parameters on separate lines.

---

114-146: LGTM!

Black formatting correctly applied to function signature with trailing comma. The status check pattern (accessing token_id before checking status) is preserved from existing code.

---

149-181: LGTM!

Consistent formatting applied to create_nft_token function signature matching the pattern used in create_fungible_token.

---

184-210: LGTM!

Function signature properly formatted. The blank lines at 210-211 follow Black's convention of two blank lines between top-level definitions.

---

212-266: LGTM!

The log_balances function is correctly formatted. The broad exception catch at line 230 is intentional for this example code, as indicated by the inline pylint disable comment.

---

268-311: LGTM!

The perform_airdrop function signature and error handling strings are correctly formatted by Black. The static analysis hints (TRY003, TRY301) are style preferences that are acceptable for example/demo code.

---

320-338: LGTM!

Function calls correctly reformatted with named parameters on separate lines and trailing commas, following Black's style for improved readability and easier diff reviews.

---

352-364: LGTM!

The log_balances and perform_airdrop calls are properly formatted with arguments on separate lines.

---

379-390: LGTM!

Final print statements and main guard are correctly formatted.

examples/tokens/token_create_transaction_token_fee_schedule_key.py (2)

22-26: Black formatting applied correctly.

The multi-line import restructuring follows Black's style guide and improves readability.

Also applies to: 29-31

---

128-132: Chained method call formatting is clean.

The transaction builder chaining is properly formatted and maintains readability.

examples/tokens/token_pause_transaction.py (10)

6-11: LGTM! Formatting changes consistent with Black.

The blank line after the module docstring and the single-line import statement are consistent with Black's formatting style.

---

21-22: LGTM! Quote normalization and spacing.

The standardization to double quotes and the added blank line are consistent with Black's formatting conventions.

---

32-33: LGTM! Consistent quote normalization.

The standardization to double quotes in the os.getenv calls follows Black's formatting rules.

---

39-56: LGTM! Proper function spacing.

The blank lines added between top-level functions follow PEP 8 guidelines (2 blank lines between top-level definitions) and are consistent with Black formatting.

---

70-81: LGTM! Improved readability in token creation.

The blank lines added between logical sections (transaction creation, execution, assertion, and result printing) improve code readability and are consistent with Black's formatting.

---

84-100: LGTM! Consistent formatting in pause functionality.

The blank lines added improve code organization and readability, separating function definitions and logical sections within the pause_token function. All changes are consistent with Black's formatting rules.

---

107-124: LGTM! Proper function spacing maintained.

The blank lines between function definitions follow PEP 8 guidelines and maintain consistent spacing throughout the file, as expected with Black formatting.

---

135-140: LGTM! Clear variable assignments.

The formatting of variable assignments with inline comments and the blank line separating logical sections maintain good readability and follow Black's conventions.

---

150-152: LGTM! Proper line wrapping for long strings.

The multiline formatting of the print statement keeps the line within Black's default line length limit (88 characters), improving code readability and consistency.

---

156-158: File formatting is consistent with Black style conventions.

The blank lines and overall formatting in this new file align with Black's module-level spacing standards.

[exploreriii]

super! thank you so much !