if truc:
    import pdb; pdb.set_trace()

Mais il est aussi possible de le faire pendant qu’on est en train d’utiliser le debugger grace à la commande “b” :

b 50, age == 18

Ceci va mettre un breakpoint à la ligne 50 qui s’activera uniquement si age vaut 18.

Des fois que ça serve…

Mélangeons les deux !

import sys
import traceback
import pdb

def pdb_post_mortem(exc_type, exc_val, exc_tb):
    # On affiche l'exception histoire de savoir ce qu'on debug
    print("".join(traceback.format_exception(exc_type, exc_val, exc_tb)))
    # On balance pdb en mode post mortem, c'est à dire qu'il va se lancer
    # malgré le fait que le programme ne marche plus, donnant accès
    # au contexte qu'il y avait juste avant que ça foire
    pdb.post_mortem(exc_tb)

# On dit à python de lancer cette fonction quand il plante
sys.excepthook = pdb_post_mortem

# On fait planter Python histoire de voir que ça marche bien

def boom():
    a = 1
    b = a / 0
boom()

Et si quand ça plante, Python nous pond la stack trace, puis nous lance un joli prompt de debugging qui donne accès à ce qu’on avait en mémoire just avant que la VM ne décède :

Traceback (most recent call last):
  File "test.py", line 16, in 
    boom()
  File "test.py", line 14, in boom
    b = a / 0
ZeroDivisionError: integer division or modulo by zero

> /home/sam/Bureau/test.py(14)test()
-> a = 1 / 0
(Pdb) 1
(Pdb) print a
1

C’est plus ou moins l’équivalent de lancer son programme manuellement avec :

python -m pdb programme.py

L’avantage de la première forme, c’est qu’on peut le setter et l’oublier, on faire une config un peu plus custom. L’avantage de la deuxième forme, c’est que c’est juste une ligne à taper, et en prime si on fait c, le programme redémarre automatiquement.

Mais parfois vous n’avez pas accès à une console sur votre process : il est derrière un nginx, ou même sur une machine distante.

rpdb vient résoudre ce problème en lançant un serveur telnet qui donne accès à votre debugger.

pip install rpdb

Puis :

import rpdb; rpdb.set_trace()

Et après vous prenez votre client telnet favoris, et vous accédez à votre débugger :

telnet 127.0.0.1 4444

Bien entendu, si vous êtes à distance, remplacez 127.0.0.1 par l’ip de la machine. Le port est configurable également :

import rpdb
debugger = rpdb.Rpdb(port=12345)
debugger.set_trace()

Et derrière, ça lance pdb, donc pdbpp est lancé automatiquement si il est installé. Joie.

Oui mais quand votre programme plante, il faut lancer l’éditeur, trouver la ligne, faire un try/except, et en plus ramer si c’est dans une boucle.

On peut faire mieux. Si vous avez ipdb et ipython installés (et si ce n’est pas le cas, un pip install les deux car on ne peut pas vivre sans), au lieu de lancer votre script ainsi:

python script.py

Lancez le ainsi:

ipython --pdb script.py

Et à la première exception, votre shell va directement s’ouvrir en mode debugger à la bonne ligne.

C’est pas merveilleux, ça ?

Pour la plupart des langages, on utilise un debugger intégré dans un IDE ou un programme à part. Ou alors on se contente de fonctions telles que var_dump ou print_r. En Python, on utilise le module pdb.

Quand vous voulez savoir ce qui se passe à un endroit du programme, à la ligne précise où vous souhaitez explorer le problème, ajoutez à votre code :

import pdb; pdb.set_trace()

Et relancez votre programme depuis une console.

L’exécution du programme va alors se figer, et dans la console vous aurez accès à un shell special:

(Pdb)

A quoi sert pdb

Dans ce shell vous pouvez entrer deux choses:

• N’importe quelle expression Python qui tient sur une ligne.
• Des commandes pdb speciales.

Ce qui est génial, c’est que toute expression Python sera éxécutée dans le context de la ligne où le programme s’est arrêté.

Donc vous pouvez faire des print, des if, des listes en intention, bref, tous les tests que vous voulez, avec les variables du programme dans l’état où elles sont à ce moment là.

Vous avez accès à tout le code, y compris vos propres objets, classes et fonctions. En fait, vous avez même accès à l’import, et donc à toutes les librairies importables.

L’essentiel des commandes

En plus de pouvoir exécuter du Python, vous pouvez utiliser des commandes. Il y en a des nombreuses, mais vous pouvez tirer l’essentiel de pdb avec six d’entre elles:

•  l: Liste quelques lignes de code avant et après là où vous vous trouver. Utile pour se resituer dans le contexte du programme. ‘l’ pour ‘list’.
•  n: Exécute la ligne suivante. Vous pouvez ainsi continuer l’exécution du programme de bout en bout, ligne par ligne, et le tester en entier. ‘n’ pour ‘next’.
•  s: Si votre ligne contient un appel de fonction ou de méthode, rentre dans à l’intérieur. ‘s’ pour ‘step in’.
•  r: Si vous êtes dans une fonction ou une méthode, celà permet d’en sortir et de passer dans le scope du dessus. ‘r’ pour ‘return’.
• unt: Si vous êtes à la dernière ligne d’une boucle, permet de reprendre l’exécution jusqu’à la sortie de la boucle. ‘unt’ pour ‘until’.
• q: Quitte brutalement le programme en le faisant crasher. ‘q’ pour ‘quit’.
• c: Quitte le debugger et continue l’exécution du programme normalement. Tous les changements que vous avez fait dans le code sont pris en compte. ‘c’ pour ‘continue’.

Pour utiliser une commande, il suffit de taper la lettre et d’appuyer sur entrée. Si vous appuyez sur entrée sans rien saisir, la commande précédente est exécutée, ce qui vous évitera de spammer le shell de commandes n.

Les limites de pdb

• Les commandes ont priorité sur le code Python. Vous ne pouvez donc pas assigner des variables dont le nom est en une seul lettre. C’est ennuyeux pour accéder à la variable ‘i‘ dans une boucle for. Dans ce cas, prefixez ‘i‘ par un ‘!‘ et il sera considéré comme du Python, et non comme une commande.
• Si vous mettez set_trace dans une boucle, le debugger va se lancer à chaque tour de boucle, ce qui embrouille tout. Dans ce cas, et dans tous les cas où vous voulez que le debugger se lance à un moment particulier, utilisez un if ou un try/except pour que set_trace ne soit appelé que dans un cas précis.
• Dans le cas de threads, de processus séparés, ou quand vous n’avez pas accès à stdout, pdb ne peut rien pour vous. Dans ce cas, le module logging est votre ami.

pdb + ipython = ipdb

Si vous êtes fan d’ipython, un coup de pip:

pip install ipdb

Et ensuite dans le programme:

import ipdb; ipdb.set_trace()

Vous aurez alors accès au shell de pdb, mais avec en prime les commandes et l’autocompletion d’ipython

Mettre un break point programmatiquement en javascript

Dans une moindre mesure, on peut aussi lancer un shell de debug depuis javascript. Ouvrez votre fenêtre d’outils Web intégrés au navigateur, Firebug ou équivalent.

Normalement il faut trouver votre script, puis la ligne, et mettre un break point.

Mais dans les navigateurs récents, vous pouvez juste ajouter:

debugger;

A la ligne voulue, et recharger la page. Votre outil de debuggage se mettra au break point automatiquement