[DELESTAGE] fichier.glade bidouillage!

Chaussette · Le 01/02/2007, à 16:19

J'ai l'impression que le tension est monté d'un cran ici.

..brrrrrrrrrrrrrrrr...

bipede · Le 01/02/2007, à 16:37

Chaussette a écrit :

J'ai l'impression que le tension est monté d'un cran ici.

..brrrrrrrrrrrrrrrr...

Rien de grave...

aleph · Le 01/02/2007, à 17:52

> bipede

Je ne peux que te conseiller de replonger dans un bouquin, wiki ou doc concernant le fonctionnement de Python et corriger certaines de tes certitudes. Il serait vain d'essayer de commenter au cas par cas le code. Les problèmes inhérents ne viennent pas directement de la syntaxe, mais sont plutôt structurels (sys.path, os.path, séparation des py et pyc). D'où la difficulté.
Par exemple, un coup d'oeil à psi, http://spinecho.ifrance.com/ , et surtout à son module de départ, psi.py, devrait être instructif.

---

>eclipse
> Le code source est disponible de son application.... Je te propose avec les talents qui sont les tiens, de voir où ca clochouille et de me créer un installer (un fichier setup.py) pas un fichier deb comme tu as dû confusionner...

J'ai le code source. J'étais curieux de savoir pouquoi notre ami(e) bipede à abandonner wxPython.
Cela dit, ce n'est ni un setup.py ou un paquet debian qui résoudront ton problème. Cela n'a rien à voir avec l'application et ne serait en tout cas d'aucune utilité. Ce n'est pas là que l'application pèche (voir plus haut).
Je ne peux aller à l'encontre de la volonté de son auteur et modifier les fichiers pour qu'ils soient conformes aux usages ne m'amuse pas plus que tant.

Vraiment désolé d'avoir déclanché cette petite tempête. Telle ne fut pas mon intention.

bipede · Le 01/02/2007, à 19:03

> aleph

sys.path[0] et sys.argv[0] donnent le même résultat, et dans mon programme produisent les mêmes effets...

La séparation des sources et du bytecode n'a aucune incidence sur ce qui se passe chez eclipse.

Alors tu connais certainement très bien python, tu serais même un puriste que ça ne m'étonnerait pas, mais quelqu'un qui oriente un utilisateur qui ne parvient pas à faire fonctionner une appli sur une fausse piste uniquement pour étaler sa science, je ne dirai pas de quoi je le qualifie par égard pour ce forum.

Retourne donc à ton wxpython, ça fonctionne très bien chez Bill, et j'ai cru comprendre que tu étais beaucoup moins fortiche pour installer une distribution linux...

Chaussette · Le 01/02/2007, à 19:59

C'est trop dur de rester courtois ?

aleph · Le 01/02/2007, à 20:49

> bipede

Arrêtons la discussion ici. Tes propos deviennent confus et fusent de tous côtés.

> ... j'ai cru comprendre que tu étais beaucoup moins fortiche pour installer une distribution linux...

Tu a compris correctement. Hélas, à mon grand dam, 10 mois d'effort n'ont pas suffit à résoudre mes problèmes de wifi. J'avoue ouvertement mon incompétence dans ce dommaine. Aussi, ai-je décidé de laisser Linux de côté. La bonne nouvelle est que même en travaillant sous Windows, mes contributions se retrouveront sous Ubuntu.

eclipse · Le 01/02/2007, à 21:57

Tu as du plomb dans tes sockette que tu as délester le post ?

trucutu · Le 01/02/2007, à 22:10

bipede a écrit :

4- Il n'y a que sous windows que les tabulations peuvent être gênantes, et encore, uniquement quand on ajoute du code provenant d'un éditeur qui les calcule différemment. Encore une fois je travaille sous linux et pour linux ...

