Constify some methods and general code cleanups by ShaharNaveh · Pull Request #5812 · RustPython/RustPython

161-161: LGTM! Good formatting improvement.

Adding a blank line here provides better visual separation between the manual 1-tuple Traverse implementation and the macro-generated implementations that follow.

1119-1119: Excellent const fn addition.

Making operator_token a const fn is beneficial as it enables compile-time evaluation for a method that only returns string literals. This allows the method to be used in const contexts and aligns with the PR's objective of adding const fn qualifiers where appropriate.

381-381: Nice refactor to idiomatic Rust.

The change from an explicit loop to using .any() makes the code more concise and idiomatic while preserving the exact same logic. This is a good example of leveraging Rust's iterator methods for cleaner code.

50-50: LGTM! Consistent formatting improvements.

The added blank lines improve readability by providing visual separation within the impl blocks. These formatting changes align well with the PR's code cleanup objectives.

Also applies to: 76-76, 113-113, 187-187

530-534: Use of raw string literal for error formatting
Switching to a raw string literal here simplifies the message by removing escape clutter and is fully equivalent.

1858-1862: Implement is_empty for AnyStrWrapper<Wtf8>
This addition keeps the wrapper API consistent with PyStr and other containers.

1868-1872: Implement is_empty for AnyStrWrapper<str>
Maintains symmetry across all AnyStrWrapper implementations.

1878-1882: Implement is_empty for AnyStrWrapper<AsciiStr>
Ensures the ASCII‐only wrapper also has an emptiness check.

494-494: Skip formatting-only blank line addition
This blank line improves readability but does not impact functionality.

305-305: LGTM: Formatting improvements enhance readability.

The blank lines around trait implementations improve code organization and readability.

Also applies to: 312-312, 359-359, 365-365

347-349: LGTM: Appropriate constification of constructor.

Making KwArgs::new a const fn is correct since it's a simple wrapper constructor that can be evaluated at compile time. This enables better optimization opportunities.

415-417: LGTM: Appropriate constification of constructor.

Making PosArgs::new a const fn is correct since it's a simple wrapper constructor that can be evaluated at compile time. This aligns with the pattern established for KwArgs::new.

110-110: LGTM: Formatting improvement enhances readability.

The blank line in the Deref trait implementation improves code organization.

246-253: LGTM: Appropriate constification of constructor.

Making PyIterIter::new a const fn is correct since it performs simple field initialization that can be evaluated at compile time. This enables better optimization opportunities.

21-23: LGTM: Appropriate constification of wrapper method.

Making to_number a const fn is correct since it's a simple wrapper that creates a PyNumber from self. This can be safely evaluated at compile time.

443-445: LGTM: Appropriate constification of accessor method.

Making obj a const fn is correct since it's a simple accessor that returns the wrapped object reference. This can be safely evaluated at compile time.

54-60: LGTM: Appropriate constification of accessor methods.

Making len and is_empty const fn for ArgBytesLike is correct since they perform simple field access and arithmetic that can be evaluated at compile time. This enables better optimization opportunities.

106-112: LGTM: Appropriate constification of accessor methods.

Making len and is_empty const fn for ArgMemoryBuffer is correct and maintains consistency with the pattern established for ArgBytesLike. These simple operations can be safely evaluated at compile time.