Discussion :

[melwin]

Bonjour à tous !

je voudrais savoir quelle est la différence entre ces deux façons de faire, quelle serait la meilleure façon de faire ou dans quel cas les utiliser.
Il est fort possible que je sois passé à côté de quelque chose et que je n'ai pas vraiment tout saisi, d'où ma question.

Première syntaxe

Code :

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

1
2
3
4
5
class Application(Frame):
 
    def __init__(self, master):
        Frame.__init__(self, master)
        self.pack()

Deuxième syntaxe

Code :

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

1
2
3
4
5
6
class Application:
 
    def __init__(self, master):
        self.myMaster = master
        self.myContainer = Frame(master)
        self.myContainer.pack()

Merci d'avance pour vos lumières

[wiztricks]

Salut,

Tant que l'interpréteur accepte votre code et que le machin fonctionne, la syntaxe est valide et à défaut d'appliquer un "standard" côté "style", who care?

Pourquoi n'écririez vous pas:

Code :

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

1
2
3
app = tk.Tk()
w = tk.Frame()
w.pack()

Si ce code fait "pareill" que les votres, sa lecture (vous) raconte une autre histoire.

Autrement dit "pourquoi":
- créer une boîte "class" alors que vous n'avez encore besoin que d'instances de "class" qui existent déjà?
- appeler Application une chose qui n'est pas s/classe de Tk?

note: "j'écris comme je veux et puis nah!!!" est une réponse tout à fait acceptable (dans un forum, à une revue de code peut être pas)

- W

[Bktero]

Au-delà de la syntaxe, il y a surtout une très grande différente conceptuelle. Dans un cas, Application hérite de Frame et donc est une Frame. Dans l'autre, Application contient une Frame. C'est héritage vs encapsulation.

[melwin]

Bonjour Wiztricks, toujours un plaisir...

Je n'ai pas changé, je fais, refais, essaye, analyse, essaye de comprendre, veux faire avec la manière de faire, etc. mon côté rigide cartésien...

Donc oui, le code fonctionne, la syntaxe est valide. Yes, but forget the yes, je m'en soucie, je veux m'imposer un style, une bonne façon de faire, peut-être est-ce une erreur...

Ensuite, j'aime bien les conteurs, peux-tu me raconter cette histoire ? Sans vouloir abuser bien entendu...


J'ai lu au travers de mes nombreuses lectures, que les raisons de structurer son programme en tant que classe est :
- d'éviter d'utiliser des variables globales.
- de mieux structurer son programme, surtout un gros programme.

Alors les choix dans ces exemples ne sont peut être pas judicieux, c'était juste pour présenter les deux styles et de comprendre le pourquoi du comment et quand...


réponse de note : vous êtes libre de vous exprimer à votre façon. Une réponse est une réponse, toujours beaucoup mieux que pas de réponse du tout. Cette réponse en dit plus qu'elle ne pourrait le faire croire...

[melwin]

Au-delà de la syntaxe, il y a surtout une très grande différente conceptuelle. Dans un cas, Application hérite de Frame et donc est une Frame. Dans l'autre, Application contient une Frame. C'est héritage vs encapsulation.

Et les waters mon cher Manson ! Merci beaucoup pour cette réponse fort claire et qui a allumé ma loupiote, pas encore une lanterne, mais qui sait un jour peut être...

[fred1599]

J'ai lu au travers de mes nombreuses lectures, que les raisons de structurer son programme en tant que classe est :
- d'éviter d'utiliser des variables globales.
- de mieux structurer son programme, surtout un gros programme.

Alors pas ok pour les deux,

On peut éviter les globales par autre chose que des classes

Code :

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

1
2
3
4
5
6
7
>>> def modif(n):
...     VARIABLES['x'] = n
... 
>>> VARIABLES = {'x': 2}
>>> modif(5)
>>> print(VARIABLES['x'])
5

Ensuite il y a bien structuré sans classes, si on comprend bien l'algorithme en lisant ton code et que tu respectes la PEP8.

La notion de classe on l'utilise souvent quand beaucoup d'objets sont à gérer.

Pour ton 1er post, la réponse est donnée par bktero, limite on pourrait dire pour donner un équivalent, et comme a voulu te faire comprendre wiztricks, Application devrait hériter de Tk et non Frame...

