Comment importer un module personnel d'un autre dossier ?

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:

---

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:

---

1 2 3

x = "toto" y = "fifi"

---

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

Code:

---

1 2	from modul1 import x,y

---

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

Code:

---

1 2 3 4

def fonct() : x = "toto" y = "fifi"

---

Merci pour votre aide :P .

Salut,

Citation:

---

Envoyé par sjlouis

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.

Citation:

---

Envoyé par sjlouis

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

Code:

---

1 2 3

x = "toto" y = "fifi"

---

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

Code:

---

1 2	from modul1 import x,y

---

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

Code:

---

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

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 :mrgreen:.

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:

---

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:

---

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.

Salut,

Citation:

---

Envoyé par sjlouis

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.

Citation:

---

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

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.

Salut,

Citation:

---

Envoyé par 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

---

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.

Citation:

---

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:

Citation:

---

x = y = 0

---

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

Code:

---

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").

Citation:

---

Envoyé par sjlouis

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

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:

---

1 2 3

import globs from globs import x as x

---

et

Code:

---

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

Citation:

---

Envoyé par wiztricks

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

Salut,

Citation:

---

Envoyé par 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 ?

---

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.

Citation:

---

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

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 :

Citation:

---

Envoyé par wiztricks

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 ?

Citation:

---

Envoyé par 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 ?

---

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.

Citation:

---

Envoyé par sjlouis

Par contre je ne comprends pas ces phrases :

Citation:

---

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:

---

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:

---

1 2 3

>>> a = 0 >>> b 1

---

Par contre, si on part d'une liste:

Code:

---

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

---

Je peux la modifier:

Code:

---

>>> a += ['x']

---

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

Code:

---

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

---

- W

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

Citation:

---

Envoyé par sjlouis

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.

Citation:

---

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

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:

---

from Bibli import bibl1

---

ou bien

Code:

---

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:

---

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.

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.

Citation:

---

Envoyé par sjlouis

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:

Citation:

---

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

Citation:

---

Envoyé par sjlouis

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

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 ?

Salut,

Citation:

---

Envoyé par sjlouis

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.

Citation:

---

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

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 ?

Citation:

---

Envoyé par sjlouis

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.

Citation:

---

Envoyé par sjlouis

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

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:

---

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.

Salut,

Citation:

---

Envoyé par sjlouis

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 ?

---

Ouvrez la documentation et vous y trouverez:

Citation:

---

PYTHONPATH

Augmente le chemin de recherche par défaut des fichiers de modules. Le format est le même que pour PATH du shell : un ou plusieurs chemins de répertoires séparés par os.pathsep (par exemple, le caractère deux-points sous Unix et point-virgule sous Windows). Les répertoires qui n'existent pas sont ignorés silencieusement.

En plus des répertoires normaux, des entrées individuelles de PYTHONPATH peuvent faire référence à des fichiers zip contenant des modules en pur Python (soit sous forme de code source, soit sous forme compilée). Les modules d'extensions ne peuvent pas être importés à partir de fichiers zip.

Le chemin de recherche par défaut dépend de l'installation mais commence généralement par préfixe/lib/pythonversion (voir PYTHONHOME ci-dessus). Il est toujours ajouté à PYTHONPATH.

Comme indiqué ci-dessus dans Options de l'interface, un répertoire supplémentaire est inséré dans le chemin de recherche devant PYTHONPATH. Le chemin de recherche peut être manipulé depuis un programme Python avec la variable sys.path.

---

Çà commence par "Augmente le chemin de recherche par défaut" puis çà vous explique quoi çà ressemble et ce qu'est "le chemin de recherche par défaut".
Et si ce n'est pas encore assez clair, vous pouvez toujours chercher des exemples sur Internet.

Citation:

---

Envoyé par sjlouis

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

---

La première littérature étant la documentation

Citation:

---

sys.path

