AFAIK:Hyperion hat geschrieben:Ja ok, ist wohl wirklich ein Problem der exakten Definition! Ich hatte es nur von der Ruby-Seite im Kopf, wo Mixins explizit als Unterschied zu Pythons Verfachvererbung genannt werden.
Ruby realisiert MixIns durch include von Modulen in eine Klasse.
[strike]D.h. die Referenzen auf die Methoden werden dabei statisch umkopiert[/strike] ¹, wie es in diesem Thread schon gezeigt wurde.
Das geht auch elegant, weil Ruby nicht erzwingt dass Module in einem eigenen File leben.
Bei Vererbung hat man hingegen einen dynamischen Suchpfad für "fehlende" Methoden. Hat es die eigene Klasse nicht, sucht man in der (ersten!) Superklasse, hat die es nicht sucht man in deren Superklasse. Ist man oben erfolglos angekommen, schaut man (bei Mehrfachvererbung!) unten ob es im Suchpfad eine weitere Superklassen gibt, und das ganze fängt von neuem an. Das führt zu konzeptionell ziemlich schwer zu beherrschenden Problemen wie dem Diamantfall, wo zwei Superklassen eine gemeinsame Superklasse haben.
Inwieweit (Modul-) import in Python das gleiche leisten können wie in Ruby weiß ich jetzt nicht, es sollte aber ansonsten kein Problem sein den betreffenden Klassen eine Methode namens import zu designen die genau das Mixin-Schema von Ruby nachstellt (wie gezeigt über die Dicts iterieren und umkopieren)
dann ruft man so was auf wie Klasse.import(Superklasse)
Will man hingegen weiterhin eine dynamische Auflösung der Methode, könnte man z.B. auch __getattr__ überschreiben.
Und das sich Python seiner Metaklassen rühmt, sollte es eigentlich für beide Konzepte auch schon konkrete Umsetzungen geben.
UPDATE:
[1] so ich habe jetzt schmarrn erzählt, tatsächlich werden die Mixin-Methoden bei einem include nicht statisch umkopiert sondern das Modul wird dynamisch verlinkt. Sprich wird dem Modul später eine neue Methode hinzugefügt, ist sie dynamisch durch den Suchpfad sichtbar.