Discussion :

[sjlouis]

Bonjour,

Je sèche depuis un bon moment sur l'utilisation et la gestion des modules personnels, surtout s'ils ne sont pas dans le dossier en cours.
EDIT : j'ai lu pas mal de documentations sur le sujet, dont des textes en Anglais (je le précise car je le lis assez difficilement) mais je n'ai rien trouvé de bien clair qui puisse m'aider. Le sujet me semble assez complexe.

J'ai une arborescence de ce type :

Code :

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

1
2
3
4
5
6
7
8
 
\DIP\
     Bibli\
           bibl1.py
           bibl2.py
     Progs\
           prog1.py
           prog2.py

Je souhaite récupérer une fonction de bibl1.py depuis prog1.py et prog2.py. Alors je peux ajouter le path de Bibli à sys.path mais comme chaque programme l'ajouterait, sans compter qu'ils peuvent être lancés à plusieurs reprises, il faudrait que je teste sa présence pour ne pas qu'il soit ajouté plusieurs fois. Ce n'est pas compliqué mais un peu lourd.

Si les modules de Bibli sont dans le dossier Progs, pas de soucis, même chose si Bibli est dans Progs mais je n'y arrive pas quand Bibli et Progs sont au même niveau comme montré dans l'exemple. J'ai bien essayé avec les .. pour arriver au répertoire parent mais j'ai le message d'erreur suivant : ValueError: attempted relative import beyond top-level package.


Autre point avec les modules : si dans le module modul1.py j'initialise des variables, x et y par exemple :

Code :

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

1
2
3
 
x = "toto"
y = "fifi"

Je peux récupérer leur valeur avec l'instruction :

Code :

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

1
2
 
from modul1 import x,y

Mais s'ils sont dans une fonction du module, je n'ai pas trouvé comment faire :

Code :

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

1
2
3
4
 
def fonct() :
    x = "toto"
    y = "fifi"

Merci pour votre aide .

[wiztricks]

Salut,

Je souhaite récupérer une fonction de bibl1.py depuis prog1.py et prog2.py. Alors je peux ajouter le path de Bibli à sys.path mais comme chaque programme l'ajouterait, sans compter qu'ils peuvent être lancés à plusieurs reprises, il faudrait que je teste sa présence pour ne pas qu'il soit ajouté plusieurs fois. Ce n'est pas compliqué mais un peu lourd

sys.path est une variable du programme qui disparaît à la sortie du programme: lancez plusieurs fois vous n'aurez pas d'ajout successifs.

Sinon la solution serait de faire de vrai packages installés via pip éventuellement --user.

Autre point avec les modules : si dans le module modul1.py j'initialise des variables, x et y par exemple :

Code :

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

1
2
3
 
x = "toto"
y = "fifi"

Je peux récupérer leur valeur avec l'instruction :

Code :

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

1
2
 
from modul1 import x,y

Mais s'ils sont dans une fonction du module, je n'ai pas trouvé comment faire :

Code :

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

1
2
3
4
 
def fonct() :
    x = "toto"
    y = "fifi"

Dans une fonction, les "variables" n'existent que lorsque la fonction a été appelée et sont détruites à sa sortie (sauf si la fonction les retourne à l'appelant).

- W

[sjlouis]

J'avais remarqué que le sys.path s'effaçait quand on fermait le shell après y avoir fait des tests mais je ne savais pas que c'était la même chose quand un programme se fermait. Intéressant. Et je viens de vérifier .

Mais ça ne m'arrange pas car pour effectuer un traitement, j'utilise une vingtaine de programmes et après les avoir "fiabilisés", je peux les lancer les uns derrières les autres ou en choisir certains dans un programme "lanceur" :

Exemple de Lanceur.py

Code :

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

1
2
3
4
5
 
exec (open ("aaa.py", encoding = "utf8").read ())
# exec (open ("bbb.py", encoding = "utf8").read ())
exec (open ("ccc.py", encoding="utf8").read ())
...

Pourquoi cette solution ? Comme j'utilise Notepad++ pour écrire mes programmes, je ne pouvais pas les lancer simplement avec F5 (ou toute autre touche) comme avec l'éditeur Python, il fallait les rouvrir à chaque fois dans l'éditeur Python, ce qui était fastidieux.

