Come funziona il super () di Python con ereditarietà multipla?

Sono praticamente nuovo nella programmazione orientata agli oggetti di Python e ho difficoltà a comprendere la super()funzione (nuove classi di stile) soprattutto quando si tratta di ereditarietà multipla.

Ad esempio se hai qualcosa come:

class First(object):
    def __init__(self):
        print "first"

class Second(object):
    def __init__(self):
        print "second"

class Third(First, Second):
    def __init__(self):
        super(Third, self).__init__()
        print "that's it"

Quello che non capisco è: la Third()classe erediterà entrambi i metodi di costruzione? Se sì, quale verrà eseguito con super () e perché?

E se si desidera eseguire l'altro? So che ha qualcosa a che fare con l'ordine di risoluzione del metodo Python ( MRO ).

Questo è dettagliato con una ragionevole quantità di dettagli dallo stesso Guido nel suo post sul metodo di risoluzione del metodo (inclusi due tentativi precedenti).

Nel tuo esempio, Third()chiamerò First.__init__. Python cerca ogni attributo nei genitori della classe in quanto sono elencati da sinistra a destra. In questo caso, stiamo cercando __init__. Quindi, se lo definisci

class Third(First, Second):
    ...

Python inizierà guardando Firste, se Firstnon ha l'attributo, allora guarderà Second.

Questa situazione diventa più complessa quando l'eredità inizia a incrociare percorsi (ad esempio se First ereditati da Second). Leggi il link sopra per maggiori dettagli, ma, in poche parole, Python proverà a mantenere l'ordine in cui ogni classe appare nell'elenco delle eredità, a partire dalla classe figlio stessa.

Quindi, ad esempio, se avessi:

class First(object):
    def __init__(self):
        print "first"

class Second(First):
    def __init__(self):
        print "second"

class Third(First):
    def __init__(self):
        print "third"

class Fourth(Second, Third):
    def __init__(self):
        super(Fourth, self).__init__()
        print "that's it"

il MRO sarebbe [Fourth, Second, Third, First].

A proposito: se Python non riesce a trovare un ordine coerente di risoluzione del metodo, solleverà un'eccezione, invece di ricorrere a comportamenti che potrebbero sorprendere l'utente.

Modificato per aggiungere un esempio di MRO ambiguo:

class First(object):
    def __init__(self):
        print "first"

class Second(First):
    def __init__(self):
        print "second"

class Third(First, Second):
    def __init__(self):
        print "third"

ThirdMRO dovrebbe essere [First, Second]o [Second, First]? Non ci sono aspettative ovvie e Python genererà un errore:

TypeError: Error when calling the metaclass bases
    Cannot create a consistent method resolution order (MRO) for bases Second, First

Modifica: vedo diverse persone che sostengono che gli esempi sopra mancano di super()chiamate, quindi lasciami spiegare: il punto degli esempi è mostrare come è costruito l'MRO. Essi sono non intendono stampare "prima \ nsecond \ terzo" o qualsiasi altra cosa. Puoi - e dovresti, naturalmente, giocare con l'esempio, aggiungere super()chiamate, vedere cosa succede e ottenere una comprensione più profonda del modello di eredità di Python. Ma il mio obiettivo qui è quello di renderlo semplice e mostrare come è costruito l'MRO. Ed è costruito come ho spiegato:

>>> Fourth.__mro__
(<class '__main__.Fourth'>,
 <class '__main__.Second'>, <class '__main__.Third'>,
 <class '__main__.First'>,
 <type 'object'>)

Il tuo codice e le altre risposte sono tutti difettosi. Mancano le super()chiamate nelle prime due classi necessarie per il funzionamento della sottoclasse cooperativa.

Ecco una versione fissa del codice:

class First(object):
    def __init__(self):
        super(First, self).__init__()
        print("first")

class Second(object):
    def __init__(self):
        super(Second, self).__init__()
        print("second")

class Third(First, Second):
    def __init__(self):
        super(Third, self).__init__()
        print("third")

