Bestimmung des zu verwendenden Klassenobjekts

Das Klassenobjekt wird aus einer Zelle namens __class__ entnommen.

Sollte super tatsächlich ein Schlüsselwort werden?

Nein. Es ist nicht notwendig, dass super ein Schlüsselwort wird.

super verwendet mit \_\_call\_\_-Attributen

Es wurde erwogen, dass die Instanziierung von Superinstanzen auf klassische Weise problematisch sein könnte, da ein Aufruf die \_\_call\_\_-Attribute nachschlagen und somit versuchen würde, einen automatischen Super-Lookup zur nächsten Klasse in der MRO durchzuführen. Dies erwies sich jedoch als falsch, da ein Aufruf eines Objekts nur die \_\_call\_\_-Methode direkt auf dem Typ des Objekts nachschlägt. Das folgende Beispiel zeigt dies in Aktion.

class A(object):
    def __call__(self):
        return '__call__'
    def __getattribute__(self, attr):
        if attr == '__call__':
            return lambda: '__getattribute__'
a = A()
assert a() == '__call__'
assert a.__call__() == '__getattribute__'

In jedem Fall entfällt dieses Problem vollständig, da klassische Aufrufe von super(<class>, <instance>) weiterhin mit derselben Bedeutung unterstützt werden.

Keine Änderungen

Obwohl es immer attraktiv ist, die Dinge so zu belassen, wie sie sind, haben die Leute seit einiger Zeit eine Änderung in der Verwendung von Super-Aufrufen gesucht, und das aus gutem Grund, wie zuvor erwähnt.

• Entkopplung vom Klassennamen (der möglicherweise nicht einmal mehr an die richtige Klasse gebunden ist!)
• Einfacher aussehende, sauberere Super-Aufrufe wären besser.

Dynamisches Attribut vom Supertyp

Der Vorschlag fügt dem Supertyp ein dynamisches Attribut-Lookup hinzu, das automatisch die richtigen Klassen- und Instanzparameter ermittelt. Jedes Super-Attribut-Lookup identifiziert diese Parameter und führt das Super-Lookup auf der Instanz durch, so wie die aktuelle Super-Implementierung dies mit der expliziten Invokation einer Superinstanz auf eine Klasse und Instanz tut.

Dieser Vorschlag stützt sich auf sys.\_getframe(), was für alles andere als eine Prototyp-Implementierung ungeeignet ist.

self.\_\_super\_\_.foo(*args)

Das \_\_super\_\_-Attribut wird in diesem PEP an mehreren Stellen erwähnt und könnte für die vollständige Lösung in Frage kommen, indem es tatsächlich explizit anstelle einer direkten Super-Verwendung genutzt wird. Doppelunterstrich-Namen sind jedoch normalerweise interne Details und es wird versucht, sie aus dem alltäglichen Code herauszuhalten.

super(self, *args) oder \_\_super__(self, *args)

Diese Lösung löst nur das Problem der Typenanzeige, behandelt keine unterschiedlich benannten Super-Methoden und ist explizit bezüglich des Instanznamens. Sie ist weniger flexibel, da sie nicht auf andere Methodennamen angewendet werden kann, wenn dies erforderlich ist. Ein Anwendungsfall, der hier fehlschlägt, ist, wo eine Basisklasse eine Factory-Klassenmethode hat und eine Unterklasse zwei Factory-Klassenmethoden hat, die beide ordnungsgemäß Super-Aufrufe an die Basisklasse machen müssen.

super.foo(self, *args)

Diese Variante eliminiert tatsächlich die Probleme bei der Lokalisierung der richtigen Instanz, und wenn eine der Alternativen ins Rampenlicht gerät, dann diese.

super(*p, **kw)

Es gab den Vorschlag, dass der direkte Aufruf von super(*p, **kw) dem Aufruf der Methode auf dem super-Objekt mit demselben Namen wie die aktuell ausgeführte Methode entsprechen würde, d. h. die folgenden beiden Methoden wären äquivalent:

def f(self, *p, **kw):
    super.f(*p, **kw)

def f(self, *p, **kw):
    super(*p, **kw)

Es gibt hierfür starke Befürworter und Gegner, aber Implementierungs- und Stilbedenken sind offensichtlich. Guido hat vorgeschlagen, dies aus diesem PEP nach dem KISS-Prinzip (Keep It Simple Stupid) auszuschließen.