Python-Klassen in 25 Zeilen: Ein überraschendes Experiment mit Dataclasses

Python-Entwickler kennen das Problem: Klassen mit boilerplate-Code wie __init__, __eq__ oder __repr__ schreiben. Der @dataclass-Decorator löst das elegant – doch was, wenn man stattdessen eine Funktion möchte, die direkt eine Klasse zurückgibt? Ein experimenteller Ansatz zeigt, wie das mit minimalem Aufwand möglich ist – und welche Fallstricke dabei lauern.

Dynamische Klassen als Ergebnis einer Funktion

Die Grundidee ist einfach: Eine Funktion nimmt Schlüsselwortargumente entgegen und gibt eine Klasse zurück. Diese Klasse besitzt automatisch Attribute, deren Standardwerte den übergebenen Argumenten entsprechen. Der Clou: Die Methode __init__ setzt nur die explizit übergebenen Werte als Instanzattribute, während alle anderen auf Klassenniveau verbleiben. So lässt sich der Standardwert eines Attributs zentral definieren, während der Instanzwert überschrieben werden kann.

Ein Beispiel verdeutlicht dies:

Klass = Klass(a=1, b=2)  # Klass ist jetzt eine Klasse mit Standardwerten a=1, b=2
instanz = Klass(a=3)      # Instanz hat a=3, b bleibt 2 (Klassenattribut)
print(instanz.a)          # Ausgabe: 3
print(instanz.b)          # Ausgabe: 2 (wird von der Klasse geerbt)

Die so erzeugte Klasse unterstützt zudem Gleichheitsprüfungen, Hash-Werte und eine benutzerdefinierte String-Darstellung – alles ohne manuelle Implementierung.

Die Implementierung im Detail

Der Kern der Lösung ist eine Kombination aus Closure und Metaprogrammierung. Die Funktion Klass sammelt die übergebenen Argumente in einem Dictionary fields und fügt zusätzlich eine Liste der Feldnamen hinzu. Anschließend wird mit type dynamisch eine Basisklasse erzeugt, die diese Felder als Klassenvariablen enthält. Eine innere Klasse _ erbt von dieser Basisklasse und überschreibt die Methoden __init__, __eq__, __hash__ sowie __repr__. Die Closure stellt sicher, dass alle Methoden auf das ursprüngliche fields-Dictionary zugreifen können – selbst wenn die Instanz bereits erstellt wurde.

Der vollständige Code ist kompakt und kommt ohne externe Abhängigkeiten aus:

def Klass(**fields):
    fields["__data__"] = list(fields.keys())  # Feldreihenfolge für Stabilität speichern
    
    class _(type("DataClass", (object,), fields)):
        def __init__(self, **class_kwargs):
            for k, val in class_kwargs.items():
                if k not in fields:
                    raise NameError(f"Unbekanntes Argument {k}={val}")
                setattr(self, k, val)
        
        def __str__(self):
            return f"&data.{self.__class__.__name__}({fields})"
        __repr__ = __str__
        
        def __eq__(self, other):
            return self.__dict__ == other.__dict__
        
        def __hash__(self):
            return hash(tuple(fields[k] for k in fields["__data__"]))
    
    return _

Drei verborgene Fehler und ihre Konsequenzen

Trotz der eleganten Lösung offenbart die Implementierung drei kritische Schwächen, die in der Praxis zu unerwartetem Verhalten führen können.

Fehler 1: Hash-Kollisionen durch Klassenebenen-Fehler

Der __hash__-Methode liegt ein fundamentaler Denkfehler zugrunde: Sie berechnet den Hash-Wert ausschließlich basierend auf den Klassenvariablen aus dem fields-Dictionary – nicht auf den tatsächlichen Instanzwerten. Das bedeutet:

hash(Klass(a=1)) == hash(Klass(a=999))  # Ergebnis: True (falsch!)