La super()chiamata trova il metodo successivo nell'MRO ad ogni passaggio, motivo per cui anche First e Second devono averlo, altrimenti l'esecuzione si interrompe alla fine di Second.__init__().

Questo è quello che ottengo:

>>> Third()
second
first
third

Volevo elaborare un po ' la risposta senza vita perché quando ho iniziato a leggere su come usare super () in una gerarchia di ereditarietà multipla in Python, non l'ho ricevuta immediatamente.

Quello che devi capire è che super(MyClass, self).__init__()fornisce il metodo successivo in __init__ base all'algoritmo MRO (Method Resolution Ordering) utilizzato nel contesto della gerarchia ereditaria completa .

Quest'ultima parte è fondamentale per capire. Consideriamo di nuovo l'esempio:

#!/usr/bin/env python2

class First(object):
  def __init__(self):
    print "First(): entering"
    super(First, self).__init__()
    print "First(): exiting"

class Second(object):
  def __init__(self):
    print "Second(): entering"
    super(Second, self).__init__()
    print "Second(): exiting"

class Third(First, Second):
  def __init__(self):
    print "Third(): entering"
    super(Third, self).__init__()
    print "Third(): exiting"

Secondo questo articolo sull'ordine di risoluzione del metodo di Guido van Rossum, l'ordine da risolvere __init__viene calcolato (prima di Python 2.3) usando un "attraversamento da sinistra a destra in profondità":

Third --> First --> object --> Second --> object

Dopo aver rimosso tutti i duplicati, tranne l'ultimo, otteniamo:

Third --> First --> Second --> object

Quindi, seguiamo cosa succede quando istanziamo un'istanza della Thirdclasse, ad es x = Third().

1. Secondo MRO Third.__init__esegue.
   • stampe Third(): entering
   • quindi super(Third, self).__init__()esegue e restituisce MRO First.__init__che viene chiamato.
2. First.__init__ viene eseguito.
   • stampe First(): entering
   • quindi super(First, self).__init__()esegue e restituisce MRO Second.__init__che viene chiamato.
3. Second.__init__ viene eseguito.
   • stampe Second(): entering
   • quindi super(Second, self).__init__()esegue e restituisce MRO object.__init__che viene chiamato.
4. object.__init__ esegue (nessuna dichiarazione di stampa nel codice lì)
5. l'esecuzione torna a Second.__init__cui poi stampaSecond(): exiting
6. l'esecuzione torna a First.__init__cui poi stampaFirst(): exiting
7. l'esecuzione torna a Third.__init__cui poi stampaThird(): exiting

Questo spiega perché l'istanza di Third () si traduce in:

Third(): entering
First(): entering
Second(): entering
Second(): exiting
First(): exiting
Third(): exiting

L'algoritmo MRO è stato migliorato da Python 2.3 in poi per funzionare bene in casi complessi, ma suppongo che l'uso della "prima traversata da sinistra a destra" + "rimuovendo i duplicati previsti per l'ultimo" continui a funzionare nella maggior parte dei casi (per favore commentare se non è così). Assicurati di leggere il post sul blog di Guido!

Questo è noto come Diamond Problem , la pagina ha una voce su Python, ma in breve, Python chiamerà i metodi della superclasse da sinistra a destra.

Questo è il modo in cui ho risolto il problema di avere l'ereditarietà multipla con diverse variabili per l'inizializzazione e di avere più MixIn con la stessa chiamata di funzione. Ho dovuto aggiungere esplicitamente variabili ai ** kwarg passati e aggiungere un'interfaccia MixIn per essere un endpoint per le super chiamate.

Ecco Auna classe base estensibile Be Csono le classi MixIn che forniscono entrambe la funzione f. Aed Bentrambi si aspettano parametri vnei loro __init__e si Caspettano w. La funzione faccetta un parametro y. Qeredita da tutte e tre le classi. MixInFè l'interfaccia mixin per Be C.

• Taccuino IPython di questo codice
• Github Repo con esempio di codice

class A(object):
    def __init__(self, v, *args, **kwargs):
        print "A:init:v[{0}]".format(v)
        kwargs['v']=v
        super(A, self).__init__(*args, **kwargs)
        self.v = v