En utilisant ce "lanceur", je peux modifier le programme aaa (ou autres) et ré exécuter le lanceur, qui lui n'a pas été modifié, via l'éditeur Python. Autre aspect pratique, tous les programmes exécutés ainsi fonctionnent comme s'ils étaient dans le même programme, ce qui me permet d'utiliser éventuellement (choix possible) des variables précédentes et laisser un fichier Excel ouvert (cela me permet de voir ce qui se passe, voire d'intervenir en cours d'exécution).

Ayant appris Python tout seul, je n'ai peut-être pas utilisé une solution très rigoureuse.

Chaque programme accède à un fichier pour récupérer quel trimestre de quelle année à traiter ainsi que d'autres informations. Je souhaite mettre toutes ces lignes de codes dans une bibliothèque. Comme tous ces programmes se comportent comme un seul programme avec les exec (open()), il me faut bien tester l'existence du path du module commun dans sys.path si je ne veux pas l'ajouter plusieurs fois.

Donc entre plusieurs lignes de code qui me permettront de construire le chemin et de tester son path dans sys.path et :

Code :

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

1
2
 
import ..Bibli.module1

La 2ème solution me paraît plus élégante . Donc j'aimerai bien savoir comment on fait pour adresser un dossier de même niveau.


Pour les variables qui n'existent que dans la fonction, je trouve que la gestion des variables dans Python est un peu complexe pour les variables globales. Je m'arrachais un peu les cheveux quand j'avais plusieurs fonctions qui s'appelaient en cascade pour trouver où positionner global variable. J'ai trouvé très récemment qu'il fallait le mettre dans toutes les fonctions qui utilisait cette variable (si ce n'est pas clair, je peux montrer un exemple). Donc avant cette "découverte", je passais les variables dans la fonction, ce qui devenait fastidieux quand il y en avait beaucoup. Il me semble qu'un global en début de programme eut été bien plus simple.

[wiztricks]

Salut,

Ayant appris Python tout seul, je n'ai peut-être pas utilisé une solution très rigoureuse.

exec(...) est un équivalent d'import.
Si vous voulez utilisez des scripts en tant que "programme", il est préférable de les lancer comme programmes via subprocess.Popen/Run/call.

Il me semble qu'un global en début de programme eut été bien plus simple.

Il y a des tas de façons de résoudre ce problème. Techniquement, on fait çà avec de la POO et des "class" mais vous pouvez aussi avoir un module "globs.py" contenant les variables globales de votre programme.

Un langage de programmation est un outil.
Les problèmes que vous allez rencontrer pour construire une application avec cet outil là sont en général résolus par des fonctionnalités qu'on ne connaît pas encore (et c'est l'intérêt d'un forum de vous aiguiller) rarement par des bricolages que vous généralisez.

- W

[sjlouis]

J'avais essayé l'instruction subprocess mais je n'y étais pas arrivé, même chose pour d'autres fonctions. J'avais trouvé exec(open)) sur plusieurs sites et cela me donnait le résultat attendu, alors je m'en suis servi. Il faudra que j'examine Popen, je ne connais pas.

Je me suis servi du livre de Gérard Swinnen pour découvrir Python. C'est une bonne base mais pour aller plus loin, ça devient plus compliqué. La doc python dont vous donnez le lien est très bien, je vais la consulter régulièrement même si elle est un peu trop souvent en Anglais, mais elle est un peu "sobre", il manque des exemples pour bien comprendre.

Je suis resté longtemps sans programmer mais comme nous achetions les langages, il y avait des documentations très exhaustives qui permettaient de consulter toutes les instructions avec des exemples. Pour Python, je vais à la pêche. Le pire c'est pour pywin32. Là il faut batailler et faire des tests pour trouver comment implémenter des fonctions vba.

Je ne comprends pas bien comment on peut utiliser un module pour les variables globales, déjà que j'ai du mal depuis longtemps avec les modules personnels. Dans d'autres langages, c'était bien plus simple et j'avais pu m'en servir très rapidement et utiliser des bibliothèques de programmes communs (utilisés par d'autres programmes). Là j'ai attendu d'avoir un peu de temps pour fouiner à nouveau mais j'ai toujours du mal. Rien que pour utiliser des répertoires de même niveau comme indiqué dans mon premier message, je n'y arrive pas alors que cela me semble si simple.