Une liste de chaînes de caractères spécifiant les chemins de recherche des modules, initialisée à partir de la variable d'environnement PYTHONPATH et d'une valeur par défaut dépendante de l'installation.

Puisqu'il est initialisé au démarrage du programme, le premier élément de cette liste, path[0], est le dossier contenant le script qui a été utilisé pour invoquer l'interpréteur Python. Si le dossier du script n'est pas disponible (typiquement, si l'interpréteur est invoqué interactivement ou si le script est lu à partir d'une entrée standard), path[0] sera une chaîne vide, qui indiquera à Python de chercher des modules dans le dossier actuel. Notez que le dossier du script est inséré avant les dossiers de PYTHONPATH.

Un programme est libre de modifier cette liste pour ses propres besoins. Seuls des str ou des bytes ne devraient être ajoutés à sys.path, tous les autres types de données étant ignorés durant l'importation.

---

Pas facile de passer à coté de PYTHONPATH lorsqu'on lit la vraie littérature sur sys.path.

Citation:

---

Envoyé par sjlouis

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 ne vous ai pas dit bien ou pas bien juste qu'on utilise import pour les modules, subprocess pour lancer les programmes et exec lorsqu'on a besoin d'une autre interface. Il n'y pas de notion de "bien", "pas bien" à choisir l'outil le plus adapté à ce qu'on veut faire.

Citation:

---

Envoyé par sjlouis

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.

---

