Discussion :

[plxpy]

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 :

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

if os.getenv('pythondebug'):

à la place de

Code :

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

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é.

[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?

[plxpy]

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.

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 :

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

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.

[PauseKawa]

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 :

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

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.

@+

[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.

[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.

Que neni: if '-o' in sys.argv

[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.

[PauseKawa]

Plus explicite:

Code :

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

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()

@+

[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.

[wiztricks]

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 :

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

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

[PauseKawa]

Bonsoir wiztricks,

Cela devrait fonctionner sur toutes les plate-forme.

Pas vraiment...

Code :

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

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.

@+

[plxpy]

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 :

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

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

[wiztricks]

Salut,

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.

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

[plxpy]

Salut Wiztricks

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.