[wiztricks]

Salut,

J'avais essayé l'instruction subprocess mais je n'y étais pas arrivé, même chose pour d'autres fonctions. J'avais trouvé exec(open)) sur plusieurs sites et cela me donnait le résultat attendu, alors je m'en suis servi. Il faudra que j'examine Popen, je ne connais pas

L'intérêt d'un forum est de montrer ce que vous avez essayé de faire pour qu'on vous explique ce que vous n'avez pas compris et qu'on vous donne sinon une solution au moins une idée de comment la construire.

Je ne comprends pas bien comment on peut utiliser un module pour les variables globales, déjà que j'ai du mal depuis longtemps avec les modules personnels.

Rien ne vous empêche de créer un module globs.py contenant:

x = y = 0

puis dans les modules qui ont des fonctions qui, écrire:

Code :

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

1
2
3
4
import globs
 
def f():
     globs.x += 1

Et voilà, j'ai fabriqué des variables globales (sans utiliser le mot clef "global").

Rien que pour utiliser des répertoires de même niveau comme indiqué dans mon premier message, je n'y arrive pas alors que cela me semble si simple.

Ajouter le chemin dans sys.path est une solution (il y en a d'autres(*)) qui fonctionne mal si vous utilisez exec de script qui vont ajouter encore le chemin... mais si vous passez par subprocess, vous aurez autant de sys.path que de programmes lancés.
(*) la documentation est là pour çà.

- W

[sjlouis]

Alors j'ai essayé globs.py, intéressant. Par contre est-ce qu'il y a moyen de ne pas mettre globs. devant le x ? Car ça alourdit mes noms de variables qui sont déjà assez longs pour être plus explicites. J'ai bien essayé :

Code :

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

1
2
3
 
import globs
from globs import x as x

et

Code :

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

1
2
3
 
import globs
from globs import globs.x as x

mais cela ne fonctionne pas. C'est peut-être idiot comme idée mais n'utilisant pas les alias, je n'en connais pas les "subtilités".

Ajouter le chemin dans sys.path est une solution (il y en a d'autres(*)) ...
(*) la documentation est là pour çà.

Comme je le disais, je vais souvent lire la documentation mais je ne comprends pas toujours ce que l'instruction fait ou comment l'utiliser. Quand j'ai pris "exec(open())", c'est après avoir cherché longuement.

Sinon j'aimerais bien comprendre cette histoire de chemin relatif et de chemin absolu pour importer des modules. J'arrive à utiliser des modules dans le même dossier ou dans le dossier en dessous mais pas dans un dossier en parallèle, cela ne fonctionne pas avec les points multiples qui sont censés me faire remonter d'un dossier (ou plus).

[wiztricks]

Salut,

Alors j'ai essayé globs.py, intéressant. Par contre est-ce qu'il y a moyen de ne pas mettre globs. devant le x ?

Si vous écrivez from globs import x vous fabriquez une variable x "global"e au module courant.

Si l'objet associé à x est mutable, vous pourrez le modifier. Sinon, le modifier, c'est assigner à x un autre objet. Dans une fonction, il faudra la déclarer "global"... mais ce faisant vous ne modifierez que le x du module et non globs.x.

Sinon j'aimerais bien comprendre cette histoire de chemin relatif et de chemin absolu pour importer des modules.

Le message d'erreur est clair: vous ne pouvez faire .. au delà de la "racine" qui est définie par le répertoire courant de votre script principal qui est définit comme "__main__".

Tout ce qui est "ailleurs" doit être dans sys.path (ce que vous savez déjà) et vous pouvez distribuer un package dans plusieurs répertoire mais il faut alors passer par la définition du __path__ (qui est plus contraignante).

- W

[sjlouis]

Je vois bien que je ne peux pas aller au dessus du dossier duquel j'ai lancé le script mais d'une part je ne comprends pas l'intérêt d'une telle limitation qui me semble idiote et d'autre part si les .., voire ... et davantage existent, c'est bien pour s'en servir et remonter, non ?

Par contre je ne comprends pas ces phrases :

Si l'objet associé à x est mutable, vous pourrez le modifier. Sinon, le modifier, c'est assigner à x un autre objet.

Que voulez vous dire avec "mutable" ? Et je ne vois pas ce que veut dire la 2ème. Sinon il n'y a pas moyen de n'utiliser que x et de conserver les qualités du module globs ?

[wiztricks]

Je vois bien que je ne peux pas aller au dessus du dossier duquel j'ai lancé le script mais d'une part je ne comprends pas l'intérêt d'une telle limitation qui me semble idiote et d'autre part si les .., voire ... et davantage existent, c'est bien pour s'en servir et remonter, non ?

Vous avez la même chose sur les systèmes de fichiers: si le répertoire par défaut est la racine, cd .. ne vous laissera pas aller plus haut.
C'est un peu la même logique.

Par contre je ne comprends pas ces phrases :

Si l'objet associé à x est mutable, vous pourrez le modifier. Sinon, le modifier, c'est assigner à x un autre objet.

Que voulez vous dire avec "mutable" ? Et je ne vois pas ce que veut dire la 2ème. Sinon il n'y a pas moyen de n'utiliser que x et de conserver les qualités du module globs ?

Une liste est un objet "mutable", un entier ne l'est pas.
Si on part de:

Code :

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

1
2
>>> a = 1
>>> b = a

1 est un entier et n'est pas mutable. Ce qui se traduit par l'impossibilité de modifier l'objet "1". Et si tout ce que je peux faire c'est assigner un autre objet à la variable a, impossible de propager cela à b:

Code :

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

1
2
3
>>> a = 0
>>> b
1

Par contre, si on part d'une liste:

Code :

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

1
2
>>> a = [1, 2, 3]
>>> b = a

Je peux la modifier:

Code :

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

>>> a += ['x']

et comme b est toujours associé à ce même objet "voir" le changement:

Code :

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

1
2
>>> b
[1, 2, 3, 'x']

- W

[sjlouis]

OK pour l'objet mutable, curieux même si je ne vois pas quoi en faire.

Pour la racine, je ne comprends toujours pas l'intérêt de dire que c'est la racine alors que ce n'est pas le cas. En plus d'après ce que j'avais lu, ce n'était pas le cas avec Python 2 mais je n'a pas testé, je n'ai jamais utilisé cette version.

Et il faudra que je n'arrive à comprendre ces notions d'importation relative et absolue. Si c'est absolu, je devrais pouvoir donner un chemin complet :

C:\Users\jeanl\Documents\DIP\Progs


Soit :

Users.jeanl.Documents.DIP.Progs

ou quelque chose d'approchant, mais cela ne fonctionne pas. Pourtant on peut faire l'équivalent avec le langage :

os.path.dirname (os.getcwd())

[wiztricks]

OK pour l'objet mutable, curieux même si je ne vois pas quoi en faire.

Attendez là on parle d'une notion de base qui interpelle tout débutant car elle n'est pas sans conséquence. Nombre d'entre eux viennent régulièrement ici demander des explications: difficile de passer à côté!
note: et même le Swinnen en parle en utilisant modifiable/non modifiable plutôt que le terme technique globish "mutable". D'ailleurs si vous allez voir un peu l'article Wikipedia en français sur le sujet, vous verrez encore d'autres appellations.

Pour la racine, je ne comprends toujours pas l'intérêt de dire que c'est la racine alors que ce n'est pas le cas.

C'est Python qui définit ce qu'est la racine et s'il dit que la racine est le répertoire du module __main__ il n'y a rien à comprendre: vous pouvez juste faire avec.

- W

[lg_53]

Pour revenir à votre problème de départ, je donnerais 2 options :

1) Arrêter Notepad et coder avec un vrai truc. Perso j'utilise Spyder. Vous vous définissez un projet avec ça, projet qui est la racine de tous vos sources. Le dossier du projet étant automatiquement ajouter à votre Path par Spyder.
Donc dans prog1.py, vous pourriez avoir qch comme

Code :

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

from Bibli import bibl1

ou bien

Code :

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

from DIP.Bibli import bibl1

selon là où vous placez la racine de votre projet. Vous avez une zone pour coder. Le F5 pour éxécuter, la console interractive, l'explorateur de projet, la totale quoi.
Et même des petits panneau warning qui apparaissent lorsqu'une parenthèse manquantes est détecté ou bien qu'une variable utilisée n'est pas connue.

2) Autre option, c'est d'éxécuter le code python, comme on éxécute n'importe quel code : en ligne de commande, avec le terminal système.
Si vous avez des dépendances, idem : dans chacun de vos modules, faites les import depuis la racine de votre projet. Dans le terminal, placer vous aussi à la racine, et éxécuter avec le chemin depuis la racine du projet, par exemple

