La meilleure façon de structurer une application tkinter ?

Question

Voici la structure générale de mon programme python tkinter typique.

def funA():
    def funA1():
        def funA12():
            # stuff

    def funA2():
        # stuff

def funB():
    def funB1():
        # stuff

    def funB2():
        # stuff

def funC():
    def funC1():
        # stuff

    def funC2():
        # stuff

root = tk.Tk()

button1 = tk.Button(root, command=funA)
button1.pack()
button2 = tk.Button(root, command=funB)
button2.pack()
button3 = tk.Button(root, command=funC)
button3.pack()

funA funB y funC fera apparaître un autre Toplevel Fenêtres avec widgets lorsque l'utilisateur clique sur le bouton 1, 2, 3.

Je me demande si c'est la bonne façon d'écrire un programme python tkinter ? Bien sûr, cela fonctionnera même si j'écris de cette façon, mais est-ce la meilleure façon ? Cela semble stupide mais quand je vois les codes écrits par d'autres personnes, leur code n'est pas embrouillé par un tas de fonctions et la plupart ont des classes.

Y a-t-il une structure spécifique que nous devrions suivre comme bonne pratique ? Comment dois-je planifier avant de commencer à écrire un programme python ?

Je sais que les meilleures pratiques en matière de programmation n'existent pas et je ne les demande pas non plus. Je veux juste des conseils et des explications pour rester dans la bonne direction alors que j'apprends Python tout seul.

Answer 1

L'organisation de votre application à l'aide de classes vous permet, à vous et aux autres personnes qui travaillent avec vous, de déboguer facilement les problèmes et d'améliorer l'application.

Vous pouvez facilement organiser votre application comme ceci :

class hello(Tk):
    def __init__(self):
        super(hello, self).__init__()
        self.btn = Button(text = "Click me", command=close)
        self.btn.pack()
    def close():
        self.destroy()

app = hello()
app.mainloop()

Answer 2

La meilleure façon d'apprendre à structurer votre programme est probablement de lire le code d'autres personnes, surtout s'il s'agit d'un grand programme auquel de nombreuses personnes ont contribué. Après avoir examiné le code de nombreux projets, vous devriez avoir une idée de ce que devrait être le style consensuel.

Python, en tant que langage, a ceci de particulier qu'il existe des directives strictes sur la manière dont vous devez formater votre code. La première est ce qu'on appelle le "Zen de Python" :

• Le beau est mieux que le laid.
• L'explicite est préférable à l'implicite.
• La simplicité est préférable à la complexité.
• Le complexe est mieux que le compliqué.
• Le plat est meilleur que l'imbriqué.
• Le clairsemé est préférable au dense.
• La lisibilité compte.
• Les cas particuliers ne sont pas assez particuliers pour enfreindre les règles.
• Bien que l'aspect pratique batte la pureté.
• Les erreurs ne doivent jamais passer en silence.
• Sauf si elle est explicitement réduite au silence.
• Face à l'ambiguïté, refusez la tentation de deviner.
• Il devrait y avoir une - et de préférence une seule - manière évidente de le faire.
• Bien que cette voie ne soit pas forcément évidente au premier abord, à moins d'être néerlandais.
• Mieux vaut maintenant que jamais.
• Bien que jamais soit souvent mieux que droite maintenant.
• Si la mise en œuvre est difficile à expliquer, c'est une mauvaise idée.
• Si la mise en œuvre est facile à expliquer, cela peut être une bonne idée.
• Les espaces de noms sont une idée géniale - il faut en faire plus !

D'un point de vue plus pratique, il y a PEP8 le guide de style pour Python.

En gardant cela à l'esprit, je dirais que le style de votre code ne convient pas vraiment, en particulier les fonctions imbriquées. Trouvez un moyen de les aplanir, soit en utilisant des classes, soit en les déplaçant dans des modules séparés. Cela rendra la structure de votre programme beaucoup plus facile à comprendre.

Answer 3

Personnellement, je n'utilise pas l'approche orientée objet, principalement parce qu'elle a) ne fait que vous gêner ; b) vous allez jamais réutiliser cela comme un module.

mais quelque chose qui n'est pas discuté ici, est que vous doit utiliser le threading ou le multiprocessing. Toujours. Sinon, votre application sera affreuse.

Faites un test simple : démarrez une fenêtre, puis récupérez une URL ou autre chose. Il est probable que votre interface utilisateur ne sera pas mise à jour pendant que la requête réseau est en cours. Cela dépend du système d'exploitation que vous utilisez, mais la plupart du temps, elle ne se redessinera pas, tout ce que vous ferez glisser sur la fenêtre y sera collé, jusqu'à ce que le processus revienne à la boucle principale de la TK.