Après pourquoi classe ? Ça va dépendre de la problématique, il n'y a pas de style qui fonctionne à tous les coups, mais des styles adaptés à chaque problème.

[melwin]

Merci pour ces réponses, ça m'aide beaucoup à avancer.
Donc voilà ou j'en suis

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
#############################################################################
# Programme Python                                                          #
# auteur : JM MARTY, Montélimar, 2014                                       #
# licence : GPL                                                             #
#############################################################################
 
#############################################################################
# Importation de fonctions externes :
 
from tkinter import *
from tkinter.messagebox import *
 
#############################################################################
# Définition locale de fonctions :
 
class Application:
    """ Mon application : menus "Fichier", "Aide" avec fonctions simples """
 
    def __init__(self, parent):
        self.myParent = parent
        self.myContainer = Frame(parent)
        self.myContainer.pack()
        #---------- Zone d'affichage : myZone -------------------
        self.myZone = Canvas(self.myContainer,
            bg = "light grey", height = 640, width = 640)
        self.myZone.pack()
        #---------- Création barre de Menu : barMenu ------------
        self.barMenu = Menu(self.myContainer)
        #---------- Création du menu : "Fichier" ----------------
        self.fichier = Menu(self.barMenu, tearoff = 0)
        self.barMenu.add_cascade(label = "Fichier", underline = 0,
            menu = self.fichier)
        self.fichier.add_command(label = "Ouvrir", underline = 0,
            command = self.ouvrir)
        self.fichier.add_command(label = "Fermer", underline = 0,
            command = self.fermer)
        self.fichier.add_command(label = "Enregistrer", underline = 0,
            command = self.enregistrer)
        self.fichier.add_command(label = "Quitter", underline = 0,
            command = self.quitter)
        #---------- Création du Menu : "Aide" -------------------
        self.aide = Menu(self.barMenu, tearoff = 0)
        self.barMenu.add_cascade(label = "Aide", underline = 0,
            menu = self.aide)
        self.aide.add_command(label = "A propos", underline = 0,
            command = self.apropos)
        #---------- Afficher le Menu : barMenu    
        self.myParent.config(menu = self.barMenu)
 
    def ouvrir(self):
        self.myZone.delete(ALL)    
        self.myZone.create_text(10 , 10, anchor = NW, text = "Ouvrir")
 
    def fermer(self):
        self.myZone.delete(ALL)    
        self.myZone.create_text(10 , 10, anchor = NW, text = "Fermer")
 
    def enregistrer(self):
        self.myZone.delete(ALL)   
        self.myZone.create_text(10 , 10, anchor = NW, text = "Enregistrer")
 
    def quitter(self): self.myParent.destroy()
 
    def apropos(self):
        #self.myZone.delete(ALL)
        #self.myZone.create_text(10 , 10, anchor = NW, text = "Application 1.0")
        showinfo('A propos', 'Application 1.0 \n\r Programme Python \n Montélimar 2014'
                 ' \n Auteur : JM MARTY \n Licence : GPL')
 
#############################################################################
# Corps principal du programme
racine = Tk()
racine.title("Mon Application")
appli = Application(racine)
racine.mainloop()
racine.destroy()

[wiztricks]

Salut,

C'est pas pour critiquer mais quand la lecture de votre code me fait penser: "tiens! on pousse les variables globales sous le chapeau application".

Pour moi, les classes sont un outil comme un autre pour organiser son code.
Les GUI apportent une difficulté supplémentaire car un widget est à la fois du code mais aussi la représentation d'un chose externe avec laquelle interagira l'utilisateur.

Ici, on fait quoi?
On crée un menu avec des sous-menus.
L'essentiel d'un menu et de ses sous-menus se réduit à une structure hiérarchique contenant des 'labels' auxquels on va associer des actions qui pour la plupart mettent a jour l'item text d'un Canvas.

Intuitivement, l'important sera l'association 'label' => commande, la création du Menu et des s/menus et les actions associées aux Commandes.

En forçant un peu le trait, çà donne un code qui ressemble à çà:

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
import tkinter as tk
from tkinter.messagebox import showinfo
 
