debug et option -O

Version imprimable

03/03/2012, 11h42
plxpy

__debug__ et option -O
Bonjour,

La variable interne __debug__ vaut True par défaut. Y-a-t-il un moyen de la mettre à False, sans passer par l'option -O quand on lance, en ligne de commandes, l'interpréteur ? (au moins sous des systèmes sauce Unix/Linux/MacOSX)

Le but est de simplifier le lancement de script par des non-informaticiens. Aujourd'hui, il est plus "compliqué" de lancer des scripts en mode nominal (__debug__ à False) qu'en mode debug ...

J'ai déjà pensé à :
- mettre, dans le shebang "#!/usr/bin/env python", l'option -O : ça fonctionne sous MacOS, pas sous Linux
- utiliser, à la place de "#!/usr/bin/env python", "#!/usr/bin/python" pour que l'option soit prise en compte : ça fonctionne sous Linux mais pas sous MacOS, l'emplacement standard Python étant un chemin infâme, très spécifique à MacOS et je ne souhaite pas non plus créer des liens symboliques sur la centaine de machines cibles (et les maintenir au gré de changements de machine...)
- passer par un "alias python='python -O'" : pas possible, les opérateurs utilisent des drag-and-drop entre le navigateur de fichiers (Finder) et une fenêtre Terminal et ne lancent jamais, explicitement, l'interpréteur
Dernier recours : utiliser une variable d'environnement (style pythondebug, en majuscules, c'est déjà pris) et écrire

Code:

if os.getenv('pythondebug'):

à la place de

Code:

if __debug__:

bof ...

Avez-vous des idées ?

Je précise aussi que ce "debug" est un debug de données traitées, pas du debuggage de code. Un debugger n'est d'aucune utilité.
03/03/2012, 13h03
fred1599

Salut,

J'ai vu une discussion intéressante où participe Guido.

Il est difficile de te répondre car je ne vois pas l'intérêt de ce __debug__, mais je tente une suggestion.

N'est-il pas possible de faire un code qui te permet de détecter l'OS et d'écrire ton shebang en fonction et de rajouter le code. Il te suffirait de l'exécuter via ton fichier avec un execfile(mon_fichier.py), non?

Citation:

Envoyé par fred1599

N'est-il pas possible de faire un code qui te permet de détecter l'OS et d'écrire ton shebang en fonction et de rajouter le code. Il te suffirait de l'exécuter via ton fichier avec un execfile(mon_fichier.py), non?