class MixInF(object):
    def __init__(self, *args, **kwargs):
        print "IObject:init"
    def f(self, y):
        print "IObject:y[{0}]".format(y)


class B(MixInF):
    def __init__(self, v, *args, **kwargs):
        print "B:init:v[{0}]".format(v)
        kwargs['v']=v
        super(B, self).__init__(*args, **kwargs)
        self.v = v
    def f(self, y):
        print "B:f:v[{0}]:y[{1}]".format(self.v, y)
        super(B, self).f(y)


class C(MixInF):
    def __init__(self, w, *args, **kwargs):
        print "C:init:w[{0}]".format(w)
        kwargs['w']=w
        super(C, self).__init__(*args, **kwargs)
        self.w = w
    def f(self, y):
        print "C:f:w[{0}]:y[{1}]".format(self.w, y)
        super(C, self).f(y)


class Q(C,B,A):
    def __init__(self, v, w):
        super(Q, self).__init__(v=v, w=w)
    def f(self, y):
        print "Q:f:y[{0}]".format(y)
        super(Q, self).f(y)

Capisco che questo non risponda direttamente alla super()domanda, ma ritengo sia abbastanza rilevante da condividere.

C'è anche un modo per chiamare direttamente ogni classe ereditata:

class First(object):
    def __init__(self):
        print '1'

class Second(object):
    def __init__(self):
        print '2'

class Third(First, Second):
    def __init__(self):
        Second.__init__(self)

Nota solo che se si fa in questo modo, dovrete chiamare ogni manualmente come sono abbastanza sicuro che First's __init__()non sarà chiamato.

Complessivamente

Supponendo che tutto discenda da object(sei tu stesso se non lo fa), Python calcola un ordine di risoluzione del metodo (MRO) basato sull'albero ereditario della classe. L'MRO soddisfa 3 proprietà:

• I bambini di una classe vengono prima dei loro genitori
• I genitori di sinistra vengono prima dei genitori di destra
• Una classe appare solo una volta nell'MRO

Se non esiste tale ordinamento, errori Python. Il funzionamento interno di questo è una Linerizzazione C3 delle classi ancestrali. Leggi tutto qui: https://www.python.org/download/releases/2.3/mro/

Pertanto, in entrambi gli esempi seguenti, è:

1. Bambino
2. Sinistra
3. Giusto
4. Genitore

Quando viene chiamato un metodo, la prima occorrenza di quel metodo nell'MRO è quella chiamata. Qualsiasi classe che non implementa quel metodo viene ignorata. Qualsiasi chiamata superall'interno di quel metodo chiamerà la ricorrenza successiva di quel metodo nell'MRO. Di conseguenza, importa sia l'ordine in cui metti le classi in eredità, sia il luogo in cui effettui le chiamatesuper nei metodi.

Con il superprimo in ogni metodo

class Parent(object):
    def __init__(self):
        super(Parent, self).__init__()
        print "parent"

class Left(Parent):
    def __init__(self):
        super(Left, self).__init__()
        print "left"

class Right(Parent):
    def __init__(self):
        super(Right, self).__init__()
        print "right"

class Child(Left, Right):
    def __init__(self):
        super(Child, self).__init__()
        print "child"

Child() Uscite:

parent
right
left
child

Con l' superultimo in ogni metodo

class Parent(object):
    def __init__(self):
        print "parent"
        super(Parent, self).__init__()

class Left(Parent):
    def __init__(self):
        print "left"
        super(Left, self).__init__()

class Right(Parent):
    def __init__(self):
        print "right"
        super(Right, self).__init__()

class Child(Left, Right):
    def __init__(self):
        print "child"
        super(Child, self).__init__()

Child() Uscite:

child
left
right
parent

Chi @ commento di calfzhou , è possibile utilizzare, come di solito, **kwargs:

Esempio di corsa online

class A(object):
  def __init__(self, a, *args, **kwargs):
    print("A", a)

class B(A):
  def __init__(self, b, *args, **kwargs):
    super(B, self).__init__(*args, **kwargs)
    print("B", b)