Code :

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

python -m DIP.prog.prog1

3) 3eme option, mais je ne la compte pas car elle semble manifestement pas du tout à votre niveau, et elle vous a déjà été proposé : faire un package python, installable avec pip.

[sjlouis]

Même si je consulte le manuel de Swinnen de temps en temps (et même ce matin), je l'ai lu il y a 4 ans et comme en plus je n'ai plus une grande mémoire, il y a pas mal de choses que j'ai oubliées.

Pour mon problème de racine, j'ai donc utilisé sys.path même s'ils le déconseillent sur d'autres sites. Ne me demandez pas pourquoi, ce n'était pas expliqué. A ce sujet pourquoi utiliser exec(open()) est moins approprié que subprocess ?

J'irai regarder Spider, cela semble sympa. J'avais pris Notepad++ car il est bien plus pratique que l'éditeur standard qui est très limité.

Pour le package Python avec PIP, je ne sais pas ce que c'est. Si je trouve un peu de temps, je chercherai.

Mes connaissances vous semblent quelque peu limitées mais ce n'est pas évident de se former tout seul et d'être le seul dans sa structure à utiliser un produit, il n'y a personne avec qui échanger. En plus lors de la ré organisation de l'entreprise, les têtes pensantes de ma boîte ont choisi de sous-traiter les développements, donc quasiment plus personne d'interne n'en fait. Et donc pas de formation ou de soutien. Je me débrouille avec Internet avec le temps dont je dispose.

