Actionable comments posted: 0

crates/vm/src/stdlib/io.rs (1)

1761-1771: Consider a macro for Destructor implementations (optional).

There are now 7 nearly identical Destructor implementations. A macro could reduce duplication:

macro_rules! impl_io_destructor {
    ($type:ty) => {
        impl Destructor for $type {
            fn slot_del(zelf: &PyObject, vm: &VirtualMachine) -> PyResult<()> {
                let _ = vm.call_method(zelf, "close", ());
                Ok(())
            }

            #[cold]
            fn del(_zelf: &Py<Self>, _vm: &VirtualMachine) -> PyResult<()> {
                unreachable!("slot_del is implemented")
            }
        }
    };
}

However, this is entirely optional — the current explicit implementations are clear and maintainable.

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Reviewing files that changed from the base of the PR and between ac48643 and a47ecd7.

• Lib/test/test_io.py is excluded by !Lib/**

• .github/workflows/ci.yaml (0 hunks)
• crates/vm/src/stdlib/io.rs (10 hunks)

• .github/workflows/ci.yaml

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.rs: Follow the default rustfmt code style by running cargo fmt to format Rust code
Always run clippy to lint Rust code (cargo clippy) before completing tasks and fix any warnings or lints introduced by changes
Follow Rust best practices for error handling and memory management
Use the macro system (pyclass, pymodule, pyfunction, etc.) when implementing Python functionality in Rust

Files:

• crates/vm/src/stdlib/io.rs

Learnt from: CR
Repo: RustPython/RustPython PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-29T12:17:28.606Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust

Applied to files:

• crates/vm/src/stdlib/io.rs

crates/vm/src/stdlib/io.rs (8)

1755-1771: LGTM!

The Destructor implementation for BufferedReader correctly follows the established pattern from _IOBase, properly swallowing errors from close() which is appropriate behavior for a destructor.

---

1824-1840: LGTM!

Consistent Destructor implementation for BufferedWriter.

---

1878-1900: LGTM!

Consistent Destructor implementation for BufferedRandom.

---

1944-2003: LGTM!

Consistent Destructor implementation for BufferedRWPair.

---

2476-2479: LGTM!

The pyclass declaration correctly includes Destructor, Iterable, and IterNext traits.

---

3342-3391: LGTM!

The TextIOWrapper implementations are well-designed:

• Destructor: Follows the established pattern.
• Iterable: Correctly checks if closed before returning self as iterator.
• IterNext: Properly sets telling = false during iteration (matching CPython behavior), releases the lock during the readline call to avoid holding it during I/O, and correctly restores state on StopIteration.

---

4284-4292: LGTM!

The necessary imports for Destructor and related types are correctly added.

---

4551-4779: LGTM!

The FileIO Destructor implementation is consistent with the other I/O types and correctly ensures proper cleanup.