class A1(A):
  def __init__(self, a1, *args, **kwargs):
    super(A1, self).__init__(*args, **kwargs)
    print("A1", a1)

class B1(A1, B):
  def __init__(self, b1, *args, **kwargs):
    super(B1, self).__init__(*args, **kwargs)
    print("B1", b1)


B1(a1=6, b1=5, b="hello", a=None)

Risultato:

A None
B hello
A1 6
B1 5

Puoi anche usarli in posizione:

B1(5, 6, b="hello", a=None)

ma devi ricordare l'MRO, è davvero confuso.

Posso essere un po 'fastidioso, ma ho notato che le persone si sono dimenticate ogni volta di usare *argse **kwargsquando hanno la precedenza su un metodo, mentre è uno dei pochi usi davvero utili e sani di queste "variabili magiche".

Un altro punto non ancora trattato è il passaggio dei parametri per l'inizializzazione delle classi. Dalla destinazione disuper dipende dalla sottoclasse, l'unico buon modo per passare i parametri è comprimerli tutti insieme. Quindi fai attenzione a non avere lo stesso nome di parametro con significati diversi.

Esempio:

class A(object):
    def __init__(self, **kwargs):
        print('A.__init__')
        super().__init__()

class B(A):
    def __init__(self, **kwargs):
        print('B.__init__ {}'.format(kwargs['x']))
        super().__init__(**kwargs)


class C(A):
    def __init__(self, **kwargs):
        print('C.__init__ with {}, {}'.format(kwargs['a'], kwargs['b']))
        super().__init__(**kwargs)


class D(B, C): # MRO=D, B, C, A
    def __init__(self):
        print('D.__init__')
        super().__init__(a=1, b=2, x=3)

print(D.mro())
D()

dà:

[<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>]
D.__init__
B.__init__ 3
C.__init__ with 1, 2
A.__init__

Chiamare la superclasse __init__direttamente ad un'assegnazione più diretta dei parametri è allettante ma fallisce se ce n'èsuper chiamata in una superclasse e / o l'MRO viene modificato e la classe A può essere chiamata più volte, a seconda dell'implementazione.

Per concludere: l'ereditarietà cooperativa e i parametri super e specifici per l'inizializzazione non funzionano molto bene insieme.

class First(object):
  def __init__(self, a):
    print "first", a
    super(First, self).__init__(20)

class Second(object):
  def __init__(self, a):
    print "second", a
    super(Second, self).__init__()

class Third(First, Second):
  def __init__(self):
    super(Third, self).__init__(10)
    print "that's it"

t = Third()

L'output è

first 10
second 20
that's it

Call to Third () individua l' init definito in Third. E chiama super in quella routine che richiama init definito in First. MRO = [Primo, Secondo]. Ora la chiamata a super in init definita in First continuerà a cercare MRO e troverà init definita in Second e qualsiasi chiamata a super colpirà l'oggetto predefinito init . Spero che questo esempio chiarisca il concetto.

Se non chiami super da First. La catena si interrompe e otterrai il seguente output.

first 10
that's it

In learningpythonthehardway imparo qualcosa chiamato super () una funzione integrata se non sbagliata. Chiamare la funzione super () può aiutare l'eredità a passare attraverso il genitore e i 'fratelli' e aiutarti a vedere più chiaramente. Sono ancora un principiante ma adoro condividere la mia esperienza sull'uso di questo super () in python2.7.

Se hai letto i commenti in questa pagina, sentirai parlare di Method Resolution Order (MRO), poiché il metodo è la funzione che hai scritto, MRO utilizzerà lo schema Depth-First-Left-to-Right per cercare ed eseguire. Puoi fare ulteriori ricerche su questo.

Aggiungendo la funzione super ()

super(First, self).__init__() #example for class First.

Puoi connettere più istanze e 'famiglie' con super (), aggiungendo in ognuno di essi. Ed eseguirà i metodi, esaminandoli e assicurandoti di non aver perso! Tuttavia, aggiungerli prima o dopo fa la differenza, saprai se hai fatto l'apprendimento per l'esercizio 44. Lascia che il divertimento abbia inizio !!