[wiztricks]

Pour mon problème de racine, j'ai donc utilisé sys.path même s'ils le déconseillent sur d'autres sites. Ne me demandez pas pourquoi, ce n'était pas expliqué. A ce sujet pourquoi utiliser exec(open()) est moins approprié que subprocess ?

Parce que vous l'utilisez pour lancer une suite de programmes "indépendants"... qui, pour fonctionner indépendamment, ont besoin d'ajouter un chemin dans sys.path ce qui vous a amené à raconter dans votre premier post:

comme chaque programme l'ajouterait, sans compter qu'ils peuvent être lancés à plusieurs reprises, il faudrait que je teste sa présence pour ne pas qu'il soit ajouté plusieurs fois

Si vous utilisiez subprocess, les exécutions seraient effectivement indépendantes et chacun aurait son propre sys.path....

Mes connaissances vous semblent quelque peu limitées mais ce n'est pas évident de se former tout seul et d'être le seul dans sa structure à utiliser un produit, il n'y a personne avec qui échanger.

Comme je vous l'ai déjà dit les forums de discussion peuvent aider. Mais il faut poser des questions avant de vous lancer dans une solution baroque.
Sûr que s'il existe des solutions "python" largement documentées, vous risquez de vous faire envoyer à la lecture des tutos et de la documentation: ils sont faits pour çà. Et on ne peut vous aider qu'à mieux maîtriser des concepts que vous avez déjà essayé de comprendre par vous même.

- W

[sjlouis]

Alors lorsque j'ai lu que la solution sys.path n'était pas privilégiée, ce n'était pas moi qui avait posé la question. Je l'ai lu dans plusieurs forums "anglais". Sinon il n'est pas difficile de tester si Bibli est déjà dans le path avant de tenter de l'y ajouter, c'est tout de même plus propre et c'est ce que j'ai testé.

Mes programmes ne sont que relativement indépendants car il travaille de façon linéaire sur les mêmes fichiers en entrée et en sortie. Si je relance tout ou partie des programmes, c'est parce que je peux recevoir une partie des fichiers en retard ou parce que certains comportent des erreurs que j'identifie et que je demande aux utilisateurs de corriger avant de les traiter à nouveau. Alors le fait que mes programmes soient vus comme un même programme est en fait un avantage car ils peuvent partager les mêmes variables et surtout le même fichier de résultat Excel sans que je sois obligé de le fermer et ainsi le sauvegarder. Ne pas le sauvegarder me permet de relancer le traitement sans être obligé de ré initialiser le fichier Excel.

