Wird super() gebrochen in Python-2.x?

Es ist oft gesagt, dass super sollte vermieden in Python 2. Ich gefunden habe in meiner Verwendung von super in Python 2 dass es nie wieder so handelt, wie ich erwarte, wenn ich alle Argumente-wie das Beispiel:

super(ThisClass, self).some_func(*args, **kwargs)

Scheint es mir, diese Niederlagen der Zweck der Verwendung super(), es ist weder kürzer, oder viel besser als TheBaseClass.some_func(self, *args, **kwargs). Für die meisten Zwecke method resolution order ist ein fernes Märchen.

  • Andere als die Tatsache, dass 2.7 ist das Letzte major release zu Python 2, warum funktioniert super bleiben, gebrochen in Python 2?
  • Wie und warum hat Python 3 ist super geändert? Gibt es irgendwelche Vorbehalte?
  • Wann und warum sollte ich super vorwärts gehen?
  • Sie nicht geben Sie irgendein Beispiel, warum Sie denken, dass Sie super ist gebrochen, außer, dass es nicht kürzer als der Aufruf der Basisklasse explizit die weder hier noch dort... Sie offensichtlich nicht verstehen, was " super() ist ein (up-Aufruf sicher mit Mehrfachvererbung).
  • Das wäre subjektiv und unscharf ist nicht Teil meines namens 🙂
  • Gut, Nein. "Broken" ist nicht ein subjektiver Begriff und super ist notwendig, in einigen Fällen. So brauchen Sie sich nicht zu erklären, warum Sie denken, dass Sie super ist gebrochen (anders als durch Verweis zu einem Artikel, nicht sagen, dass) und Sie zeigen keine Erscheinung, zu verstehen, was super ist (Tipp: es ist nicht das äquivalent der alternative, die Sie zeigen).
  • Wenn Sie sagen, dass TheBaseClass.some_func(self, *args, **kwargs) ist besser als super Sie sind unter der Annahme, dass TheBaseClass ist immer der Vorfahr von ThisClass die möglicherweise nicht der Fall sein, wenn Sie mehrfache Vererbung (oder jemand fügt es danach). Es könnte sein, dass super(ThisClass, self) löst etwas anderes als TheBaseClass. super(). Die Frage ist also: wollen Sie zum aufrufen der "next guy" in der Kette (wahrscheinlich) oder Ihr anrufen möchten TheBaseClass genau.
InformationsquelleAutor Matt Joiner | 2011-02-21
  1. 42

    super() ist nicht kaputt-es sollte nur nicht als standard-Weg für den Aufruf einer Methode der Basisklasse. Dies änderte sich nicht mit Python 3.x. Das einzige, was sich verändert hat, ist, dass Sie nicht brauchen, um passieren die Argumente self, cls im standard-Fall, dass self ist der erste parameter der aktuellen Funktion und cls ist die Klasse aktuell definiert.

    Bezüglich Ihrer Frage, wenn Sie auch tatsächlich zu nutzen super() meine Antwort wäre: kaum jemals. Ich persönlich versuchen zu vermeiden, die Art der Mehrfachvererbung machen würde super() nützlich.

    Bearbeiten: Ein Beispiel aus dem realen Leben, die ich einmal lief: ich hatte einige Klassen definieren run() Methode hatte, von denen einige Basis-Klassen. Ich verwendet super() Aufruf der geerbten Konstruktoren -- ich wusste nicht, dass es darauf ankam, denn ich war mit einfachvererbung nur:

    class A(object):
    def __init__(self, i):
        self.i = i
    def run(self, value):
        return self.i * value

