Discussion :

[fred1599]

Ton exemple ne coïncide pas avec QDialog et ses deux arguments optionnels. vehicule a son initialisation prend un argument obligatoire, on est donc obligé lors de l'héritage de l'utiliser avec super().__init__(vMax=...).

En appelant super().__init__() il appelle la classe mère avec ses deux arguments par défaut, il n'y a pas besoin de les spécifier. C'est comme exécuter une fonction avec des arguments optionnels.

Code :

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

1
2
3
def test(a=2, b=3):
    pass
test()  # pas d'erreur

[Sve@r]

Ton exemple ne coïncide pas avec QDialog et ses deux arguments optionnels. vehicule a son initialisation prend un argument obligatoire, on est donc obligé lors de l'héritage de l'utiliser avec super().__init__(vMax=...).

J'ai précisé que ça fonctionne aussi avec les arguments optionnels. Remplace (dans l'objet d'origine) vMax par vMax=200 par exemple...

En appelant super().__init__() il appelle la classe mère avec ses deux arguments par défaut, il n'y a pas besoin de les spécifier.

Toute la question est là: et s'il veut les spécifier justement ? S'il veut appeler son objet avec un parent (parce que la parenté sous Qt c'est super important et que là il ne s'en préoccupe pas du tout) ???
Le principe est de pouvoir tout offrir, et pas seulement offrir le cas par défaut.

[fred1599]

Toute la question est là: et s'il veut les spécifier justement ?

Il me semble que ce choix est un choix délibéré, il veut utiliser les paramètres par défaut pour parent et f.

S'il veut appeler son objet avec un parent (parce que la parenté sous Qt c'est super important et que là il ne s'en préoccupe pas du tout) ???

C'est important, mais dans son cas, il n'a pas ce besoin à mon sens. Si on met des valeurs par défaut, c'est justement prévu que si on ne les utilise pas, ça rend tout de même fonctionnel le code. Il semble que ce choix lui convienne...

Remplace (dans l'objet d'origine) vMax par vMax=200 par exemple...

Eh bien je peux l'écrire

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class vehicule:
    def __init__(self, vMax=200):
        self.vMax=vMax
 
class voiture(vehicule):
    def __init__(self, marque):
        super().__init__(vMax=160)
        self.marque=marque
 
v = voiture("renault")
 
print(v.vMax)  # 160

ou comme cela si je sais que ma renault roule à 200 km max

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class vehicule:
    def __init__(self, vMax=200):
        self.vMax=vMax
 
class voiture(vehicule):
    def __init__(self, marque):
        super().__init__()
        self.marque=marque
 
v = voiture("renault")
print(v.vMax)  # 200

[Sve@r]

Il me semble que ce choix est un choix délibéré, il veut utiliser les paramètres par défaut pour parent et f.

C'est important, mais dans son cas, il n'a pas ce besoin à mon sens. Si on met des valeurs par défaut, c'est justement prévu que si on ne les utilise pas, ça rend tout de même fonctionnel le code. Il semble que ce choix lui convienne...

C'est un avis (qui suit celui de papajoker). Je ne peux que te répondre la même chose: je suis parti du postulat que Diablo76 voulait notre avis, je lui ai donné le mien. Toutefois les habitudes ont la vie dure et on peut aussi penser que s'il code ses objets Qt de cette façon ici il les code de la même façon de partout
Je t'invite à aller voir mon exemple Qt n° 6 Construire des widgets en vrac où je crée un objet Qt de mon cru contenant un slider et un lcd associé, puis une fois créé, quand il est devenu tout aussi manipulable et indépendant que tout autre widget Qt, je l'utilise à ma convenance et en place plusieurs dans un gridLayout.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class vehicule:
    def __init__(self, vMax=200):
        self.vMax=vMax
 
class voiture(vehicule):
    def __init__(self, marque):
        super().__init__(vMax=160)
        self.marque=marque
 
v = voiture("renault")
 
print(v.vMax)  # 160

ou comme cela si je sais que ma renault roule à 200 km max

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class vehicule:
    def __init__(self, vMax=200):
        self.vMax=vMax
 
class voiture(vehicule):
    def __init__(self, marque):
        super().__init__()
        self.marque=marque
 
v = voiture("renault")
print(v.vMax)  # 200

Et donc ton objet "voiture" ne permet pas de lui spécifier une quelconque vMax. C'est aussi une façon de voir les choses mais qui n'est pas la mienne et qui (désolé de le faire remarquer), me semble aller à l'encontre de ta précédente remarque sur les avantages recherchés dans l'héritage (quand tu disais au post #10 que créer un héritage est fait pour avoir des attributs en plus). C'est donc dommage de faire un héritier qui ne permet plus l'accès aux paramètres de l'ancètre.
Et puis (rappel: cette discussion est juste là parce que tu as demandé que je t'explique ma remarque du post 1 donc je te l'explique bien volontiers) moi j'aime bien la souplesse et il me semble que la solution n° 2 à base de *args et **kwargs offre toute la souplesse du monde. Permet de spécifier une vMax si on veut, ou prendre la vMax par défaut...

Code python :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class vehicule:
	def __init__(self, vMax=200):
		self.vMax=vMax
 
class voiture(vehicule):
	def __init__(self, marque, *args, **kwargs):
		super().__init__(*args, **kwargs)
		self.marque=marque
 
v1 = voiture("renault")
print(v1.vMax)  # 200
 
v2 = voiture("bmw", vMax=360)
print(v2.vMax)  # 360

Et si demain la lib "vehicule v2" rajoute une vMin je n'aurai absolument rien à toucher à mon objet "voiture", il s'y adaptera automatiquement. Seuls les utilisateurs de mon objet devront s'y adapter (mais ça c'est normal quand la lib change).