J'ai bien cherché sur Internet comment accéder à un fichier déjà ouvert mais je n'ai rien trouvé. Et je procède à chaque fois ainsi,quand je veux faire quelque chose que je ne sais pas faire, je vais chercher sur Internet une solution et je vais prendre celle qui me paraît la meilleure, c'est pour ça que le terme "baroque" me gêne un peu. Alors il est tout à fait possible qu'il y ait des solutions davantage dans les règles de l'art mais si je ne l'ai pas prise, c'est parce que je ne l'ai pas trouvée.

Sinon j'ai vu que Spyder pouvait être installé avec Anaconda. Hormis des bibliothèques scientifiques dont je n'ai pas besoin, y a-t-il un intérêt à installer Anaconda ?

[wiztricks]

Salut,

c'est pour ça que le terme "baroque" me gêne un peu. Alors il est tout à fait possible qu'il y ait des solutions davantage dans les règles de l'art mais si je ne l'ai pas prise, c'est parce que je ne l'ai pas trouvée.

Pour trouver quelque chose, il faut déjà essayer de formuler correctement ses besoins. Et çà commence par faire la différence entre module qu'on importe et programme qu'on lance indépendamment.

Un forum sert aussi à vous permettre de mieux formuler votre problème essentiellement parce qu'on discute, on essaie de comprendre ce que vous cherchez à faire.

Une solution proposée par Python sera de tester si la variable __name__ est "__main__" ou pas. Ce qui vous permet de savoir si le script a été lancé en tant que programme ou importé comme module et exécuter des instructions d'initialisation dans un cas ou dans l'autre.
note: si vous faites exec(open(...)) __name__ sera celui du module courant et ne permettra pas de faire la différence.

Alors lorsque j'ai lu que la solution sys.path n'était pas privilégiée, ce n'était pas moi qui avait posé la question. Je l'ai lu dans plusieurs forums "anglais". Sinon il n'est pas difficile de tester si Bibli est déjà dans le path avant de tenter de l'y ajouter, c'est tout de même plus propre et c'est ce que j'ai testé.

Vous pouvez aussi renseigner la variable d'environnement PYTHONPATH et ne rien tester du tout (parmi d'autres).
Dans ce cas, inutile de modifier sys.path et ni de tester quoi que ce soit.... Et vous pouvez même déplacer votre répertoire sans avoir à retoucher les différents programmes.

Et tant que vous essayez de généraliser l'astuce que vous connaissez plutôt que d'évaluer avantages et inconvénients de différentes possibilités, vous risquez de tomber dans le "baroque". Le truc qui marche avec plein de soucis qu'on ne cherchera pas à résoudre car pas grand monde code comme çà.

- W

[sjlouis]

Alors je vais me répéter mais je ne prends pas la première solution que je trouve. Je fais des tests, j'examine et je prends celle qui me paraît la plus intéressante et la plus propre. Alors je ne suis pas suffisamment perfectionné pour avoir toutes les billes en main mais je fais avec les éléments dont je dispose. Et je ne compte pas mon temps pour chercher des infos complémentaires sur Internet. Alors si c'est pour le exec(open()), c'est sûr que ça m'a paru curieux mais je l'ai pris car je n'arrivais pas à faire fonctionner les autres possibilités comme subprocess.

Alors en quoi exec(open()) n'est pas une bonne solution ? pour ma part jusqu'à présent, je n'y ai trouvé que des avantages.

Pour la variable d'environnement PYTHONPATH, je ne la trouve pas. Il faut la créer ?

[wiztricks]

Alors en quoi exec(open()) n'est pas une bonne solution ? pour ma part jusqu'à présent, je n'y ai trouvé que des avantages.

import pour un module et subprocess pour un programme sont les interfaces standards pour accéder/créer des 2 types d'objets.
Si vous utilisez exec, c'est pour d'autres besoins que ceux offerts par ces interfaces là.
Vous ne l'utilisez que parce que vous n'avez pas été capable de faire fonctionner subprocess. C'est une bonne raison pour ouvrir une nouvelle discussion montrant ce que vous avez essayé de faire et demander de l'aide pour comprendre comment le mettre en œuvre.