Ca ne m'emballe pas du tout. Toucher au shebang c'est modifier dynamiquement le script avant de le lancer ... Possible, oui mais ça ne vaut pas le coup (c'est même un peu bricolage).

S'il n'y a pas de solution directe (et en lisant la doc version 2 ou 3 et la discussion que tu as donnée, même si elle date de 2001, j'ai bien peur que ce soit le cas), je vais garder le classique "#!/usr/bin/env python" et "doubler" chaque script exécutable python (quand __name__ vaut "__main__") par un shell script tout bête du style "python -O script.py $*". C'est une (petite) contrainte pour le développeur mais plus pour l'utilisateur.

De plus, on pourra mettre, dans le shell script, un chemin et pas le nom simple du script python ce qui permettra de :

mettre (organiser !) tous les modules python de tous les outils ailleurs
ne laisser que 1 fichier (le shell script) pour 1 outil dans le répertoire depuis lequel les opérateurs "drag-and-drop"

Visuellement, quand il y a plusieurs dizaines d'outils, ça facilite grandement les choses de réduire le nombre de fichiers et ne garder que l'essentiel.

Citation:

Envoyé par fred1599

je ne vois pas l'intérêt de ce __debug__

C'est à coup sur un héritage du C. Comme en C, les "assert" ne sont effectivement exécutés qu'en mode debug (quand __debug__ vaut True en Python, quand NDEBUG n'est pas positionné à la compilation en C) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 plx@sony:~$ python -c "assert False, 'ca ne passera jamais'" Traceback (most recent call last): File "<string>", line 1, in <module> AssertionError: ca ne passera jamais plx@sony:~$ plx@sony:~$ python -O -c "assert False, 'ca ne passera jamais'" plx@sony:~$ plx@sony:~$ python -c "print __debug__" True plx@sony:~$ python -O -c "print __debug__" False plx@sony:~$
Jouer sur ce mode debug/pas debug permet d'avoir strictement le même code et de pouvoir "désactiver" toutes les instructions assert ou celles après un "if __debug__:" sans jamais toucher le code, de passer de l'un à l'autre selon le contexte et les besoins.

La différence en C, c'est qu'on compile le même code, une fois avec NDEBUG, une fois sans, qu'on obtient 2 exécutables (une version "debug", une autre souvent appelée "release") mais là, pour le coup, l'utilisateur lance de la même façon l'une ou l'autre des versions.

Bonjour plxpy,

J'aurais aussi penser à un script shell mais je trouve cela os dépendant.
A la limite il est possible de faire un 'lanceur' pour cela.

Pourquoi ne pas utiliser le script lui même ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import sys
import os # Subprocess ou ce qui tu veux
 
def main():
    print('Use q to quit, n for NameError, a for AssertionError')
    r = ''
    while r != 'q':
        r = raw_input('Value ? > ')
        if r == 'a':
            assert r != 'a'
        elif r == 'n':
            n/0
 
if __name__ == "__main__":
    if __debug__:
        print 'reload', __file__, 'with -O option'
        cmdline = 'python -O'
        for elem in sys.argv:
            cmdline =  cmdline + ' ' + elem
        os.system(cmdline)
        sys.exit()
    else:
        main()

Et si l'on souhaite récupérer les autres arguments il y a sys.flags.

@+

06/03/2012, 07h05
plxpy
Salut PauseKawa

fûtée l'idée de se relancer soi-même avec les options qui vont bien. Ca ne m'avait pas effleuré ! Mais j'ai l'impression que là, pour le coup, on ne peut plus lancer le script en debug.

Même si le passage par le shell est, comme tu dis, os dépendant, le côté minimaliste de la solution me plait beaucoup.

De plus :
- on n'a extrêmement peu de chance de faire tourner ces outils sous Windows
- si c'était le cas, il faudrait de toute façon revoir la chose car les drag-and-drop entre le navigateur de fichiers et "l'invite de commande" ...
- on met déjà les fichiers des outils ailleurs pour les raisons que j'ai indiquées et on crée 1 seul fichier par outil (aujourd'hui c'est un simple lien symbolique)
Mais je garde ton idée en tête pour d'autres occasions/situations.
06/03/2012, 07h12
PauseKawa

Citation:

Envoyé par plxpy

fûtée l'idée de se relancer soi-même avec les options qui vont bien. Ca ne m'avait pas effleuré ! Mais j'ai l'impression que là, pour le coup, on ne peut plus lancer le script en debug.

Que neni: if '-o' in sys.argv
06/03/2012, 07h25
plxpy
double que nenni !
- soit on ne met pas l'option -O dans la commande, sous le shell, et on relance, dans le script python, avec -O (partie if, reconstruction de la commande)
- soit, dans la ligne de commande, on met l'option O et ça s'exécute directement (partie else)
C'est, au final, lancer sans l'option O qui permet d'être en mode debug (pour les développeurs ou même les utilisateurs si le script s'est crashé ou a trouvé des bizarreries)

Ou alors j'ai pas compris.

Plus explicite:

Code:

1
2
3
4
5
6
7
8
if __name__ == "__main__":
    if __debug__ and '-dev' not in sys.argv:
        cmdline = 'python -O'
        for elem in sys.argv:
            cmdline =  cmdline + ' ' + elem
        os.system(cmdline)
        sys.exit()
    main()

06/03/2012, 12h26
plxpy

Oui, du coup l'option -dev (du script) a le dernier mot et si elle n'est pas présente, c'est en mode optimisé qu'on travaille systématiquement.

J'étais parti sur un truc dans le genre, en détaillant encore un peu plus les cas de figure : et bien, on peut facilement tomber dans une boucle infinie, en relançant une commande qui n'a toujours pas la bonne forme !

Sinon, j'ai l'impression (fausse ?) que l'utilisation des modes debug/pas debug n'est pas très courante dans le monde Python. C'est (ça peut) pourtant être bien complémentaire des exceptions.

Salut,

J'aime bien Python car, il est souvent plus rapide de grattouiller un bout de code que de trouver l'information dans la documentation.

La variable d'environnement PYTHONOPTIMIZE permet de contrôler l'équivalent de l'ajout du -O ou du -OO au lancement de l'interpréteur.
Code:

1 2 3 4 5 6 7 8 9 10 C:\py_works>set PYTHONOPTIMIZE= C:\py_works>python -c "assert False, 'is false'" Traceback (most recent call last): File "<string>", line 1, in <module> AssertionError: is false C:\py_works>set PYTHONOPTIMIZE="X" C:\py_works>python -c "assert False, 'is false'" C:\py_works>
Cela devrait fonctionner sur toutes les plate-forme.

Cordialement,
- W

Bonsoir wiztricks,

Citation:

Envoyé par wiztricks

Cela devrait fonctionner sur toutes les plate-forme.

Pas vraiment...
Code:

1 2 3 4 5 6 7 8 9 10 11 patrice@Zeus:~$ python -c "assert False, 'is false'" Traceback (most recent call last): File "<string>", line 1, in <module> AssertionError: is false patrice@Zeus:~$ set PYTHONOPTIMIZE="X" patrice@Zeus:~$ python -c "assert False, 'is false'" Traceback (most recent call last): File "<string>", line 1, in <module> AssertionError: is false patrice@Zeus:~$ cat /etc/issue Ubuntu 11.10 \n \l
Je continu a penser que le contrôle interne du code est plus sur.

@+

En fait, il faut passer par une variable d'environnement, donc sous bash, export (pas set)

Sinon, la doc officielle en 2.6.6 ne fait nulle part référence à PYTHONOPTIMIZE. La 2.7.2, si. Par contre, ça fonctionne en 2.6
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 plx@sony:~$ python -c "assert False, 'Damned'" Traceback (most recent call last): File "<string>", line 1, in <module> AssertionError: Damned plx@sony:~$ plx@sony:~$ export PYTHONOPTIMIZE=quelque_chose plx@sony:~$ plx@sony:~$ python -c "assert False, 'Damned'" plx@sony:~$ plx@sony:~$ cat /etc/issue Ubuntu 11.04 \n \l plx@sony:~$ python2.6 -c "assert False, 'Damned'" plx@sony:~$ export PYTHONOPTIMIZE= plx@sony:~$ python2.6 -c "assert False, 'Damned'" Traceback (most recent call last): File "<string>", line 1, in <module> AssertionError: Damned plx@sony:~$
Reste à voir si sous MacOS ça fonctionne également.

En python 2.6(.6), MacOSX version Snow Leopard : oui, ça fonctionne

06/03/2012, 21h44
wiztricks

Salut,

Citation:

Envoyé par plxpy

Sinon, la doc officielle en 2.6.6 ne fait nulle part référence à PYTHONOPTIMIZE. La 2.7.2, si. Par contre, ça fonctionne en 2.6

C'est dans la doc 2.6
Je ne sais pas quand a été implémentée cette fonctionnalité mais Google en a des traces en 2001.

Citation:

Je continu a penser que le contrôle interne du code est plus sur.

Il est dommage de ne pas connaître les différentes options a notre disposition avant de choisir ce qu'on pense être le plus approprié à l'instant t.

Le contrôle interne que vous proposez est sympa car l'optimisation est "le défaut" pour un script particulier et on ajoute des "flags" si on ne veut pas optimiser.
Ce n'est pas plus "sûr" - l'utilisateur tape toujours ce qu'il veut - mais plus spécifique, ciblé qu'une variable d'environnement qui sera "globale" a tous les scripts.

- W
06/03/2012, 22h06
plxpy

Salut Wiztricks

Citation:

Envoyé par plx

Sinon, la doc officielle en 2.6.6 ne fait nulle part référence à PYTHONOPTIMIZE

Effectivement, j'ai parlé trop vite mais j'avais fait confiance à l'outil de recherche (Quick search) du bandeau à gauche : en 2.6 il ne ramène strictement rien. En 2.7, il y a 1 seul résultat qui pointe sur une page équivalente à celle que tu as mise dans ton post.

Sinon, sur le fond et dans l'absolu, l'utilisation de cette variable d'environnement me va bien. Mais je dois aussi penser au fait que, dans la pratique, les utilisateurs (non informaticiens, je le redis) devront pouvoir lancer le script en mode debug et l'expérience montre que les faire "jongler" avec des variables d'environnement est très hasardeux.

Mais là, pour le coup, entre la solution de PauseKawa et la tienne, j'ai toutes les billes pour faire au mieux. Merci à tous les deux.

__debug__ et option -O

debug et option -O