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.