Prendendo l'esempio di seguito, è possibile copiare e incollare e provare a eseguirlo:

class First(object):
    def __init__(self):

        print("first")

class Second(First):
    def __init__(self):
        print("second (before)")
        super(Second, self).__init__()
        print("second (after)")

class Third(First):
    def __init__(self):
        print("third (before)")
        super(Third, self).__init__()
        print("third (after)")


class Fourth(First):
    def __init__(self):
        print("fourth (before)")
        super(Fourth, self).__init__()
        print("fourth (after)")


class Fifth(Second, Third, Fourth):
    def __init__(self):
        print("fifth (before)")
        super(Fifth, self).__init__()
        print("fifth (after)")

Fifth()

Come funziona? L'istanza di fifth () andrà così. Ogni passaggio passa da una classe all'altra in cui è stata aggiunta la super funzione.

1.) print("fifth (before)")
2.) super()>[Second, Third, Fourth] (Left to right)
3.) print("second (before)")
4.) super()> First (First is the Parent which inherit from object)

Il genitore è stato trovato e andrà avanti al terzo e quarto !!

5.) print("third (before)")
6.) super()> First (Parent class)
7.) print ("Fourth (before)")
8.) super()> First (Parent class)

Ora è stato effettuato l'accesso a tutte le classi con super ()! La classe genitore è stata trovata ed eseguita e ora continua a decomprimere la funzione nelle eredità per terminare i codici.

9.) print("first") (Parent)
10.) print ("Fourth (after)") (Class Fourth un-box)
11.) print("third (after)") (Class Third un-box)
12.) print("second (after)") (Class Second un-box)
13.) print("fifth (after)") (Class Fifth un-box)
14.) Fifth() executed

Il risultato del programma sopra:

fifth (before)
second (before
third (before)
fourth (before)
first
fourth (after)
third (after)
second (after)
fifth (after)

Per me aggiungendo super () mi permette di vedere più chiaramente come Python eseguirà la mia codifica e assicurarmi che l'eredità possa accedere al metodo che intendevo.

Vorrei aggiungere ciò che @Visionscaper dice in alto:

Third --> First --> object --> Second --> object

In questo caso, l'interprete non filtra la classe oggetto perché è duplicata, piuttosto perché Second appare in una posizione di testa e non appare nella posizione di coda in un sottoinsieme di gerarchia. Mentre l'oggetto appare solo in posizioni di coda e non è considerato una posizione forte nell'algoritmo C3 per determinare la priorità.

La linearizzazione (mro) di una classe C, L (C), è la

• la classe C
• più l'unione di
  • linearizzazione dei suoi genitori P1, P2, .. = L (P1, P2, ...) e
  • l'elenco dei suoi genitori P1, P2, ..

L'unione linearizzata viene effettuata selezionando le classi comuni che appaiono come head list e non come coda poiché l'ordine conta (diventerà chiaro di seguito)

La linearizzazione di Third può essere calcolata come segue:

    L(O)  := [O]  // the linearization(mro) of O(object), because O has no parents

    L(First)  :=  [First] + merge(L(O), [O])
               =  [First] + merge([O], [O])
               =  [First, O]

    // Similarly, 
    L(Second)  := [Second, O]

    L(Third)   := [Third] + merge(L(First), L(Second), [First, Second])
                = [Third] + merge([First, O], [Second, O], [First, Second])
// class First is a good candidate for the first merge step, because it only appears as the head of the first and last lists
// class O is not a good candidate for the next merge step, because it also appears in the tails of list 1 and 2, 
                = [Third, First] + merge([O], [Second, O], [Second])
// class Second is a good candidate for the second merge step, because it appears as the head of the list 2 and 3
                = [Third, First, Second] + merge([O], [O])            
                = [Third, First, Second, O]

Pertanto, per un'implementazione super () nel seguente codice:

class First(object):
  def __init__(self):
    super(First, self).__init__()
    print "first"

class Second(object):
  def __init__(self):
    super(Second, self).__init__()
    print "second"

class Third(First, Second):
  def __init__(self):
    super(Third, self).__init__()
    print "that's it"

diventa ovvio come questo metodo verrà risolto

Third.__init__() ---> First.__init__() ---> Second.__init__() ---> 
Object.__init__() ---> returns ---> Second.__init__() -
prints "second" - returns ---> First.__init__() -
prints "first" - returns ---> Third.__init__() - prints "that's it"

In Python 3.5+ l'eredità sembra prevedibile e molto piacevole per me. Si prega di guardare questo codice:

class Base(object):
  def foo(self):
    print("    Base(): entering")
    print("    Base(): exiting")


class First(Base):
  def foo(self):
    print("   First(): entering Will call Second now")
    super().foo()
    print("   First(): exiting")


class Second(Base):
  def foo(self):
    print("  Second(): entering")
    super().foo()
    print("  Second(): exiting")


class Third(First, Second):
  def foo(self):
    print(" Third(): entering")
    super().foo()
    print(" Third(): exiting")


class Fourth(Third):
  def foo(self):
    print("Fourth(): entering")
    super().foo()
    print("Fourth(): exiting")

Fourth().foo()
print(Fourth.__mro__)

Uscite:

Fourth(): entering
 Third(): entering
   First(): entering Will call Second now
  Second(): entering
    Base(): entering
    Base(): exiting
  Second(): exiting
   First(): exiting
 Third(): exiting
Fourth(): exiting
(<class '__main__.Fourth'>, <class '__main__.Third'>, <class '__main__.First'>, <class '__main__.Second'>, <class '__main__.Base'>, <class 'object'>)

Come puoi vedere, chiama foo esattamente UNA volta per ogni catena ereditata nello stesso ordine in cui è stata ereditata. Puoi ottenere quell'ordine chiamando . mro :

Quarto -> Terzo -> Primo -> Secondo -> Base -> oggetto

Forse c'è ancora qualcosa che può essere aggiunto, un piccolo esempio con Django rest_framework e decoratori. Ciò fornisce una risposta alla domanda implicita: "perché dovrei volerlo comunque?"

Come detto: stiamo con Django rest_framework e stiamo usando viste generiche e per ogni tipo di oggetto nel nostro database ci troviamo con una classe di vista che fornisce GET e POST per elenchi di oggetti e un'altra classe di vista che fornisce GET , PUT e DELETE per singoli oggetti.

Ora POST, PUT e DELETE vogliamo decorare con login_required di Django. Nota come questo tocca entrambe le classi, ma non tutti i metodi in entrambe le classi.

Una soluzione potrebbe passare attraverso l'ereditarietà multipla.

from django.utils.decorators import method_decorator
from django.contrib.auth.decorators import login_required

class LoginToPost:
    @method_decorator(login_required)
    def post(self, arg, *args, **kwargs):
        super().post(arg, *args, **kwargs)

Allo stesso modo per gli altri metodi.

Nell'elenco delle eredità delle mie classi concrete, aggiungerei il mio LoginToPostprima ListCreateAPIViewe LoginToPutOrDeleteprima RetrieveUpdateDestroyAPIView. Le mie lezioni concrete non getsarebbero state decorate.

Pubblicando questa risposta per il mio futuro riferimento.

L'ereditarietà multipla di Python dovrebbe usare un modello a diamante e la firma della funzione non dovrebbe cambiare nel modello.

    A
   / \
  B   C
   \ /
    D

Lo snippet di codice di esempio sarebbe: -

class A:
    def __init__(self, name=None):
        #  this is the head of the diamond, no need to call super() here
        self.name = name

class B(A):
    def __init__(self, param1='hello', **kwargs):
        super().__init__(**kwargs)
        self.param1 = param1

class C(A):
    def __init__(self, param2='bye', **kwargs):
        super().__init__(**kwargs)
        self.param2 = param2

class D(B, C):
    def __init__(self, works='fine', **kwargs):
        super().__init__(**kwargs)
        print(f"{works=}, {self.param1=}, {self.param2=}, {self.name=}")

d = D(name='Testing')

Qui la classe A è object