Pour la variable d'environnement PYTHONPATH, je ne la trouve pas. Il faut la créer ?

Bah... vous programmez avec Python et vous n'avez même pas lu le mode d'emploi qui explique comment l'utiliser sur votre système?

Je suis sûr que si vous changez de voiture, vous lirez attentivement le mode d'emploi ne serait ce que pour savoir ouvrir le coffre, où est la roue de secours, le fonctionnement des feux de signalisation,... les trucs de base qui vous permettent de prendre la route sans être un danger pour les autres où pour vous même.

- W

[sjlouis]

Alors là je ne vais pas me faire des amis mais j'en ai ma claque d'être pris pour un imbécile, je savais qu'il ne fallait pas que je lise la réponse hier soir car cela allait me prendre sérieusement la tête et ça n'a pas manqué.

Alors en quoi j'ai besoin de PYTHONPATH ? C'est comme les fichiers autoexec.bat et config.sys sous MS-Dos, ils sont devenus "transparents" avec les premières versions de Windows et maintenant il n'y a plus "rien" dedans alors qu'avant il fallait les renseigner soigneusement pour avoir un PC opérationnel.

Gérard Swinnen n'en parle pas et il ne me semble pas que j'aurais pu en avoir besoin. Alors c'est vrai que dans ma recherche sur l'utilisation d'une bibliothèque en parallèle, j'ai pu voir sys.path, les imports relatifs avec les .. qui ne fonctionnent pas et le PYTHONPATH sur lequel personne ne s'étendait.

Malgré tout j'avais un peu cherché et quand dans le shell Dos, je tapais echo %pythonpath%, il n'y avait rien, rien non plus depuis le shell Python qui me retournait :

Code :

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

1
2
 
NameError: name 'pythonpath' is not defined

Rien dans les variables d'environnement de Windows. Alors il est où, que contient-t-il exactement? Ou bien faut-il le créer ? C'est la question que j'avais posée et vous me retournez vers la doc que j'avais déjà lue et qui ne permet pas, ni de le trouver ni de voir ce qu'il contient. OK, j'avais bien compris qu'on y gérait des paths mais est-ce qu'il existe et quels sont les paths déjà présents ?

Au moins il y a une vraie littérature sur sys.path.

Et quand vous me dites, ça c'est bien et ça c'est pas bien, pourquoi ? Moi j'aime bien comprendre la logique des choses. Je fais des tests, je compare les différentes solutions et je prends celle qui me parait la meilleure, que ce soit en terme de lisibilité ou en terme de performance. La solution open(exec(fichier)) est un peu curieuse, mais comme exec(instruction), elle permet d'exécuter des instructions contenues dans un fichier et le résultat correspond à ce que je recherchais.

Quand vous me dites que vous cherchez dans le manuel d'une nouvelle voiture comment allumer les feux, ouvrir le coffre, trouver la roue de secours, alors je me dis ou bien wiztricks a choisi un exemple bien pourri, ou bien son niveau en "mécanique" est abyssalement plus bas que le mien en Python. Même ma femme qui a des connaissances en mécanique quasiment inexistantes serait capable de trouver la roue de secours. Pour la monter, ça c'est autre chose.

Alors oui quand j'achète un objet évolué, je vais regarder la notice comme j'ai pu étudier le livre de Gérard Swinnen. Donc pour ma Focus, j'ai parcouru la notice de 400 pages pour voir s'il n'y avait pas des fonctions que je ne connaissais pas et j'ai trouvé que la 4ème position pour les feux permettait de faire pivoter les feux dans les virages serrés, ce qui est bien pratique dans les épingles des cols de montagne, qu'on pouvait ouvrir et verrouiller la voiture en passant la main devant ou derrière une des poignées (gadget), comment afficher Google Maps sur l'écran de l'écran multi media...

Je vais aussi consulter les notices techniques pour savoir à quelle fréquence je dois changer les bougies, le filtre... connaître la norme exacte pour la qualité d'huile, d'autant qu'on ne la trouve pas dans le commerce de proximité.

