port-from-pythonlisted

# Port from Python ## A construct mapping and a boundary, nothing else This skill maps Python to Rust and owns the PyO3 boundary. The parity contract, the five phases, and the anti-patterns are `/port-to-rust`, which runs first and stays running through the port. ## The end state decides whether PyO3 appears at all `/port-to-rust` names three end states, and this is where the choice bites hardest, because Python has the cheapest FFI story and the easiest to reach for uninvited. This skill asks rather than assumes. | End state | In Python terms | PyO3 | |---|---|---| | A. Replacement | A Rust binary or crate replaces the Python entirely; the seam is the CLI, the HTTP route, or the queue consumer that already exists | Never appears | | B. Rust core, Python package is the product | The importable package keeps its name and its signatures; the engine underneath becomes Rust | Permanent public surface — signatures, exception types, wheels per platform, semver | | C. Scaffold | The port ends standalone, but Python calls the Rust module while the migration is under way | Temporary, and deleted at cut-over | ## When there are bindings, the Python seam is unusually good Under B or C, a Rust extension module built with PyO3 and packaged with maturin is importable from the existing Python with no call-site change beyond the import, which makes "port the hot leaf module first, keep the app in Python" a genuinely incremental path rather than a euphemism. Under A none of that applie