Pour pouvoir comparer des solutions, il faut arriver à les faire fonctionner (ou essayer de comprendre pourquoi vous n'y arrivez pas). Et si vous choisissez
exec(...) parce que vous n'avez pas réussi à faire fonctionner subprocess et que vous n'avez pas penser à utiliser import... vous n'avez rien comparé du tout.

Citation:

---

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.

---

Vous n'êtes pas en train de demander de l'aide pour comprendre comment coder l'exercice d'un tuto mais poser des questions sur une utilisation un peu avancée de python telles que exec et la modification de sys.path.

On peut donc supposer que vous avez de bonnes raisons pour ne pas utiliser des solutions plus standards que sont import et subprocess et que vous avez un peu cherché sur Internet (ou la documentation) ce qui se raconte sur ce message d'erreur: "ValueError: attempted relative import beyond top-level package."

Car pour revenir à nos histoires de bagnoles, un voyant (le message d'erreur) se met à clignoter, vous savez pas s'il faut faire le niveau d'huile, s'inquiéter de la pression des pneus, faire le plein d'essence,... (comprendre le message).

- W

Alors j'ai passé un peu de temps à faire des recherches supplémentaires et des tests.

Citation:

---

Envoyé par wiztricks

Ouvrez la documentation et vous y trouverez:

Çà commence par "Augmente le chemin de recherche par défaut" puis çà vous explique quoi çà ressemble et ce qu'est "le chemin de recherche par défaut".
Et si ce n'est pas encore assez clair, vous pouvez toujours chercher des exemples sur Internet.

La première littérature étant la documentation

Pas facile de passer à coté de PYTHONPATH lorsqu'on lit la vraie littérature sur sys.path.

---

Sur Stackoverflow, j'ai pu voir que je n'étais pas le seul en difficulté avec Pythonpath pour Windows, il y a des échanges fournis et si la doc dit que sys.path récupère les infos de Pythonpath, la variable ne semble pas exister, tout au moins sous ce nom. Et si pour ajouter un lien permanent à Pythonpath, on trouve l'instruction avec "export", a priori elle ne fonctionne que sur Linux. Donc les solutions les mieux notées indiquent :
- qu'il suffit de la créer dans le registre de Windows et d'y ajouter le path souhaité,
- ou bien d'ajouter le chemin souhaité dans le path Windows,
- ou bien de mettre le chemin dans un fichier .pth dans C:\Users\nom_user\AppData\Local\Programs\Python\Python37-32\Lib\site-packages

De toute façon, je voulais avoir un chemin relatif, ce que ne permet pas cette solution, je vais donc utiliser sys.path et tester que le chemin n'existe pas déjà.

Citation:

---

Envoyé par wiztricks

Je ne vous ai pas dit bien ou pas bien juste qu'on utilise import pour les modules, subprocess pour lancer les programmes et exec lorsqu'on a besoin d'une autre interface. Il n'y pas de notion de "bien", "pas bien" à choisir l'outil le plus adapté à ce qu'on veut faire.

Pour pouvoir comparer des solutions, il faut arriver à les faire fonctionner (ou essayer de comprendre pourquoi vous n'y arrivez pas). Et si vous choisissez
exec(...) parce que vous n'avez pas réussi à faire fonctionner subprocess et que vous n'avez pas penser à utiliser import... vous n'avez rien comparé du tout.

---

J'avais regardé ces instructions il y a 3 ans et comme j'avais peu de temps, j'ai pris celle qui me donnait le résultat escompté. Là j'ai un peu plus de temps, mon application étant bien avancée.

Alors je suis allé voir à nouveau ces instructions et après avoir noté il y a quelques temps une instruction pour "import", à savoir "import variables from module", cela fait ce que je voulais faire la première fois, sauf que pour importer ces variables, elles ne doivent pas être dans une fonction du module appelé, ou alors si c'est possible, je n'ai pas trouvé comment faire. Je souhaite mettre le traitement de ces variables dans une fonction pour qu'elles soient dans un "paragraphe propre à ces instructions" de mon module bibliothèque de fonctions. Alors je peux malgré tout les mettre au début du module ou dans un module spécifique même si cela me convient moins.

Pour subprocess, je n'ai toujours pas compris comment m'en servir et les exemples fournis utilisent des instructions Linux.

Code:

---

1 2 3

import subprocess subprocess.Popen(["dir"])

---

retourne un message d'erreur.

Code:

---

1 2 3

import subprocess, sys subprocess.Popen([sys.executable, "dir"])

---

fonctionne mais n'affiche rien à la console.

Même chose pour :

Code:

---

1 2 3

import subprocess, sys subprocess.Popen([sys.executable, "print('toto')"])

---

ou pour :

Code:

---

1 2 3

import subprocess, sys subprocess.Popen([sys.executable, "C:\\Users\\nom_user\\Documents\\DIP\\Progs\\ddd.py"])

---

où ddd.py comporte l'instruction "print".

Quand je dis que je compare 2 solutions, ce sont des lignes de code. Ainsi pour faire des contrôles sur des milliers de ligne, je peux penser à 2 traitements différents et je vais retenir celui qui dure le moins longtemps.

Citation:

---

Envoyé par wiztricks

On peut donc supposer que vous avez de bonnes raisons pour ne pas utiliser des solutions plus standards que sont import et subprocess et que vous avez un peu cherché sur Internet (ou la documentation) ce qui se raconte sur ce message d'erreur: "ValueError: attempted relative import beyond top-level package."

---

Et bien non, je n'ai pas pensé à rechercher juste sur ce message, j'ai juste pu voir que je n'étais pas le seul à avoir ce message et que ceux qui répondaient n'expliquaient pas ce qu'il signifiait, je ne l'ai compris que lorsque vous m'avez répondu.

Citation:

---

Envoyé par wiztricks

Car pour revenir à nos histoires de bagnoles, un voyant (le message d'erreur) se met à clignoter, vous savez pas s'il faut faire le niveau d'huile, s'inquiéter de la pression des pneus, faire le plein d'essence,... (comprendre le message).

---

Et bien si, on sait ce qui ne va pas car il y a un voyant par type d'anomalie, huile, ABS, freinage...

Salut,

Citation:

---

Envoyé par sjlouis

De toute façon, je voulais avoir un chemin relatif, ce que ne permet pas cette solution, je vais donc utiliser sys.path et tester que le chemin n'existe pas déjà.

---

Définir une variable d'environnement sous Windows se fait, à la base, via la commande SET et c'est largement documenté..

C'est une solution alternative à sys.path.

Dans les deux cas, çà ne permet pas d'avoir des chemins relatifs.

Citation:

---

Envoyé par sjlouis

Alors je suis allé voir à nouveau ces instructions et après avoir noté il y a quelques temps une instruction pour "import", à savoir "import variables from module", cela fait ce que je voulais faire la première fois, sauf que pour importer ces variables, elles ne doivent pas être dans une fonction du module appelé

---

Je vous ai déjà répondu sur ce point ici.

Citation:

---

Envoyé par sjlouis

Pour subprocess, je n'ai toujours pas compris comment m'en servir et les exemples fournis utilisent des instructions Linux.

---

DIR est une commande Windows qui marche bien pour "tester"... Et c'est aussi une commande Python. Mais subprocess.Popen([sys.executable, "dir"]), c'est lancer python avec dir en argument ce qui ne fonctionne que s'il existe un script Python nommé dir. dans le répertoire par défaut.
D'ailleurs, vous pouvez essayer la commande à faire executer par subprocess à la console pour tester:

Code:

---

1 2	$ py dir C:\py37-64\python.exe: can't open file 'dir': [Errno 2] No such file or directory

---

Pour demander à Python d'executer l'instruction dir passée depuis la ligne de commande, c'est: py -c dir. Vous pourrez constater que çà ne retourne rien.
Par contre:

Code:

---

1 2	$ py -c print('toto') toto

---

affiche bien "toto".
Et si on traduit çà avec subprocess:

Code:

---

1 2 3 4

>>> import subprocess >>> subprocess.Popen("py -c print('toto')" <subprocess.Popen object at 0x00000000026436D8> >>> toto

---

- W

Citation:

---

Envoyé par wiztricks

Définir une variable d'environnement sous Windows se fait, à la base, via la commande SET et c'est largement documenté..

C'est une solution alternative à sys.path.

Dans les deux cas, çà ne permet pas d'avoir des chemins relatifs.

---

La façon de créer la variable n'était pas la plus importante, ma question c'était de savoir où la trouver et si elle existait. Il semblerait qu'elle n'existe pas sous le nom Pythonpath sous Windows.

Citation:

---

Envoyé par wiztricks

Je vous ai déjà répondu sur ce point ici.

---

Ce que je souhaite faire, c'est que dans le module param.py, un traitement affecte des valeurs à plusieurs variables. Des scripts importent ce module pour récupérer ces variables et les utilisent pour effectuer leurs traitements.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

import csv, os, sys   t_chemin = os.path.dirname (os.getcwd()) + "\\"   class ExcelFr (csv.excel): delimiter = ";" lineterminator = "\n"   csv.register_dialect ("excel-fr", ExcelFr())   try : fichParam = open (t_chemin + "Data\\Param.csv","r") except : print ("**** Fichier Param introuvable, traitement annulé.") print (" Fichier recherché : DIP\\Data\\Param.csv") sys.exit()   readerParam = csv.reader (fichParam, "excel-fr")   for enregParam in readerParam : if enregParam [0] == "annee" : t_annee = enregParam [1] elif enregParam [0] == "mois" : t_mois = enregParam [1] elif enregParam [0] == "repertoire reception" : t_repertRecept = t_chemin + t_annee + "\\" + t_mois + "\\" + enregParam [1] + "\\" elif enregParam [0] == "repertoire travail" : t_repertTrav = t_chemin + t_annee + "\\" + t_mois + "\\" + enregParam [1] + "\\" elif enregParam [0] == "repertoire fusion" : t_repertFus = enregParam [1] elif enregParam [0] == "repertoire a traiter" : t_repertTrait = enregParam [1] elif enregParam [0] == "document visible (1/0/ )" : t_paramVisible = enregParam [1]   fichParam.close ()   t_chemin = t_chemin + t_annee + "\\" + t_mois + "\\"

---

Et dans mes différents scripts j'utiliserais les différentes variables t_xxx avec :

Code:

---

1 2	from param import t_annee, t_mois, t_repertRecept, t_repertTrav, t_repertFus, t_repertTrait, t_paramVisible, t_chemin

---

Citation:

---

Envoyé par wiztricks

Par contre:

Code:

---

1 2	$ py -c print('toto') toto

---

affiche bien "toto".
Et si on traduit çà avec subprocess:

Code:

---

1 2 3 4

>>> import subprocess >>> subprocess.Popen("py -c print('toto')" <subprocess.Popen object at 0x00000000026436D8> >>> toto

---

---

Dans mon shell ça n'affiche rien :

Code:

---

1 2 3 4

>>> import subprocess >>> subprocess.Popen("py -c print('toto')") <subprocess.Popen object at 0x024156D0>

---

Par contre je vois une fenêtre Dos s'afficher brièvement à l'écran. Le "toto" s'y affiche peut-être.

Merci.

Citation:

---

Envoyé par sjlouis

La façon de créer la variable n'était pas la plus importante

---

Pourtant, si vous ne la créé pas, elle n'existe pas car comme toutes les variables PYTHONmachin, si elle vous permet de changer ce que fait Python par défaut, elle n'a pas besoin d'être là pour rien.

Citation:

---

Envoyé par sjlouis

Ce que je souhaite faire, c'est que dans le module param.py, un traitement affecte des valeurs à plusieurs variables.

---

Ce n'est possible que si toutes ces variables sont associées au même objet mutable.

Citation:

---

Dans mon shell ça n'affiche rien :

Code:

---

1 2 3 4

>>> import subprocess >>> subprocess.Popen("py -c print('toto')") <subprocess.Popen object at 0x024156D0>

---

---

Par défaut, lorsqu'on lance l'interpréteur Python, on le fait depuis un terminal qui permet de lancer des commandes (DOS si vous êtes sous Windows).
Essayez voir ce qu'affiche:

Code:

---

1 2	>>> import subprocess >>> subprocess.call("py -c print('toto')")

---

- W

Citation:

---

Envoyé par wiztricks

Pourtant, si vous ne la créé pas, elle n'existe pas car comme toutes les variables PYTHONmachin, si elle vous permet de changer ce que fait Python par défaut, elle n'a pas besoin d'être là pour rien.

---

Pourtant d'après la documentation dont avez donné le lien :

https://docs.python.org/fr/3/library/sys.html#sys.path
la définition de sys.path :

Citation:

---

Une liste de chaînes de caractères spécifiant les chemins de recherche des modules, initialisée à partir de la variable d'environnement PYTHONPATH et d'une valeur par défaut dépendante de l'installation.

---

Donc comme sys.path n'est pas vide, il l'a récupéré de Pythonpath à moins que ça ne vienne de la "valeur par défaut dépendante de l'installation".

Citation:

---

Envoyé par wiztricks

Ce n'est possible que si toutes ces variables sont associées au même objet mutable.

---

Vous pouvez être un peu plus explicite car telle quelle je ne sais pas quoi faire de cette info.

Citation:

---

Envoyé par wiztricks

Par défaut, lorsqu'on lance l'interpréteur Python, on le fait depuis un terminal qui permet de lancer des commandes (DOS si vous êtes sous Windows).
Essayez voir ce qu'affiche:

Code:

---

1 2	>>> import subprocess >>> subprocess.call("py -c print('toto')")

---

---

Ok, je n'avais jamais procédé ainsi. Je lance la console depuis un raccourci Windows.

Merci.

Salut,

Citation:

---

Envoyé par sjlouis

Donc comme sys.path n'est pas vide, il l'a récupéré de Pythonpath à moins que ça ne vienne de la "valeur par défaut dépendante de l'installation".

---

Vous pourriez avoir la curiosité de regarder ce que contient sys.path "par défaut", puis recommencer en ayant défini PYTHONPATH.

Citation:

---

Envoyé par sjlouis

Vous pouvez être un peu plus explicite car telle quelle je ne sais pas quoi faire de cette info.

---

Soit je vous ai déjà répondu soit je ne comprends pas la question. C'est le défaut d'une discussion qui va et vient dans tous les sens. Ca serait bien de fermer celle-ci et d'en ouvrir une autre en récapitulant ce que vous voulez faire.

- W

Citation:

---

Envoyé par wiztricks

Vous pourriez avoir la curiosité de regarder ce que contient sys.path "par défaut", puis recommencer en ayant défini PYTHONPATH.

---

Et bien il va ajouter le nouveau path que j'aurais inscrit dans Pythonpath à ce qu'affichait sys.path avant la création de Pythonpath. Mais cela ne répond pas à ma question. D'après les différentes doc, je comprends que sys.path affiche les valeurs d'une variable Python existante, Pythonpath, alors qu'il semblerait que Pythonpath soit une variable que l'utilisateur peut créer pour y ajouter des liens qu'il veut permanents. Dans les différentes doc, je n'ai pas vu que l'utilisateur avait à créer cette variable.

Citation:

---

Envoyé par wiztricks

Soit je vous ai déjà répondu soit je ne comprends pas la question. C'est le défaut d'une discussion qui va et vient dans tous les sens. Ca serait bien de fermer celle-ci et d'en ouvrir une autre en récapitulant ce que vous voulez faire.

---

Si vous voulez mais c'est vous qui m'avez dit d'utiliser des variables associées à un objet mutable quand j'avais écrit que je souhaitais affecter des variables dans un module utilisé par plusieurs scripts (voir le code fourni précédemment) et que je souhaitais que ce code soit dans un paragraphe "propre" comme une fonction. Or je n'arrive pas à faire un import de variables dans une fonction d'un module. Et je ne sais pas comment utiliser votre info pour que ces variables soient importées d'une fonction d'un module.

Voilà :) .

Citation:

---

Envoyé par sjlouis

Dans les différentes doc, je n'ai pas vu que l'utilisateur avait à créer cette variable.

---

Vous partez avec l'hypothèse de retrouver dans sys.path ce qui a été défini dans PYTHONPATH sans la vérifier. Et bloqué la dessus, vous êtes imperméable à une autre logique (comment çà pourrait marcher sinon) et à ce que raconte la documentation.

Intéressant!

Un variable d'environnement reste une variable d'environnement, impossible de la mettre à jour sans la (ré-)créer... Et si une variable n'est utilisée que pour permettre de changer un comportement par défaut (ce qui est le cas de toutes les variables d'environnement Python), pas besoin qu'elle existe de façon permanente.

Et si vous voulez trouver où est mentionné qu'il faut la créer dans la documentation Python, c'est juste dans le tuto. qui vient avec:
Modules standards:

Citation:

---

La variable sys.path est une liste de chaînes qui détermine les chemins de recherche de modules pour l'interpréteur. Elle est initialisée à un chemin par défaut pris de la variable d'environnement PYTHONPATH ou d'une valeur par défaut interne si PYTHONPATH n'est pas définie. sys.path est modifiable en utilisant les opérations habituelles des listes :

---

Citation:

---

Envoyé par sjlouis

...que je souhaitais que ce code soit dans un paragraphe "propre" comme une fonction. Or je n'arrive pas à faire un import de variables dans une fonction d'un module. Et je ne sais pas comment utiliser votre info pour que ces variables soient importées d'une fonction d'un module.

---

La notion de paragraphe propre n'existe pas en Python.
Importer des variables dans une fonction se fait simplement:

Code:

---

1 2 3

def f(): from sys import path print (path)

---

Et importer les variables d'une fonction d'un module n'est pas possible vu ce que sont les fonctions.
Désolé mais pour moi, ce que vous racontez est un charabia que je ne comprends pas.

- W