Python-Funktion nach Rust portieren
Portiert eine Python-Funktion idiomatisch nach Rust - mit Hinweis auf Ownership-Unterschiede und was nicht 1:1 geht.
Zuletzt geprüft 23. April 2026
Prompt
Port this Python function to idiomatic Rust. Process: 1. CONTRACT - what the function does, in plain terms, before writing code. Types, inputs, outputs, side effects, error conditions. 2. RUST CHOICES - decisions you're making: - String vs &str, Vec vs slice - Result<T, E> with what error type - Ownership (clone? borrow? consume?) - iter vs collect vs loop 3. CODE - the Rust port, idiomatic not transliterated 4. WHAT IS DIFFERENT - behavioral differences from the Python (if any). For example: Python dict ordering vs HashMap, integer overflow, default Float comparison 5. TESTS - 3-5 tests that exercise the same cases as the original Python logic Rules: - No `clone()` unless justified - explain when used - Error type: real enum, not `Box<dyn Error>` unless genuinely open - No `unwrap()` except in tests - Prefer iterator chains over loops where readable - If a Python feature has no clean Rust equivalent (e.g. `**kwargs`, duck typing), say so and show the pragmatic version - Do not over-engineer - match the function's scope Python function: [PASTE] Calling context (how it's used): [OPTIONAL]
Wann nutzen
Für Migrations-Experimente oder einzelne Hot-Path-Funktionen. Der Contract-Schritt vor dem Code macht den Unterschied zwischen Port und Rewrite.
Use-Cases
- Perf-kritische Python-Funktion in Rust testen.
- Lernen: idiomatisches Rust durch Vergleich mit bekanntem Python.
- PyO3-Bindings-Kandidat identifizieren.
Getestet mit
Bei komplexen Typen (NumPy-Arrays, Pandas-DataFrames): nicht portieren, sondern kapseln. Das Modell sollte das explizit sagen.