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