J'essaye de parcourir un script python pour du code que j'ai écrit il y a plus d'un an. La façon dont je me souviens, quand vous écrivez une ligne pdb.set_trace(), le programme va arrêter son exécution à ce point et imprimer la ligne suivante qui sera exécutée. Entrer 'n' ou 's' avancera l'exécution par une ligne (et peut-être entrer dans une fonction, pas trop pertinente à mon problème) ET imprime la ligne suivante à exécuter à nouveau.Incompatibilité Python PDB avec les sorties de commandes - instruction suivante non sortie
Maintenant, j'ai un programme "example1.py" et il n'imprime pas l'instruction suivante à exécuter. Je viens d'obtenir quelque chose comme ce qui suit
./example1.py
> /home/some/example1.py(44)create()
(Pdb) s
> /home/some/example1.py(45)create()
(Pdb) s
--Call--
> /home/some/example1.py(90)parse()
Mais quand j'essaie la même chose avec un programme python différent, « example2.py », qui je l'ai écrit plus récemment, je reçois la sortie que j'attends (la prochaine instruction à exécuter.)
> /home/some/example2.py(86)random_update()
-> DATE_LIMIT=1
(Pdb) n
> /home/some/example2.py(87)random_update()
-> FILE_LIMIT=120
(Pdb) n
> /home/some/example2.py(89)random_update()
-> n_dates=0
Je n'ai aucune idée de ce qui pourrait être une cause possible pour cela. Les instructions d'importation peuvent-elles interférer avec l'exécution de pdb? Donc, je définis mon point d'arrêt de trace avant de passer à un répertoire qui est en dehors de mon répertoire personnel. Quand je fais cela, j'obtiens la sortie à laquelle je m'attends. J'ai remarqué que le propriétaire du groupe de ce répertoire était root donc je l'ai changé pour mon utilisateur. Cela n'a pas résolu mon problème, mais maintenant je sais que cela a à voir avec l'emplacement d'exécution du programme.