Obwohl die Instanzen unterschiedliche Werte enthalten, liefern sie denselben Hash. In Python sind Hash-Kollisionen zwar erlaubt, doch eine hohe Kollisionsrate führt zu Performance-Problemen, da alle kollidierenden Schlüssel in derselben Bucket einer Hash-Tabelle landen. Bei großen Datenmengen kann dies zu O(n)-Komplexität statt O(1) führen – ein Albtraum für Dictionaries oder Sets.

Fehler 2: Falsche Repräsentation durch Closure-Effekte

Die __str__-Methode gibt das ursprüngliche fields-Dictionary aus – nicht die aktuellen Instanzwerte. Wird eine Instanz mit geänderten Werten erzeugt, zeigt die String-Darstellung dennoch die Standardwerte an:

x = Klass(a=99)
print(x)  # Ausgabe: &data.Klass({'a': 1, 'b': 2}) – obwohl x.a eigentlich 99 ist

Dies widerspricht dem Prinzip von __repr__, der eine eindeutige und wahrheitsgetreue Darstellung des Objekts liefern sollte. Die Lösung wäre, sowohl die Standardwerte als auch die Instanzattribute zu kombinieren.

Fehler 3: Inkonsistente Gleichheitsprüfung durch Attributvererbung

Die __eq__-Methode vergleicht ausschließlich die __dict__-Attribute der Instanzen. Problematisch wird es, wenn ein Attribut als Klassenvariable definiert ist und nicht explizit in der Instanz überschrieben wird:

Klass = Klass(a=1, b=2)
Klass() == Klass(a=1, b=2)  # Ergebnis: False (obwohl beide effektiv a=1, b=2 haben)

Die leere Instanz Klass() hat ein leeres __dict__, während die Instanz Klass(a=1, b=2) die Attribute a und b enthält. Da die Klassenvariablen nicht im Instanz-Dictionary landen, gelten die Objekte als ungleich – obwohl sie semantisch identisch sind. Eine korrekte Implementierung müsste alle Felder explizit abfragen, unabhängig davon, ob sie auf Klassen- oder Instanzebene definiert sind.

Warum diese Experimente wertvoll sind

Trotz der offensichtlichen Mängel bietet der Ansatz wertvolle Einblicke in Pythons Objektmodell. Er demonstriert:

• Erste-Klasse-Klassen: Funktionen können Klassen zurückgeben, und type fungiert als dynamischer Klassenkonstruktor.
• Closures in Klassenmethoden: Die innere Klasse _ greift auf Variablen der äußeren Funktion Klass zu – ein mächtiges, aber fehleranfälliges Konzept.
• Attributvererbung zwischen Klasse und Instanz: Standardwerte auf Klassenniveau, Überschreibungen auf Instanzebene – ein Prinzip, das auch Django-Modelle oder ORMs nutzen.
• Die Notwendigkeit von @dataclass: Die Standardbibliothek löst die gleichen Probleme, aber mit durchdachten Lösungen für Hashing, Gleichheit und Repräsentation.

Ein Blick in die Implementierung von dataclasses.py offenbart, wie komplex die korrekte Handhabung von Attributen und Vererbung tatsächlich ist. Die dortige Lösung berücksichtigt unter anderem:

• Wann __dict__ aktualisiert werden muss
• Wie mit Einfrieren (Frozen-Instanzvariablen) umgegangen wird
• Wann Hash-Werte basierend auf Tupeln statt Dictionaries berechnet werden

Fazit: Innovation ja, Produktion nein

Dieses 25-zeilige Experiment ist ein faszinierendes Lehrstück – aber keine Empfehlung für den produktiven Einsatz. Die drei identifizierten Fehler zeigen, wie leicht man sich in Pythons Objektmodell verirren kann. Für den täglichen Gebrauch bleiben etablierte Werkzeuge wie der @dataclass-Decorator oder Bibliotheken wie attrs die sicherste Wahl.

Dennoch lohnt es sich, den Code nachzuvollziehen, die Fehler selbst zu finden und zu beheben. Nur so lässt sich verstehen, was hinter den Kulissen von dataclasses und Co. passiert. Am Ende steht nicht nur ein funktionierender Prototyp, sondern ein tieferes Verständnis für die Mechanismen, die Python zu einer so flexiblen Sprache machen.