Discussion :

[Yuseph]

Yo les gars,

Aidez-moi j'ai trop le cerveau qui fume avec ce truc. Comment faire pour récupérer bank_freeze avec super ??
J'ai bien compris que super override la subclass qui elle-même override la main class.
Je comprends mieux pourquoi l'auteur prône les compositions plutôt que les inheritances.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
# ALTERING INHERITANCE
from datetime import date
 
class Client(object):
    raw_date = date.today()
    date = raw_date.strftime("%d/%B/%Y")
    def __init__(self, first_name, bank_freeze):
        self.first_name = first_name
        self.bank_freeze = bank_freeze
    def printout(self):
        print(self.first_name, self.bank_freeze)
 
class Order(Client):
    def __init__(self, amount):
        self.date = Client.date
        self.amount = amount
    def printout(self):
        print(self.amount, self.date)
        super().__init__ ???
 
 
first_client = Order("$100")
 
Order.printout(first_client)

[wiztricks]

bank_freeze est un attribut créé par l'__init__ialisation de Client.

Si Order hérite de Client (quelle idée? Est ce qu'une commande est un Client? mais bon...), il devra appeler l'__init__ de sa classe mère dans son __init__ à lui... sinon aucune chance d'être un Client (avoir les attributs qui vont avec après la création d'un Order).

Pour plus de détails, ouvrez un tuto. aux chapitres qui parlent des classes avec Python. Lisez ce qu'ils racontent, essayez de comprendre et vérifiez le en essayant de faire les exercices (corrigés).

- W

[Sve@r]

Bonjour

Aidez-moi j'ai trop le cerveau qui fume avec ce truc.

T'as lu la doc au moins???

J'ai bien compris que super override la subclass qui elle-même override la main class.

Alors pourquoi tu appelles super().__init__() dans une méthode qui n'est pas __init__()???

Comment faire pour récupérer bank_freeze avec super ??

Tu n'as pas besoin de super pour ça. Ton Order hérite de Client, il possède donc tous les attributs publics de Client donc aussi l'attribut bank_freeze.

Si maintenant ce que tu appelles "récupérer" c'est "surcharger la méthode printout du parent dans l'objet hérité", là aussi on utilise super

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# ALTERING INHERITANCE
from datetime import date
 
class Client(object):
	raw_date = date.today()
	date = raw_date.strftime("%d/%B/%Y")
	def __init__(self, first_name, bank_freeze):
		self.first_name = first_name
		self.bank_freeze = bank_freeze
	def printout(self):
		print(self.first_name, self.bank_freeze)
 
class Order(Client):
	def __init__(self, amount, *args, **kwargs):
		self.date = Client.date
		self.amount = amount
 
		# C'est ici, dans le constructeur de l'héritier qu'on appelle le constructeur du parent (pour justement créer le parent)
		super().__init__(*args, **kwargs)	# Tous les paramètres qui ne sont pas traités par "Order" sont renvoyés au parent
 
	def printout(self):
		print(self.amount, self.date)
		super().printout()
 
first_client = Order("$100", "Yuseph", "$150")		# Si Order hérite de Client, alors il doit être appelé avec les paramètres demandés par Client !!!
first_client.printout()
print(first_client.bank_freeze)		# Comme quoi, super ce n'est pas le truc magique qu'on place au petit bonheur en espérant tomber juste...

Je comprends mieux pourquoi l'auteur prône les compositions plutôt que les inheritances.

