Discussion :

[Ruyneau]

Bonjour,

J'ai un <<assez gros>> programme (du moins pour moi) utilisant le module tkinter et il y a des petits bugs qui ne sont pas bloquants (et que j'essaie de corriger au fur et à mesure). Mon éditeur de python est Idle.
Lorsque je lance mon programme à partir d'Idle (en tapant F5) et qu'il y a un petit bug, sur une fenêtre Python, il m'affiche l'origine de l'erreur mais mes fenêtres ouvertes par mon programme restent ouvertes et le programme continue à tourner (et je peux continuer à l'utiliser)
Par contre, si je lance directement mon programme (en pyw). Dès que le pg rencontre un bug, tout le programme s'arrête et il y a fermeture de toutes les fenêtres.
Ma question est la suivante: existe-t-il une commande ou une procédure qui évite l'arrêt total du pg lors de la rencontre d'un petit bug et lorsque ce programme est lancé directement sans passer par l'éditeur de Python?
Je ne sais pas si ma question est claire...
En tout cas merci pour vos éventuelles réponses.
Gabriel

[wiztricks]

Salut,

Ma question est la suivante: existe-t-il une commande ou une procédure qui évite l'arrêt total du pg lors de la rencontre d'un petit bug et lorsque ce programme est lancé directement sans passer par l'éditeur de Python?

Sous IDLE, le programme est lancé dans un process "à part" et s'il y a des échanges, ils sont fait via RPC. Cela construit une étanchéité entre IDLE et le programme: si le process "à part" se plante, IDLE y survivra.
Ceci dit, le petit "bug" aura quand même provoqué la destruction du process (et la perte de l'état du programme qu'il faudra relancer du début).

Ceci dit un bug reste la transition dans un état que le code est incapable de traiter qui se traduit en général par la levée d'une exception tôt ou tard.

Et la notion de "petit bug" pourrait être définir par des transitions dans un état qui permette quand même de continuer les opérations dans un mode +/- dégradé.

Exemple:
Le programme demande à l'utilisateur un nom de fichier à ouvrir en lecture.

Appeler open(nom, 'r') sans avoir vérifier que le fichier "nom" existait va lever l'exception: IOError: [Errno 2] No such file or directory: "nom"
Plutôt que de "vérifier", on peut attraper l'exception:

Code :

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

1
2
3
4
try:
   f = open(nom, 'r')
except IOError:
   # que faire ici pour que le bug soit 'petit'?

Autre approche.
Le code que j'écris n'est jamais sans "bug". J'utilise logging de façon extensive vérifier que certains états sont "as expected" mais il y a toujours des imprévus. On peut ajouter l'affichage d'informations supplémentaires pour savoir ce qu'il se passe et relancer... mais l'exercice est un peu harassant.

J'utilise un module debug.py qui me permet de lancer le debugger en post mortem:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import sys
 
def pm_debug(type, value, tb):
    """traitement normal des exceptions en mode interactif ou sans console
    sinon on affiche l'exception puis on lance le debugger en mode pm
    """
    if hasattr(sys, 'ps1') or not sys.stderr.isatty():
        sys.__excepthook__(type, value, tb)
    else:
        import traceback, pdb
        traceback.print_exception(type, value, tb)
        pdb.post_mortem(tb)
 
sys.excepthook = pm_debug

Ca s'utilise comment? Soit par exemple ce code qui lève une exception de division par 0:

Code :

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

1
2
3
4
def foo(a, b):
    return a / b
 
foo(1, 0)

Lorsqu'on le lance, çà plante et il ne reste qu'a interpréter la trace pour savoir ce qui pèche (ok, ici c'est facile):

Code :

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

1
2
3
4
5
6
7
8
C:\py_works>py -3.2 demo.py
Traceback (most recent call last):
  File "demo.py", line 5, in <module>
    foo(1, 0)
  File "demo.py", line 3, in foo
    return a / b
ZeroDivisionError: division by zero
C:\py_works>

Si on ajoute "import debug", lorsque çà plante, on récupère le debugger!

Code :

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

1
2
3
4
5
6
7
8
9
10
C:\py_works>py -3.2 demo.py
Traceback (most recent call last):
  File "demo.py", line 6, in <module>
    foo(1, 0)
  File "demo.py", line 4, in foo
    return a / b
ZeroDivisionError: division by zero
> c:\py_works\demo.py(4)foo()
-> return a / b
(Pdb)

On pourra alors examiner ce qui s'est passé et corriger (plus vite?)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
(Pdb) list
  1     import helpers.debug
  2
  3     def foo(a, b):
  4  ->     return a / b
  5
  6     foo(1, 0)
[EOF]
(Pdb) print a
1
(Pdb) print b
0
(Pdb)

Je ne suis pas sur que cela réponde à votre question.
J'espère vous avoir donné une idée d'approche...

- W

[Ruyneau]

Bonjour,

Cà ne répondait pas à ma question initiale, mais comme laisser des pgs avec des <<petits>> bugs, ce n'est pas génial, je vais essayer d'utiliser votre debugger pour trouver et corriger plus rapidement les erreurs.
J'utilise rarement la commande <<try>> qui me semble réellement un plus. Je ne vois pas trop comment elle fonctionne (surtout dans la partie except).
Effectivement mes petits bugs sont l'ouverture des fichiers qui n'existent pas ou bien la récupération d'une fenêtre (tkinter) qui n'existe plus.
Peut être que try me suffirait pour résoudre le pb.

Gabriel

[Ruyneau]

rebonjour

J'ai essayé avec import debug.py.

Pas de soucis lorsqu'on lance un programme.py ; l'erreur s'affiche sur la console.

Par contre, avec programme.pyw, aucun message ne s'affiche et je ne sais pas où aller chercher le fichier recensant le bug... qui doit être bien quelque part

Merci de votre aide

Gabriel

[wiztricks]

Salut,

Par contre, avec programme.pyw, aucun message ne s'affiche et je ne sais pas où aller chercher le fichier recensant le bug... qui doit être bien quelque part

C'est normal, çà dit:

Code :

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

1
2
3
4
def pm_debug(type, value, tb):
    """traitement normal des exceptions en mode interactif ou sans console
    sinon on affiche l'exception puis on lance le debugger en mode pm
    """

.PYW est justement "sans console".

Ceci dit, si le programme plante "sans" console, il plantera (probablement) aussi "avec"...
- W

[Ruyneau]

honte à moi... je n'avais pas lu le commentaire du pg...

OK.

Merci

Gabriel