class B(A):
    def __init__(self, i, j):
        super(B, self).__init__(i)
        self.j = j
    def run(self, value):
        return super(B, self).run(value) + self.j

    Stell dir vor, es gab mehrere Klassen, die alle mit eigener Konstruktor Prototypen, und alle mit derselben Schnittstelle run().

    Nun wollte ich hinzufügen, dass einige zusätzliche Funktionen, um alle diese Klassen, sagen die Protokollierung. Die zusätzliche Funktionalität benötigt, eine zusätzliche Methode definiert werden, auf alle diese Klassen, sagen info(). Ich wollte nicht in die ursprünglichen Klassen, sondern definieren, einen zweiten Satz von Klassen Erben von der ursprünglichen, hinzufügen der info() - Methode und erbt von einem mix-in die Bereitstellung der eigentlichen Anmeldung. Nun, ich konnte nicht verwenden super() im Konstruktor nicht mehr, so habe ich direkte Aufrufe:

    class Logger(object):
    def __init__(self, name):
        self.name = name
    def run_logged(self, value):
        print "Running", self.name, "with info", self.info()
        return self.run(value)

class BLogged(B, Logger):
    def __init__(self, i, j):
        B.__init__(self, i, j)
        Logger.__init__("B")
    def info(self):
        return 42

    Hier Dinge, die aufhören zu arbeiten. Die super() nennen, die in der Basisklasse Konstruktor plötzlich ruft Logger.__init__(), und BLogged kann nichts über es nicht tun. Es gibt tatsächlich keinen Weg, um diese Arbeit zu machen, außer für das entfernen der super() Anruf in B selbst.

    [Noch ein Edit: ich scheine nicht zu haben, aus meiner Sicht, wie aus all den Kommentaren hier und unter den anderen Antworten. Hier ist, wie dieser code funktioniert mit super():

    class A(object):
    def __init__(self, i, **kwargs):
        super(A, self).__init__(**kwargs)
        self.i = i
    def run(self, value):
        return self.i * value

class B(A):
    def __init__(self, j, **kwargs):
        super(B, self).__init__(**kwargs)
        self.j = j
    def run(self, value):
        return super(B, self).run(value) + self.j

class Logger(object):
    def __init__(self, name, **kwargs):
        super(Logger,self).__init__(**kwargs)
        self.name = name
    def run_logged(self, value):
        print "Running", self.name, "with info", self.info()
        return self.run(value)

class BLogged(B, Logger):
    def __init__(self, **kwargs):
        super(BLogged, self).__init__(name="B", **kwargs)
    def info(self):
        return 42

b = BLogged(i=3, j=4)

    Vergleichen Sie diese mit der Verwendung von expliziten Superklasse aufruft. Sie entscheiden, welche version Sie bevorzugen.]

    Diese und ähnliche Geschichten sind es, warum ich denke, dass super() sollte nicht als der normale Weg, der Aufruf von Methoden der Basisklasse. Es bedeutet nicht super() ist gebrochen.

    • Ist die Letzte Zeile von B gemeint zu Lesen super(B, self), und diese sollten defs classes?
    • Danke, behoben.
    • Es ist unklar, wie das erstellen von Unterklassen ist besser als self._logger = Logger("B") - mischen von beliebigen Klassen in einem Baum hat nie gearbeitet. Sie können denken, der einen ähnlich kaputten Beispiel, aber mit direkten aufrufen. Die Klassen entworfen werden müssen, zusammen zu arbeiten. Und super helfen können, wenn Sie es nicht sind. Aber, wie der Artikel sagt, du bist besser dran mit übergeben der Argumente als Stichwörter beim aufrufen der Superklasse. Dann ist dein problem würde nicht existieren, wenn die Logger Klasse korrekt verwendet super.
    • All dies funktioniert völlig in Ordnung, wenn ich einfach nicht mit super(). Ich denke nicht, dass es gebrochen zu alle. Ich würde gerne call b.run_logged(value) auf eine BLogged Instanz b, nicht b._logger.run_logged(value).
    • Für diejenigen, die auf diese in die Zukunft, Raymond Hettinger gab ein fantastisch-talk: Super ist als Super.
    InformationsquelleAutor Sven Marnach
  2. 31

    super() ist nicht gebrochen, in Python 2 oder Python 3.

    Betrachten wir die Argumente aus dem blog post:

    • Es nicht tut, was es klingt wie es funktioniert.

    OK, Sie können Zustimmen oder nicht, dass, es ist ziemlich subjektiv. Was soll es denn dann als? super() ist ein Ersatz für den Aufruf von der Oberklasse direkt, so scheint der name in Ordnung für mich. Es ruft NICHT die Oberklasse direkt, denn wenn das war alles, was Sie Tat, es wäre sinnlos, als könnte man Sie trotzdem. OK, zugegeben, das mag nicht offensichtlich sein, aber die Fälle, wo Sie brauchen super() sind in der Regel nicht offensichtlich. Wenn Sie es brauchen, tun Sie einige ziemlich haarige Mehrfachvererbung. Es ist nicht zu offensichtlich sein. (Oder du machst ein einfaches mixin, in dem Fall ist es ziemlich offensichtlich, und verhält sich wie erwartet, auch wenn Sie nicht die Dokumentation Lesen).

    Wenn Sie anrufen können die Oberklasse direkt, das ist wahrscheinlich das, was Sie am Ende tut. Das ist die einfache und intuitive Art und Weise, es zu tun. super() kommt nur ins Spiel, wenn das nicht funktioniert.

    • Es nicht gut kämmen mit dem Aufruf der Oberklasse direkt.

    Ja, weil es entworfen ist, um ein problem zu lösen mit zu tun. Sie können rufen Sie die Oberklasse direkt, wenn, und nur wenn Sie genau wissen, welche Klasse das ist. Die Sie nicht für Mixins in Verbindung, zum Beispiel, wenn die Klasse Hierarchie ist so versaut, dass Sie tatsächlich vereinigen sich die beiden äste (was ist das typische Beispiel in allen Beispielen der Verwendung super()).

    So lange, wie jede Klasse in Ihrer Klassenhierarchie hat einen gut definierten Platz, den Aufruf der Superklasse direkt funktioniert. Wenn nicht, dann funktioniert es nicht, und in diesem Fall müssen Sie super() statt. Das ist der Punkt, der super() dass es zahlen, was die "nächste Superklasse" ist nach der MRO, ohne Sie ausdrücklich angeben, denn man kann nicht immer tun, weil Sie nicht immer wissen, was es ist, zum Beispiel bei der Verwendung von Mixins in Verbindung.

    • Die völlig andere Programmiersprache Dylan, eine Art von lisp-Dingens, löst dieses Problem auf eine andere Weise, die nicht verwendet werden können, in Python, weil es sehr unterschiedlich.

    Eh. OK?

    • super() nicht an Ihre Superklasse.

    Yeah, Sie sagte,.

    • Nicht mischen super() und direkt aufrufen.

    Yeah, Sie sagte das auch.

    Also, es gibt zwei Argumente dagegen: 1. Der name ist schlecht. 2. Verwenden Sie es konsequent.

    Nicht übersetzen, es wird "gebrochen" oder die, die es werden sollten "vermieden".

    • Ich habe keine Ahnung, was du meinst mit, dass.
    • Matt, der versucht, zu beleidigen die Menschen, die Antworten für Sie tut nichts für Ihre technischen Argumente.
    • Zur info, mein Profil liest die string-Theorie Forschungsarbeiten und gibt Kritik auf. Es ist ein ziemlich geiles Profil. Aber ich verstehe immer noch nicht, was du meinst. Mein Profil wahrscheinlich nicht, aber es ist zu beschäftigt, um meine E-Mails beantworten.
    • Regebro: Sorry für die Verwirrung, es ist eine eher ungewöhnliche Verwendung für das Wort 'Lesen': definition 6: en.wiktionary.org/wiki/read#Verb. Ich meine-Zunge-in-Wange, dass, wenn Ihre Antwort waren mehr Konversation würde ich denken, geschrieben von einem Java-fan.
    • Java-fans gibt es nicht in meiner Erfahrung gesprächiger als die Pythonistas... Ah gut.
    InformationsquelleAutor Lennart Regebro
  3. 6

    Du scheinst zu unterstellen in Ihrem Beitrag, dass

    def some_func(self, *args, **kwargs):
    self.__class__.some_func(self, *args, **kwargs)

    ist nicht eine unendliche Rekursion. Es ist, und super wäre richtiger.

    Auch, ja, Sie sind erforderlich, um alle übergeben Argumente zu super(). Das ist ein bisschen wie beschweren sich, dass max() funktioniert nicht wie erwartet, es sei denn, Sie übergeben Sie alle zahlen, die Sie überprüfen möchten.

    In 3.x, jedoch weniger Argumente sind nötig: Sie können dies super().foo(*args, **kwargs) statt super(ThisClass, self).foo(*args, **kwargs).

    Ich bin jedenfalls nicht sicher auf alle Situationen beim super sollte vermieden werden. Sein Verhalten ist nur "komisch", wenn MI beteiligt ist, und bei der MI beteiligt ist, super() ist im Grunde Ihre hoffe nur, dass für eine richtige Lösung. In Einzel-Vererbung es ist nur etwas wordier als SuperClass.foo(self, *args, **kwargs), und macht nichts anders.

    Ich glaube, ich Stimme mit Sven, dass diese Art von MI ist es Wert zu vermeiden, aber ich bin nicht einverstanden, dass super ist es Wert zu vermeiden. Wenn Ihre Klasse soll vererbt werden, super bietet den Benutzern Ihrer Klasse Hoffnung MI zu arbeiten, wenn Sie sind seltsam in dieser Weise, so macht es Ihre Klasse mehr nutzbar.

    • Ich Stimme überhaupt nicht mit, dass super() ist die "einzige Hoffnung", wenn mehrfache Vererbung beteiligt ist. Es gibt clas hierachies, die erfordern, dass super(), aber vielen Klassen-Hierarchien mit Mehrfachvererbung nicht.
    • ist nur so etwas wie eine Allgemeine Lösung (über verschiedene Arten der Vererbung-Graphen), so weit wie ich es verstehe. Natürlich, wenn Sie nicht daran interessiert sind, eine Allgemeine Lösung ist, dann super nicht geben Ihnen etwas. Auf der anderen Seite, werden Sie nicht verlieren alles, was durch die Verwendung super entweder. Also, ich würde super.
    • Hast du eigentlich gelesen, dieser Seite im Zusammenhang mit dem OP? Zumindest brauchen Sie sich nicht um die erwähnten Probleme gibt. Sie werden, etwas zu verlieren, wenn Sie super(). Ich benutzte es eine Menge, und es brach eine Menge von meinem code. Mittlerweile, jedes mal wenn ich Begegnung super() in meinem code habe ich es rauseditieren.
    • Gelesen habe ich es ein paar mal über die Jahre. Ich kann nicht finden, was Sie denken, der von einem abschöpfen. Was hat es zu sagen, Sie verlieren durch die Verwendung von super, dass Sie behalten durch die Verwendung von SuperClass.method(...)? Ich Sprach die Probleme in der Frage genannten, nicht den Artikel, denn eigentlich hatte er Fragen.
    • sorry, ich wollte nicht zu hart klingen. Speziell, was Sie verlieren ist, dass Sie nicht wissen, was Methode, die Sie tatsächlich anrufen. Das bit mir schon ein paar mal über die Jahre. In der Regel, ich weiß, die __init__() möchte ich nennen, und ich will nicht super() Sie eine andere sein, je nach Kontext. Und ich do verwenden Sie Mehrfachvererbung.
    • Aber das ist der ganze point es. Verwenden Sie super() in Fällen, in denen Sie nicht genau wissen, welche Methode Sie aufrufen müssen. 🙂 Wenn du hast, dann könntest du einfach rufen.
    • Mein einziger Punkt ist, dass super() sollte nicht als die standard-Art des Aufrufs Basis-Klasse Methoden. Viele Menschen tun das, und Devin auch vorschlagen, dies zu tun.
    • Vielleicht sollten Sie Lesen Sie die Artikel ich verknüpft ;). Es gibt gute Gründe zu wollen, super-wie Verhalten. Wenn Sie nicht einverstanden mit der MRO produziert, ändern Sie die Reihenfolge der Vererbung. Es ist wahr, dass es einige Vererbung Ketten, die sind unmöglich, um vernünftig, aber Sie sind sehr seltsam (siehe Beispiele). Ich schlage vor, es als regulären Weg, weil Sie wirklich nichts verlieren, indem Sie es in den SI-code und (sane) MI code kann jederzeit gemacht werden, um mit ihm zu arbeiten (nicht immer der Fall für explizite Basis-Aufrufe).
    • Ich Las den Artikel mehrmals. Ich gab ein vollständiges Beispiel für das, was Sie verlieren auch in single inheritance in meiner Antwort.
    • bei einfacher Vererbung die MRO ist identisch mit der Rückseite der Vererbungskette. Sie wissen genau, welche Methode Sie aufrufen.
    • Dann schauen Sie auf das Beispiel, das ich gab. Als ich das erste entwickelt die Hierarchie, es war eine einzige Vererbung nur, damit ich nicht zu kümmern, ob super() oder explizite Aufrufe. Später, als ich eingeführt mix-ins weiter unten in der Hierarchie, die alten super() fordert mich etwas.
    • Ihr Beispiel ist der MI, nicht SI. Das problem entsteht aus der Unwissenheit, wie das super funktioniert: Sie können nicht mischen super und Oberklasse.Methode, denn was super funktioniert. Dass beiseite, Sie scheinen zu denken, dass SI-code wiederverwendet werden kann, ohne änderungen zu MI code: das ist falsch, im Allgemeinen Fall (siehe: diamond inheritance problem), obwohl das super macht es auch für weitere Fälle, und einfacher/möglich für den Rest. Es wird immer Arbeit mit Mixins in Verbindung, vorausgesetzt, Sie verwenden die Konstrukte korrekt, so dass, wenn Ihre Beschwerde ist, dass es entfernt die Möglichkeit, um Sie später zu verwenden Mixins in Verbindung von SI-code, das ist falsch.
    • Vielleicht ist es meine begrenzte Kenntnisse der englischen Sprache, aber Sie scheint mir völlig falsch. Ich wissen genau, wie super() funktioniert. Ich weiß, warum mein Beispiel brach und wie man es beheben, sowohl mit super() und explizite Superklasse aufruft. Die version mit super() ist hässlich und schwer zu fassen, während die version mit expliziten Aufrufe ist straight-forward. Ich bin zufällig auf die letztere vorziehen.
    • Beachten Sie auch, dass in meinem Beispiel, man könnte einfach mix in die anderen Klassen in der Hierarchie (also "wiederverwenden SI-code ohne änderungen zu MI code") wäre es nicht für die super() call -- ohne Sie ist alles straight-forward.
    • Wenn Sie wissen, wie es zu beheben verwenden Sie nur super-Aufrufe, in Ordnung, aber an der Zeit, die Sie behauptet, dass der einzige Weg, um es zu beheben war, zu entfernen super. Für deine Lösung, Sie machen es unnötig hässlich mit **kwargs Mist. Ich glaube nicht, Sie verstehen sich super() wenn Sie denken, das ist notwendig. Und ich glaube nicht, dass Sie verstehen, Mixins in Verbindung, wenn Sie Diamant-Vererbung mit Ihnen. Das heißt, ich habe genug von diesem thread -- die "Frage"-Fragesteller nie wirklich wollte eine Antwort, nur eine Wiederholung seiner Vorurteile, und schon haben Sie es gegeben.
    • Ich wäre ehrlich interessiert, wie man es besser machen und wie Sie mit mix-ins mit new-style-Klassen, ohne irgendwelche Diamanten. Deine Letzte Bemerkung war eigentlich ziemlich beleidigend und enthalten ziemlich wenig technische Informationen.
    • Ich denke, dass super() sollte immer aufgerufen werden, mit dem die einfache Vererbung zu. So dass Sie wirklich OOP mit Vererbung, Methoden und Verhalten sich genauso wie die Eigenschaften sind (und ich denke, dies ist korrekt und sauber Verhalten). Sie sagen nicht über die Eigenschaft: falls nicht definiert, wird hier, nehmen Sie es aus der A-Klasse. Sie sagen: nehmen Sie es von den Eltern. Wenn Sie die Methode bestimmen, dann in der richtigen OOP sollte es tun "gleich wie Eltern"+etwas mehr. Mit super() haben Sie den code funktioniert ohne änderungen, wenn Sie fügen Sie die fehlenden (noch nicht verwendete) Methode irgendwo in der Vorfahren-Kette, wenn Sie ändern die Ahnen-Kette und so weiter.

    InformationsquelleAutor Devin Jeanpierre
  4. 3

    Hast du den Artikel gelesen, den Sie verlinken? Es nicht schließen, dass super sollte vermieden werden, aber das sollte man vorsichtig sein, seine Vorbehalte, wenn es zu benutzen. Diese Vorbehalte sind zusammengefasst die Artikel, obwohl, ich würde nicht einverstanden mit Ihren Vorschlägen.

    Der wichtigste Punkt des Artikels ist, dass Mehrfachvererbung können sich chaotisch, und super hilft nicht so viel, wie der Autor möchte. Jedoch multiple Vererbung ohne super wird es oft noch komplizierter.

    Wenn Sie nicht tun, die mehrfache Vererbung super gibt Sie den Vorteil, dass jemand erbt von der Klasse hinzufügen können einfache Mixins in Verbindung und Ihre __init__ wäre richtig genannt. Denken Sie daran, rufen Sie immer die __init__ von der Superklasse, auch wenn Sie Erben von object, und führen Sie alle verbleibenden Argumente (*a und **kw) zu. Wenn Sie den Aufruf von anderen Methoden von der übergeordneten Klasse verwenden auch super, aber dieses mal verwenden, deren ordnungsgemäße Unterschrift, die Sie bereits kennen (d.h. sicherzustellen, dass Sie die gleiche Signatur in allen Klassen).

    Wenn Sie Mehrfachvererbung müsste man tiefer Graben als das, und wahrscheinlich wieder Lesen die gleichen Artikel mehr gezielt, um sich bewusst sein, der Vorsichtsmaßnahmen. Und es ist auch nur bei Mehrfachvererbung, wenn Sie könnten eine situation, wo ein expliziter Aufruf an die Eltern könnte besser sein, als super, aber ohne ein bestimmtes Szenario niemand kann Ihnen sagen, ob super verwendet werden soll oder nicht.

    Die einzige änderung in super in Python 3.x ist, dass Sie nicht brauchen, um explizit zu übergeben, der die aktuelle Klasse und self zu. Dies macht super mehr attraktiv, weil es würde bedeuten, dass kein hardcoding entweder die übergeordnete Klasse oder der aktuellen Klasse.

    InformationsquelleAutor Rosh Oxymoron
  5. 1

    @Sven Marnach:

    Das problem mit deinem Beispiel ist, dass Sie mischen explizite Oberklasse ruft B.__init__ und Logger.__init__ im Blogartikel mit super() in B., die nicht funktionieren. Entweder Sie verwenden alle explizite Superklasse aufruft oder verwenden Sie super() auf alle Klassen. Wenn Sie super() Sie brauchen, um verwenden Sie es auf alle Klassen beteiligt sind, einschließlich Eine, die ich denke. Auch in deinem Beispiel denke ich, Sie könnte verwenden Sie die explizite Superklasse Anrufe in alle Klassen, ich.e verwenden Sie A.__init__ in Klasse B

    Wenn es keine diamond-Vererbung denke ich, dass super() nicht viel Vorteil. Das problem ist jedoch, dass Sie nicht im Voraus wissen, wenn Sie in eine Diamant-Vererbung in der Zukunft also in diesem Fall wäre es klug zu nutzen super() sowieso (aber verwenden Sie es dann konsequent). Sonst würden Sie am Ende mit zu ändern, alle Klassen zu einem späteren Zeitpunkt oder führen Sie in Probleme.

    • Gut, ich weiß, warum mein Beispiel nicht funktioniert. Es war gedacht als Beispiel, wie routinemäßig mit super() hat Nachteile. Sie können am Beispiel der Arbeit mit super(), aber es wird wirklich hässlich, während es ist straight-forward mit expliziten Superklasse aufruft. Beachten Sie, dass es wird diamond erbschaft beteiligt, da beide A und Logger stammen aus object. Nochmal, mein Punkt ist, dass super() sollte nicht als die standard-Art des Aufrufs Basis-Klasse Methoden.
    InformationsquelleAutor Piet van Oostrum
Schreibe einen Kommentar