Quel auteur? Dans quel contexte? En informatique (comme d'ailleurs dans toute science) il n'y a pas d'absolu en matière d'outils. Ce midi j'ai démonté mon clavier pour le nettoyer, j'ai utilisé un cruciforme mais je n'irai pas dire "je prône l'utilisation du cruciforme" parce que le jour où je devrai planter un clou...

[Yuseph]

oh boudiou j'ai réussi les baby boys

j'ai souffert pour sortir le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
from datetime import date
 
class Client(object):
    def __init__(self, first_name, bank_freeze):
        self.first_name = first_name
        self.bank_freeze = bank_freeze
        self.date = date.today()
        self.date = self.date.strftime("%d-%B-%Y")
    def printout(self):
        return f'{self.first_name} / {self.bank_freeze} / {self.date}'
 
class Buying_Client(Client):
    def __init__(self, first_name, bank_freeze, amount):
        super().__init__(first_name, bank_freeze)
        self.amount = amount
    def printout(self):
        parent = super().printout()
        print(f'{parent} / {self.amount}')
 
 
first_client = Buying_Client("John", True, "$100")
 
Buying_Client.printout(first_client)

oui args et kwargs ça m'a l'air pas mal. c'est pas dans les bouquins mais je vais essayer de suite.

[Sve@r]

j'ai souffert pour sortir le code

Attention, la méthode "Client.printout" retourne une string tandis que la méthode "Buying_Client.printout" affiche une string à l'écran mais ne retourne rien.
C'est pas interdit en Python (la preuve ça marche) mais c'est interdit en POO. Un objet hérité est présumé fonctionner au minimum à l'identique de l'objet originel. L'utilisateur a donc le droit d'utiliser Client.printout tout comme Buying_Client.printout et doit récupérer dans les deux cas la même chose.

Buying_Client.printout(first_client)

Utilise l'écriture traditionnelle first_client.printout(), t'as moins de risque de faire une connerie...

oui args et kwargs ça m'a l'air pas mal. c'est pas dans les bouquins mais je vais essayer de suite.

Essaye de trouver une doc dessus avant d'essayer en aveugle...

[Yuseph]

C'est bon pour args et kwargs. Donc ça attrape tous les attributs de la main class si j'ai bien pigé.
Mais quel intérêt ? puisque en général de la subclass on cherche juste à attraper "certains" attributs de la main class

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
from datetime import date
class Client (object):
    raw_date = date.today()
    date = raw_date.strftime("%d-%B-%Y")
    def __init__(self, first_name, last_name, bank_freeze):
        self.first_name = first_name
        self.bank_freeze = bank_freeze
        self.last_name = last_name
    def printout(self):
        return f'{self.first_name} / {self.last_name} / {self.bank_freeze} / {Client.date}'
class Buying_Client(Client):
    def __init__(self, amount, *args, **kwargs): # args and kwargs take all the arguments
        super().__init__(*args, **kwargs)
        self.amount = amount
    def printout(self):
        parent = super().printout()
        return (f'{parent} / {self.amount}')
 
first_client = Buying_Client("$100", "John", "DOE", True)
storing = Buying_Client.printout(first_client)
print(storing)

[wiztricks]

Mais quel intérêt ? puisque en général de la subclass on cherche juste à attraper "certains" attributs de la main class

Dans tous les bons tutos, *args et **kwargs sont présentés dans les chapitres qui traitent des fonctions. Si vous êtes parti dans les classes et la POO sans avoir pris le temps de maîtriser ces bases, tant pis pour vous.

- W

[Sve@r]

C'est bon pour args et kwargs. Donc ça attrape tous les attributs de la main class si j'ai bien pigé.

Ca attrape tous les arguments non spécifiques passés à une fonction

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
>>> def etat_civil(nom, *args, grade, **kwargs):
...	print("nom=", nom, type(nom))
...	print("args=", args, type(args))
...	print("grade=", grade, type(grade))
...	print("kwargs=", kwargs, type(kwargs))
...
>>> etat_civil("Cesar", "Julius", "Caius", grade="General", victoire="Alesia", defaite="Gergovie")
nom= Cesar <class 'str'>
args= ('Julius', 'Caius') <class 'tuple'>
grade= General <class 'str'>
kwargs= {'victoire': 'Alesia', 'defaite': 'Gergovie'} <class 'dict'>

Le premier argument "Cesar" est récupéré dans le premier paramètre positionnel (ici "nom") ; l'argument nommé "grade" est récupéré lui dans le paramètre nommé à l'identique. Et les autres sont récupérés dans "arg" ou "kwargs" selon qu'ils ont été nommés ou pas (args récupère ceux qui n'ont pas de noms)

Mais quel intérêt ? puisque en général de la subclass on cherche juste à attraper "certains" attributs de la main class

Déjà ça t'évite, quand tu crées un héritage, de te taper toute la doc de l'objet dont tu hérites pour savoir quels éléments il attend pour les reporter dans ton objet
Exemple (dans mes objet PyQt)

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class myWidget(QWidget):
	def __init__(self, *args, **kwargs):
		super().__init__(*args, **kwargs)

De quoi a besoin un QWidget quand on le crée? J'en sais rien. Je sais simplement que celui qui appellera mon objet, lui il le sait (il pense utiliser un QWidget donc il est censé savoir de quoi ce QWidget a besoin) donc il passera à mon objet tout ce que le QWidget attend et moi je transfère le tout au QWidget sans me poser de question.

Et si ensuite demain le QWidget évolue et que de nouveaux attributs voient le jour mon objet s'adapte automatiquement.

[wiztricks]

Si maintenant ce que tu appelles "récupérer" c'est "surcharger la méthode printout du parent dans l'objet hérité", là aussi on utilise super

"surcharger" n'existe pas avec Python: on se contente de redéfinir avec appel ou pas de la méthode identique des parents... appel qu'on ne peut omettre pour l'initialisation de l'instance.

- W