Pour mes motos, je vais y chercher les couples de serrage des différents éléments, les jeux limites pour les pistons et les segments. Récemment cela m'a permis de trouver le bon jeu de coussinets de bielles parmi 3 choix possibles.

Alors oui je vais regarder la doc mais pas pour voir comment on débraie.

Et quand vous me dites que vous en avez besoin pour ne pas être un danger sur la route, wouaw ! Je ne me serais pas imaginé que savoir ouvrir le coffre pouvait protéger des accidents !

Je me moque mais je l'ai un peu en travers. Il a fallu que je pose 5 ou 6 fois la question au sujet des imports relatifs pour que vous me disiez que pour Python le répertoire où était lancé le programme était considéré comme la racine. Pour vous c'est peut-être évident mais pas pour tous ceux qui posaient a même question et qui ne comprenaient pas non plus pourquoi le .. ne remontait pas au dessus. Ceux qui répondaient fournissaient d'autres solutions. Et cette question était le sujet de mon post.

Alors si j'ai été un bon informaticien il y a bien longtemps, je m'y remets et cela prendra un peu de temps, même si vous en doutez.

Et comme vous faites la comparaison avec une voiture, ayant fait des compétitions de sports mécaniques en tout genres, je n'ai pas appris à "piloter" en quelques jours, ni appris à régler mon matériel rapidement d'autant plus qu'à l'époque c'était très confidentiel.

Maintenant j'en fais profiter d'autres personnes et j'essaie de leur expliquer comment ça fonctionne sans leur dire ou sous-entendre qu'ils sont nuls et que cela ne vaut pas la peine. Donc si quelqu'un a un problème de fourche en tout terrain, que ce soit avec une moto ou un VTT, plutôt de descente, je vais lui expliquer que s'il trouve la fourche trop ferme sur les chocs et qu'il ouvre la compression, et bien il va avoir un engin qui va plonger de l'avant et taper davantage dans les trous de freinage. En plus l'engin va devenir pataud et peu précis. Mauvais plan. Pour les chocs, que ce soient des racines, des sauts ou des trous de freinage, il faut jouer sur les hautes vitesses, et là il faut démonter et modifier l'empilement de clapets.

Si un autre me dit que sa suspension arrière est trop souple et qu'il va resserrer le ressort, mauvais plan également. Je ne vais pas lui dire "t'es nul, va réviser tes cours de physique de lycée". Je vais lui faire un dessin avec l'action sur un ressort "mou", un ressort "mou" davantage pré comprimé et un ressort "ferme". Sur un graphique, on voit tout de suite qu'un ressort "mou" pré comprimé va perdre en sensibilité mais ne pas empêcher les talonnages pour autant. Et si le ressort influe sur la souplesse de la suspension, il sert surtout à maintenir le châssis et à modifier l'assiette. Il vaut mieux modifier l'hydraulique.

Je ne développe pas, cela n'est pas le sujet sur ce forum et en plus, vu votre niveau, et là je me moque encore à mon tour, cela doit vous passer largement au dessus de la tête. Comme la quasi totalité des gens, quand vous montez dans une voiture, vous lui demandez juste de vous emmener à un autre point, pourvu qu'il y ait la radio, la clim et les vitres électriques sans vous soucier de la façon dont ça fonctionne sous le capot ou au niveau du châssis alors que pour ma part, je vais chercher comment rendre ma voiture, mes motos et mes VTT plus efficaces.

J'ai procédé de la même façon quand je formais mon équipe et des utilisateurs, même si étant plus jeune j'étais moins pédagogue.

Alors peut-être qu'avec un peu de temps je continuerai à me perfectionner avec Python comme j'ai pu être performants avec d'autres langages. Simplement les langages actuels offrent davantage de possibilités et il faut plus de temps pour essayer de tous les appréhender alors que je suis un peu sous pression et qu'en dehors du boulot, je n'ai pas que Python dans la tête.

Alors malgré tout j'ai appris quelques petites choses intéressantes mais dans un tel climat que je ne suis pas prêt de reposer des questions sur ce forum. Pour ma 2ème question en 4 ans sur un forum Python, ce qui montre que je ne cherche pas des solutions "faciles", on peut dire que j'ai été douché.

Alors je me doute bien que je vais me faire rincer mais au moins ça m'a défoulé. Merci et au revoir.