Pas sûr. Je n'ai pas fais des tests poussés, mais dans ce domaine, je pense que le troll emacs/vi (tout sous linux) n'est pas qu'une simple querelle de fous de leurs éditeurs, surtout quand on utilise à tort et à travers l'indentation automatique sans savoir la régler dans l'un ou l'autre des éditeurs (c'est mon cas en tous cas, et je lutte dès que je développe en Python à cause de ça...). Donc bon, en termes de portabilité d'édition, je pense aussi qu'il vaut mieux éviter la tabulation... enfin, c'est pas grave, hein ?

bipede · Le 02/02/2007, à 09:42

Bon, avec le recul d'une bonne nuit de sommeil, je regrette de m'être énervé hier soir.

Toutefois, plutôt que m'expliquer que je suis un gland, que je dois réapprendre python, et plutôt que de me lancer un no-nos sous forme de jeu de piste, j'aurai préféré pour pouvoir dépanner eclipse rapidement, et que le docteur es python me dise exactement ce qui foirait et pourquoi, puisqu'il semblait le savoir.

Comme je ne suis pas obtus, je vais :

- Utiliser les méthodes de définition des chemins utilisées dans psy.
- convertir toutes les tabulations en espaces dans le code source (en fait, c'est le paramétrage de scite qui provoquait cela).
- Fournir une version 3.0.1 qui tienne compte de ces modifications, et sans livrer aucun bytecode.

J'espère que ça solutionnera le problème.

Par contre j'aimerais comprendre pourquoi une méthode de définition de chemins qui fonctionne sur ubuntu ne fonctionnerait pas sous debian...

aleph · Le 02/02/2007, à 19:59

Tu n'est pas un gland, tu n'a pas compris l'essence et le fonctionnement
de Python. La syntaxe et l'écriture du code est une chose, la compréhension
de "ce qui se passe" quand on exécute un script Python en est une autre.
Et ceci a une influence sur l'écriture et la conception du code. Beaucoup
achoppent sur ce point. Dépanner eclipse n'aurait été qu'un emplâtre sur une
jambe de bois, car c'est ton code qui pèche.

script et bytecode

Pour bien réaliser "ce qui se passe", essaie ceci dans l'ordre.
On laisse de côté les shebangs et les encodages et on travaillera
dans un dossier/répertoire vide pous faciliter la compréhension.

1) Première étape, script unique

#module a1.py
def main():
print 'Salut les amiches, je suis a1.py'
if __name__ == '__main__':
main()

Exécution du script a1.py, Python fait afficher

Salut les aminches, je suis a1.py

Aucun fichier a1.pyc n'est créé.
Ton répertoire ne contient que a1.py.

2) Deuxième étape. Deux scripts.

#module a2.py
import b1
def main():
print 'Salut les amiches, je suis a2.py'
b1.proc()
if __name__ == '__main__':
main()

#module b1.py
def proc():
print 'Salut les amiches, je suis proc de b1.py'

Exécution du script a2.py, Python fait afficher

Salut les aminches, je suis a1.py
Salut les amiches, je suis proc de b1.py

Que ce passe-t-il ?
Python exécute a2.py, il tombe sur la ligne import b1.
Il se pose la question suivante, existe-t-il une version bytecode
de b1 ? Non.
Existe-il un script b1.py? Oui. A ce moment, Python se dit
la chose suivante, "il serait bien de "compiler" (le terme
n'est pas tout à fait correct) b1.py en b1.pyc car j'aurais
peut-être besoin de lui plus tard et il existera déjà, par
exemple, lors d'une nouvelle exécution de a2. A noter, que le
fichier b1.pyc est créé dans le même répertoire que le fichier
b1.py .

Ton répertoire contient maintenant a1.py, a2.py, b1.py et b1.pyc.

3) Etape 3. Modification de b1.py
#module b1.py
def proc():
print 'Salut les filles, je suis proc de b1.py modifié'

Exécution du script a2.py, Python fait afficher

Salut les aminches, je suis a1.py
Salut les filles, je suis proc de b1.py modifié

Que se passe-t-il?
Python exécute a2.py, il tombe sur la ligne import b1.
Il se pose la question suivante, existe-t-il une version
bytecode de b1 ? Oui.
Existe-t-il une version script b1.py? Oui.
Problème pour Python, lequel dois-je utiliser ?
A ce moment, Python utilise un méchanisme qui va lui permettre
de comparer b1.py et b1.pyc. Ce méchanisme lui dit, "b1.pyc existe,
mais il ne correspond plus à l'ancien b1.py". Donc, je vais le
recompiler, il sera à nouveau disponible pour une utilisation ultérieure.

Ton répertoire contient maintenant a1.py, a2.py, b1.py et b1.pyc, où
b1.py et b1.pyc ne sont plus les mêmes.

Question. Pourquoi Python ne crée-t-il pas du bytecode pour a1.py
et pour a2.py dans les exemples précédents ?

Réponse. Parce que Python a aussi la faculté de travailler dans
un mode interactif, c'est le cas dans une console (IDLE, psi, PyShell
ou une terminal). Quand on travaille en mode interactif, il serait inutile
de faire deux fois le travail, c'est à dire parcourir le code source, le
convertir en bytecode et l'exécuter à partir ce celui-ci.
Si tu entres une commande dans une console, la commande est envoyée
à l'interpréteur sous forme de pseudo-fichier. C'est comme si, la
commande que tu as entrée provenait d'un fichier qui serait un script.

