Python für C# Entwickler: Umstiegsschulung für .NET-Teams

Von C# zu Python

• Von C# zu Python: was sich aus der .NET-Praxis übertragen lässt und was nicht
• C# und Python im Vergleich: kompiliert für die CLR gegenüber interpretiert in CPython
• Einsatzfelder nebeneinander: .NET-Dienste, Python für Daten, Skripte und Automatisierung
• Eine Geschichte von zwei Hello Worlds: static void Main und Top-Level-Statements gegenüber Modulcode
• if __name__ == "__main__" als Einstiegspunkt, Ausführen mit uv run
• Kommentare mit # und Docstrings statt XML-Dokumentationskommentaren mit ///
• Docstrings im Google- oder NumPy-Stil, Hilfe mit help() und Anzeige im Editor
• Umfangsblöcke: Einrückung statt geschweifter Klammern, kein eigener Scope je Block
• Geltungsbereiche nach der LEGB-Regel, global und nonlocal

Variablen, Datentypen und Typ-Hinweise

• Variablen als Namen für Objekte: dynamische Typisierung gegenüber statischen Typen und var
• Datentypen im Vergleich: int ohne Überlauf, float als double, Decimal statt decimal
• Werttypen und Referenztypen in C#, veränderliche und unveränderliche Objekte in Python
• None und X | None gegenüber Nullable-Referenztypen und dem Operator ?.
• Typ-Hinweise für Variablen, Parameter und Rückgaben – zur Laufzeit nicht erzwungen
• Generics mit list[int], dict[str, Kunde] und der Typparameter-Syntax class Stapel[T]
• Statische Prüfung mit mypy oder Pyright als Ersatz für die Fehlermeldungen des Compilers
• Pylance in VS Code, Typprüfung in PyCharm und als Schritt in der CI-Pipeline

Bedingungen und Schleifen

• Bedingte Anweisungen mit if/elif/else, Bedingungsausdruck statt ?:
• match/case gegenüber switch-Ausdrücken und Pattern Matching in C#
• Wahrheitswerte: leere Sammlungen, 0 und None gelten als falsch – in C# ein Compilerfehler
• Schleifen: for … in wie foreach, range() statt Zählschleife, kein do/while
• Schleifensteuerung mit break und continue, der else-Zweig als Ersatz für Such-Flags

Funktionen in Python

• Definieren und Aufrufen von Funktionen mit def, freie Funktionen ohne umgebende Klasse
• Mehrere Rückgabewerte als Tupel statt out-Parametern
• Benannte und Standardparameter wie in C# – und die Falle veränderlicher Standardwerte
• Nur-Schlüsselwort-Parameter nach * und reine Positionsparameter mit /
• *args und **kwargs gegenüber params-Arrays
• Lambda-Funktionen: nur ein Ausdruck, anders als C#-Lambdas mit Anweisungsblock
• Funktionen als Objekte: Callable statt Func<> und Action<>, functools.partial

Klassen und Objekte in Python

• Klassen und Methoden definieren: __init__, explizites self, keine Zugriffsmodifizierer
• Konventionen _intern und Namensverschleierung mit __name statt private und protected
• @classmethod als benannter Konstruktor, @staticmethod und Modulfunktionen
• Vererbung mit super(), Überschreiben ohne virtual, Kennzeichnung mit @typing.override
• Mehrfachvererbung und Methodenauflösungsreihenfolge (MRO) – was C# bewusst ausschließt
• Abstrakte Klassen mit abc.ABC und @abstractmethod
• Schnittstellen: typing.Protocol für strukturelle Typen statt nominaler Interfaces
• ABC oder Protocol: ausdrückliche Vererbung gegenüber Duck Typing, Kriterien für die Wahl
• Magische Methoden __str__, __repr__, __eq__, __hash__ statt ToString, Equals, GetHashCode
• Aus operator + wird __add__, aus IComparable werden __lt__ und Vergleiche mit functools.total_ordering
• Eigenschaften mit @property und Setter statt { get; set; }
• Datenklassen mit @dataclass(frozen=True) als Gegenstück zu record

Sammlungen und LINQ-Ersatz

• Arrays und Listen: list statt List<T> und Array, Slicing mit [a:b]
• Tupel für feste Wertegruppen, das Modul array für typisierte Zahlenreihen
• Dictionaries statt Dictionary<TKey, TValue>: get(), setdefault() und defaultdict
• Mengen mit set und frozenset statt HashSet<T>
• Iteratoren mit __iter__ und __next__ gegenüber IEnumerable<T> und IEnumerator<T>
• Generatoren mit yield als Gegenstück zu yield return, verzögerte Auswertung
• LINQ → Comprehensions: Where und Select als List- und Dict-Comprehension
• sorted(key=…), itertools.groupby, sum() und any() statt OrderBy, GroupBy, Sum, Any

Allgemeine Operationen

• Eingebaute Funktionen len(), isinstance(), enumerate(), zip() statt Methoden und Properties
• Zeichenketten: f-Strings statt $"…"-Interpolation, Format-Spezifikationen
• String-Methoden und "".join() statt StringBuilder
• Ausnahmen: try/except/finally, raise statt throw, Ausnahmeketten mit from
• Ausnahmegruppen mit except* und eine eigene Ausnahmehierarchie für die Fachlogik
• with und Kontextmanager als Gegenstück zu using und IDisposable

Pakete, Umgebungen und Tests

• Pakete und Umgebungen mit uv: pyproject.toml statt .csproj, PyPI statt NuGet
• Module und Pakete gegenüber Namespaces und Assemblys: Importe und __init__.py
• Virtuelle Umgebungen, Lockdatei uv.lock und eine feste Python-Version je Projekt
• Tests mit pytest statt xUnit oder NUnit: assert, Fixtures, @pytest.mark.parametrize
• Ruff als Linter und Formatierer, vergleichbar mit Roslyn-Analyzern und dotnet format
• async/await in Python und C#: asyncio statt Task-basiertem Thread-Pool im Überblick

C#-Code mit JetBrains AI nach Python übertragen

• Agent portiert eine C#-Klasse – Review auf Getter-Methoden, I-Präfixe und Interfaces mit einer Implementierung
• mypy --strict übernimmt die Rolle des Compilers und läuft nach jeder Änderung des Agenten
• xUnit-Fälle zuerst als pytest-Tests übertragen lassen, erst danach den Produktivcode
• LINQ-Ketten vom Agenten in Comprehensions umschreiben lassen und Laufzeiten mit timeit vergleichen
• Projektregeln für den Agenten festhalten: uv statt pip, Protocols, keine pauschalen except Exception

Praxisprojekt: Lagerauswertung aus einem .NET-Dienst in Python

• Lagerbewegungen aus CSV einlesen, als Dataclasses abbilden und Bestände je Artikel berechnen
• Datenquellen hinter einem Protocol austauschbar machen: CSV-Datei und SQLite
• LINQ-Auswertungen der C#-Vorlage mit Comprehensions und itertools nachbauen
• Paket mit uv, pytest-Suite und mypy-Prüfung ausliefern und mit der C#-Fassung abgleichen