Python/Rust boundaries

Treat the Python/Rust boundary as an ownership, execution and distribution contract. Check the installed PyO3/Python/numpy versions and GIL-enabled versus free-threaded build first.

Work from the affected contract

1. Trace ownership of Python handles, Rust data, NumPy views and retained resources. State what can outlive the call or interpreter and who may mutate shared buffers.
2. Separate Python-object access from Rust-only work. Select attach/detach and synchronization rules for the actual build; measure crossing and detach costs rather than using universal timing thresholds.
3. Map typed Rust errors to useful Python exceptions and preserve actionable tracebacks. Specify panic policy rather than swallowing unsafe or corrupted state.
4. For async/resource ownership, trace cancellation, executor/thread affinity, callback access and shutdown order. Exercise import/exit and partial initialization failures.
5. Choose ABI/wheel targets from consumer needs and supported features. Verify import, minimal operation, distribution matrix and measured payoff on representative workloads.

Scope and completion

Deliver the boundary contract, version/build assumptions, targeted repair/design and observed checks. Keep batching, zero-copy and abi3 as measured choices with ownership/compatibility conditions. Rust acceleration is justified by whole-call cost and required behavior, not language reputation.

Use the user’s existing intent and authorization. Ask only for missing information that materially changes the result; use additional reviewers when they address a concrete uncertainty. Treat unavailable checks as gaps rather than successful verification.

Focused references