Exemple:
>>> print 'Salut, les aminches'

La console, plutôt son programme, prend le texte print 'Salut, les aminches'
comme du code source et l'envoie à un interpréteur Python, comme si cela était
un script dans un fichier. Il est à noter que l'interpréteur de la commande
n'est pas le même que l'interpréteur qui fait fonctionner la console.

La console, via son interpréteur, affichera

Salut les aminches

Répétons l'execice avec une erreur dans le "script". Ici, une absence
d'apostrophe à la fin du string.

>>> print 'Salut, les amiches

La console renvoie
File "<psi last command>", line 1
print 'Salut les aminches
^
SyntaxError: EOL while scanning single-quoted string

Ceci est très instructif et démontre le travail de la console.
La console prend la source print 'Salut les aminches comme si cela
était un script dans un fichier nommé <psi last-command> et signale
une erreur dans la première ligne.

Dans cet exemple, une erreur sera détectée dans le deuxième ligne.
>>>for c in '123':
print 'Salut, les amiches

File "<psi last command>", line 2
print 'Salut, les amiches
^
SyntaxError: EOL while scanning single-quoted string

Très souvent, le nom du pseudo fichier est <input> et non
<psi last command>. Cela dépend du concepteur de l'application.
<psi last command> est le nom choisi dans *mon* interface/shell, psi.

A partir de cette explication, on peut déjà déduire quelques
points.
1) Les bytecodes sont générés à la volée. Python "sait" les
générer quand cela est nécessaire.
2) Les bytecode sont dans le même répertoire que les scripts (aisément
vérifiable pour toutes applications Python, y compris les librairies
du moteur Python).
3) Pour distribuer une application, il suffit donc de distribuer les
scripts. Le pc récepteur (quelque soit la plateforme, Linux, OS X
ou Windows) les créera.

Pigé ?
Ceci ne résoud toujours pas tous tes problèmes, mais cela fait
déjà avancer le schmilblik.