FILE_MENU = dict(
    label = 'Fichier',
    command_items = [ 
            ('Ouvrir', 'do_open_file'),
            ('Fermer', 'do_close_file'),
            ('Enregistrer', 'do_save_file'),
            ('Quitter', 'do_quit'),
            ]
    )
 
HELP_MENU = dict(
    label = 'Aide',
    command_items = [ 
            ('A Propos', 'do_help'),
            ]                 
    )
 
def create_menu(toplevel, actions):
 
    def create_submenu(menu, command_items):
        submenu = tk.Menu(menu)
        for text, name in command_items:
            assert hasattr(actions, name)
            submenu.add_command(label=text, command=getattr(actions, name), underline = 0)
        return submenu
 
    menu = tk.Menu(toplevel)
    for zot in (FILE_MENU, HELP_MENU):
        label, command_items = zot['label'], zot['command_items']
        submenu = create_submenu(menu, command_items)
        menu.add_cascade(label = label, underline=0, menu=submenu)
    toplevel['menu'] = menu
 
class Actions:
 
    def do_quit(self): 
        app.quit()
 
    def do_help(self):
         showinfo('A propos', 'Application 1.0 \n\r Programme Python \n Montélimar 2014'
                 ' \n Auteur : JM MARTY \n Licence : GPL') 
 
    def __init__(self, canvas):
 
        self.canvas = canvas
        canvas.create_text(10 , 10, anchor ='nw', tag='text_box')
        for name in ('do_open_file', 'do_close_file', 'do_save_file'):
            action = lambda p=name: self.canvas.itemconfigure('text_box', text = p)
            setattr(self, name, action)
 
if __name__ == '__main__':
 
    app = tk.Tk()
    app.title("Mon Application")
 
    canvas = tk.Canvas(app, bg = "light grey", height = 640, width = 640)
    canvas.pack()
    actions = Actions(canvas)
 
    create_menu(app, actions)
    app.mainloop()

- W

[melwin]

Salut,

justement, j'avais mis le code pour avoir des critiques et la critique n'est pas obligatoirement négative...

Pour expliquer le pourquoi du comment, les méthodes sont juste pour faire quelque chose, le but au final n'étant pas d'écrire du texte dans le Canvas bien entendu.

Je m'inspire de ce qui est fait dans les livres de Gérard Swinnen "Apprendre à programmer avec Python 3" (lu plusieurs fois et fait les différents exercices des chapitres), Vincent Le Goff ""Apprenez à programmer en Python" et pas mal de site sur internet abordant les sujet Python, GUI et BD.
Pour ce type de menu, je me suis inspiré du site de Tyrtamos, où est abordé un chapitre de la programmation graphique avec Tkinter et la réalisation d'une barre de menu. Ensuite, je voulais, juste pour la gymnastique, écrire dans le Canvas plutôt que dans le shell comme proposé dans le programme initial.
Le but final c'est d'ajouter au fur et à mesure des modifications. La suite ce serait l'enregistrement de données dans une BD (SQLite ou PostgreSQL) et à la fin d'y accéder à travers le réseau. Oui je sais c'est pas encore gagné...

Alors effectivement, la difficulté supplémentaire du GUI je l'ai bien rencontrée, parce que j'essaye de bien assimiler pour que plus tard ce ne soit plus que formalité pour refaire ce genre de programme.

Je souhait non seulement arriver à programmer en python mais à y être de le faire proprement. Donc je suis friand de remarques, critiques...
Je suis bien conscient que la route est encore longue, surtout qu'à chaque fois j'ai l'impression de prendre un coup de bambou derrière la tête.
Rassures moi quand même, ce n'est pas complètement nul ce que je fais ?

Donc, j'ai biens compris l'utilisation de Dictionnaire et bien vu l'utilisation de lambda déjà vu dans "Penser en Tkinter"

[wiztricks]

Je suis bien conscient que la route est encore longue, surtout qu'à chaque fois j'ai l'impression de prendre un coup de bambou derrière la tête.
Rassures moi quand même, ce n'est pas complètement nul ce que je fais ?

Beuh non, puisque çà fonctionne.

Mon propos était de montrer que la structure du code est une question de parti pris i.e. de choix.
Qui dit "choix" dit arbitrage entre avantages et inconvénients qu'il faut motiver par rapport à un contexte.
In fine, seul le programmeur pourra expliquer pourquoi une structure est préférable à une autre.

- W