[fred1599]

Et puis (rappel: cette discussion est juste là parce que tu as demandé que je t'explique ma remarque du post 1 donc je te l'explique bien volontiers) moi j'aime bien la souplesse et il me semble que la solution n° 2 à base de *args et **kwargs offre toute la souplesse du monde.

Elle a plus de souplesse, le problème n'est pas vraiment là, je comprend ton point de vue, et je pense que @papajoker aussi, je voulais surtout exprimer que l'on peut accepter et croire que le développeur a bien décidé cette manière de faire, c'est lui qui développe son projet. On peut se questionner sur la manière de faire, et proposer une autre manière d'écrire, mais il pourrait ne pas là comprendre, car ce n'est peut-être pas une décision prise à la légère (bénéfice du doute) et surtout comme ça fonctionne, qu'est-ce que ça lui apportera sur un projet qui n'évoluera pas ?

Bref je t'ai un peu titiller, mais j'aime bien parler POO, j'ai pas pu m'empêcher...

[Sve@r]

Bref je t'ai un peu titiller, mais j'aime bien parler POO, j'ai pas pu m'empêcher...

Compris

[Diablo76]

Salut,

Merci pour vos retours.

Autre chose: hériter de Qt c'est bien... mais cela ne doit pas faire perdre les avantages des objets d'origine (autrement dit, on préserve les objets et tous leurs paramètres). Surtout...

Code :

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

1
2
3
4
class UbuntuDesktopFileCategoriesView(QDialog):
    """Manage the Ubuntu Desktop File Categories View."""
    def __init__(self, *args, **kwargs) -> None:
        super().__init__(*args, **kwargs)

...que ce n'est franchement pas super compliqué...

Effectivement, ici l'héritage de QDialog ne m'intéresse que pour le mode Modal (mais j'ai pris en compte des remarques et arguments).

En fait, il nous manque une info ! Quelle est la logique derrière ce code ?
Si le but est juste qu'il fonctionne, alors ok pour le code
Si le but est de faire un "template" de bon code (je soupçonne avec les noms controleur et modele), alors c'est loupé.

Un template de bon code, non, un code qui fonctionne déjà, c'est pas mal. Après, je ne suis pas encore à l'aise avec la notion de MVC (Je vois de tout et de rien sur le net...)

Peux-tu développer : "Qt a son propre système mvc"

[Sve@r]

Après, je ne suis pas encore à l'aise avec la notion de MVC (Je vois de tout et de rien sur le net...)

C'est une méthode de développement dans laquelle on sépare un projet en 3 grands domaines

• le Modèle (tout ce qui a trait à la sauvegarde des datas => fichier, bdd, ...)
• la Vue (tout ce qui a trait à la saisie et affichage => print, input, IHM, ..)
• le Contrôleur ou Calcul (tout ce qui permet de générer une info Y à partir d'une info X)

En séparant les 3 domaines et en les isolant, on peut généralement plus ou moins facilement en changer (remplacer les fichiers par une bdd, remplacer les print/input par des menus déroulants, ...)

Peux-tu développer : "Qt a son propre système mvc"

En théorie, Qt c'est une GUI. C'est dans ce but que cet lib a été démarrée. Et GUI c'est juste la partie "Vue" de MVC.
Mais depuis elle s'est développée de façon tentaculaire pour offrir de la gestion de fichier ou de bdd (partie "M") et de la gestion de threads qui peuvent faire la partie "C", et plein d'autres choses encore. Et donc au final on peut faire tout le MVC par Qt.
Perso j'aime pas. Ce n'est jamais bon de mettre tous ses oeufs dans le même panier et l'informatique ne fait pas exception. J'aime Qt pour sa partie V mais moi pour le M et le C j'utilise d'autres libs.

[papajoker]

Pour forcément à utiliser dans ton cas ...

Qt a son propre système (pas du mvc classique) et c'est dans la doc !

python ou C++ c'est la même doc
Note: pySide est la lib officielle python pour faire du Qt

Puisque tu utilises un formulaire, la solution pour ton besoin spécifique serait le QDataWidgetMapper ( et est dispo un exemple)

---------

Si on désire une classe particulière pour le controleur/présentateur, rien n'est fait mais c'est possible, voir cet exemple mais, surtout cet article (en)



=========
Re-note: pour moi, c'est une aberration d'écrite un outil en Qt pour un bureau gnome !!!!
https://github.com/Taiko2k/GTK4PythonTutorial
https://github.com/yucefsourani/pyth...-gtk4-examples
https://discourse.gnome.org/tag/python