(un peu brouillon, je n'ai pas testé les scripts présentés ici).

sys.path et sys.argv

Par paresse, voici ce que dit la documentation

sys.path
A list of strings that specifies the search path for modules. Initialized from the environment variable PYTHONPATH, plus an installation-dependent default.
As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter. If the script directory is not available (e.g. if the interpreter is invoked interactively or if the script is read from standard input), path[0] is the empty string, which directs Python to search modules in the current directory first. Notice that the script directory is inserted before the entries inserted as a result of PYTHONPATH.

A program is free to modify this list for its own purposes.

Changed in version 2.3: Unicode strings are no longer ignored.

sys.argv
The list of command line arguments passed to a Python script. argv[0] is the script name (it is operating system dependent whether this is a full pathname or not). If the command was executed using the -c command line option to the interpreter, argv[0] is set to the string '-c'. If no script name was passed to the Python interpreter, argv has zero length.

Je n'aime pas renvoyer bêtement les gens aux manuels, mais parfois les
concepts nécessitent une meilleure compréhension/étude. C'est ce que font
les manuels et ce que ne fait pas la documentation.

Voici ce qu'il faut comprendre et que la doc ne dit pas.
- sys.path[0] n'est pas nécessairement identique à sys.argv[0].
- Les sys.path peuvent être différents sur chaque pc. Quand je dis,
pc, je ne pense pas à une platforme Windows, Ubuntu, Debian ou Solaris
mais au pc de l'utilisateur. Deux platformes Ubuntu peuvent avoir des
sys.path différents.
- C'est au concepteur de l'application que revient la tâche de gérer
correctement tout ceci. *Ce n'est pas un déficience de Python*.

Voici mon sys.path sur ma platforme w2k, à partir de psi.py :

for e in sys.path:
print e

C:\jm\jmpy\psi\psi77
C:\WINDOWS\system32\python25.zip
C:\Python25\DLLs
C:\Python25\lib
C:\Python25\lib\plat-win
C:\Python25\lib\lib-tk
C:\Python25
C:\jm\jmpy\jmlib
C:\jm\jmpy\psi\psigraph7
C:\Python25\lib\site-packages
C:\Python25\lib\site-packages\wx-2.8-msw-ansi

Sur un autre pc, même w2k, le sys.path peut être différent.
Même sur cette machine avec une autre application le sys.path pourrait
être différent.

Il y a encore bien des subtilités, mais le gros est expliqué.

sys.path, une parmi les idées de génie du concepteur de Python
Guido van Rossum.

bipede · Le 02/02/2007, à 23:30

à aleph

Merci d'avoir pris le temps...

Le principe de la pseudo-compilation à la volée, j'avais bien compris, et effectivement je n'avais pas réfléchi plus loin que mon environnement quand j'ai packagé.

Par contre sys.path je ne l'utilisais pas bien parce que je n'avais pas tout compris. Et c'est bien mon utilisation hasardeuse qui provoquait les problèmes...

aleph · Le 03/02/2007, à 11:05

> bipede

Il faut bien comprendre que l'utilisateur final ne n'intéresse qu'aux fichiers .py et non aux .pyc. Tout utilisateur Python un peu expérimenté recherchera de toute façon les fichiers .py. Demander à un utilisateur final de déplacer des scripts d'un dossier à l'autre n'a aucun sens. (v. section Bureautique).

Ceci nous amène à la distribution de ton application...

Pour distribuer ton application, il suffit *uniquement* de distribuer les scripts Python (.py) qui concernent ton application. Si ton application fait appel à des bibliothèques extérieures comme PIL dans ton cas, tu dois informer l'utilisateur que ces bibliothèques doivent être installées sur son pc afin que ton application fonctionne sans problème. Il est inutile de concevoir un package (rpm, deb,...) qui contient les bibliothèques tierces (v. autre message). Ce n'est pas à toi de faire ce travail. Il est aussi bon d'indiquer les versions de ces bibliothèques que ton application est censée utiliser.
Dans le monde Python, il est plutôt d'usage de distribuer ses scripts dans un fichier zip et non un tar.

sys.path, j'ai installé PIL sur mon pc.

Avant l'installation, sys.path

C:\Python25\Lib\idlelib
C:\WINDOWS\system32\python25.zip
C:\Python25\DLLs
C:\Python25\lib
C:\Python25\lib\plat-win
C:\Python25\lib\lib-tk
C:\Python25
C:\jm\jmpy\jmlib
C:\jm\jmpy\psi\psigraph7
C:\Python25\lib\site-packages
C:\Python25\lib\site-packages\wx-2.8-msw-ansi
>>>

Après installation

C:\Python25\Lib\idlelib
C:\WINDOWS\system32\python25.zip
C:\Python25\DLLs
C:\Python25\lib
C:\Python25\lib\plat-win
C:\Python25\lib\lib-tk
C:\Python25
C:\jm\jmpy\jmlib
C:\jm\jmpy\psi\psigraph7
C:\Python25\lib\site-packages
C:\Python25\lib\site-packages\PIL
C:\Python25\lib\site-packages\wx-2.8-msw-ansi
>>>

Ton oeil exercé notera que
- je n'ai absolument rien fait pour que PIL soit dans le sys.path, les concepteurs ont fait le travail correctement.
- l'entrée de PIL n'est ni en position 0, ni à la fin !

Deux remarques.

- J'utilise aussi SciTE et n'ai aucun problème d'indentation. J'utilise la convention maintenant établie qui est une indentation = 4 blancs. J'échange des scripts Python avec des utilisateurs de toutes platformes sans aucun problème depuis des années et même depuis bien avant la naissance d'Ubuntu.
- Au cas où tu ne le saurais pas, Python 2.5 inclut "nativement" sqlite. Petites modifications en perspective...

PS Je "roule" pour Python, les gueguerres Linux, Windows, OS X ne m'intéressent pas.

Bon vent.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 01/02/2007, à 16:19

Re : [DELESTAGE] fichier.glade bidouillage!

#27 Le 01/02/2007, à 16:37

Re : [DELESTAGE] fichier.glade bidouillage!

#28 Le 01/02/2007, à 17:52

Re : [DELESTAGE] fichier.glade bidouillage!

#29 Le 01/02/2007, à 19:03

Re : [DELESTAGE] fichier.glade bidouillage!

#30 Le 01/02/2007, à 19:59

Re : [DELESTAGE] fichier.glade bidouillage!

#31 Le 01/02/2007, à 20:49

Re : [DELESTAGE] fichier.glade bidouillage!

#32 Le 01/02/2007, à 21:57

Re : [DELESTAGE] fichier.glade bidouillage!

#33 Le 01/02/2007, à 22:10

Re : [DELESTAGE] fichier.glade bidouillage!

#34 Le 02/02/2007, à 09:42

Re : [DELESTAGE] fichier.glade bidouillage!

#35 Le 02/02/2007, à 19:59

Re : [DELESTAGE] fichier.glade bidouillage!

#36 Le 02/02/2007, à 23:30

Re : [DELESTAGE] fichier.glade bidouillage!

#37 Le 03/02/2007, à 11:05

Re : [DELESTAGE] fichier.glade bidouillage!

Pied de page des forums