Import variable globale

Bonjour,

Est ce que vous savez s'il est possible dans un fichier python de regrouper toutes les variables globales que l'on utilise et ensuite faire un import de ce fichier ?

Juste histoire de ne pas faire des copier coller de ces variables globales dans tous les fichier *.py

Merci pour votre aide

Thais

Bonjour.

Avez-vous pensé aux variables d'environnement ?

Exemple de fichier .env :

Code:

---

1 2 3

var1=valeur var2=valeur va3=valeur

---

Sous Windows, la librairie python-dotenv sera à installer mais si vous êtes sous Linux/Unix, normalement pas besoin.

Et une p'tite classe Config par exemple, qui se charge d'instancier toutes ces variables :

Code:

---

1 2 3 4 5 6 7 8 9 10

from os import getenv from dotenv import load_dotenv # si Windows   load_dotenv() # si Windows   class Config: def __init__(self) -> None: self.var1 = getenv('var1', default='valeur par defaut') self.var2 = getenv('var2', default='valeur par defaut') self.var3 = getenv('var3', default='valeur par defaut')

---

Bien sûr, c'est un exemple parmi tant d'autres.

Salut,

Citation:

---

Envoyé par thais781

Est ce que vous savez s'il est possible dans un fichier python de regrouper toutes les variables globales que l'on utilise et ensuite faire un import de ce fichier ?

---

Techniquement, on pourrait le faire en ajoutant une instruction du genre INCLUDE: on ajoute du texte avant d'exécuter le module.

Mais il serait plus simple de fabriquer de vraies variables globales en utilisant la technique décrite dans la FAQ Python.

Ceci dit, les variables globales demandent des précautions pour être utilisées à défaut, c'est prendre le risque de passer (et perdre) beaucoup de temps pour la mise au point du programme.


- W

Bonjour

Citation:

---

Envoyé par thais781

Juste histoire de ne pas faire des copier coller de ces variables globales dans tous les fichier *.py

---

Si tu utilises les globales pour transmettre une info entre X et Y c'est mal. Si tu utilises des globales juste pour gérer une espèce de config alors ok. Mais dans ce cas, pas besoin de globales.
Dans mes projets j'ai deux type d'objet

• un objet "cEnv" qui contient l'environnement du projet (nom de l'application, nom de la bdd, etc etc etc)
• un objet "cConfig" qui contient la configuration du projet (paramètres, distance, nb de jour avant fin de X, etc)

L'objet "cEnv" est statique. L'objet "cConfig" charge un fichier ".ini" via la lib configparser.
Et dans mon programme, me suffit d'importer les sources contenant ces deux objets pour avoir accès à leurs attributs. Ce qui évite de devoir se coltiner des globales

bonjour

Citation:

---

Envoyé par thais781

Juste histoire de ne pas faire des copier coller de ces variables globales dans tous les fichier *.py

---

Du travail de refactoring ! très très bien

Mais comme dit plus haut, il faut surtout qu'il soit bien fait... sinon autant ne rien faire :mouarf:

Tu sembles ici, simplement vouloir gagner du temps. Donc écrire ton propre script va-t-il t'en faire gagner ? je ne pense pas ou bien ton projet est très complexe ?

Sinon, tu peux parcourir tous tes .py, avec une regex du type ligne qui débute par <MOT> suivit de '=' avec éventuellement un ou des espaces.
Tu sauvegardes ces "globales" dans une liste, puis tu crées un fichier init (ou fichier config.py) où tu les écris.

note:
Et si tu n'as pas respecté PEP 8 :roll: alors un linter type pylint peut retrouvé tes "variables globales"

Citation:

---

Envoyé par pylint;

(fichier)(ligne) C0103: Constant name "xxx" doesn't conform to UPPER_CASE naming style

---

Citation:

---

Envoyé par papajoker

Sinon, tu peux parcourir tous tes .py, avec une regex du type ligne qui débute par <MOT> suivit de '=' avec éventuellement un ou des espaces.
Tu sauvegardes ces "globales" dans une liste, puis tu crées un fichier init (ou fichier config.py) où tu les écris.

---

Ou tu passes par configparser qui fait tout ça tout seul (et qui gère aussi la notion de "chapitre" dans le fichier) :P

Nous sommes tout à fait d'accord

Citation:

---

Envoyé par papajoker

il faut surtout qu'il soit bien fait... sinon autant ne rien faire :mouarf:

---

Je n'ai répondu qu'à la question "j'ai la flemme de faire des copier/coller". Une fois les variables/constantes regroupées, commence le véritable travail de refactoring.

Bonjour

Vouloir conserver des données modifiées d'une session à l'autre est un problème général. Pour ça, j'utilise les fichiers "ini" (module Python "configparser"):

A l'installation du programme, il doit y avoir un fichier .ini avec le programme installé qui donne les données initialisées (une sorte de "configuration usine").

Si les données à conserver d'une session à l'autre sont spécifiques à l'un des utilisateurs, le fichier ini devra se trouver dans son "home". Sinon, dans le home "public". Trouver le home de l'utilisateur sans connaître son nom est facile, tant sous Windows que sous Linux:

Code:

---

rephome = os.path.expanduser('~')

---

Au lancement du programme, celui-ci commence par chercher le programme ini dans le "home" (le répertoire) de l'utilisateur. Si le fichier ini s'y trouve, on le charge.

Si le fichier ini ne se trouve pas dans le répertoire utilisateur, c'est que c'est la 1ère exécution. On charge donc les données d'initialisation.

Le programme se déroule, et certaines données sont modifiées.

A la fermeture du programme, les données modifiées sont placées dans le dictionnaire ordonné, et celui-ci est enregistré dans le fichier ini du home de l'utilisateur.

Pour le code, voilà ce que j'ai fait. On met ce code dans un fichier (que j'appelle "bibini.py") qu'il suffira d'importer dans tous les programmes qui l'utilisera:

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

# -*- coding: utf-8 -*-   """ Charge et sauve le contenu d'un fichier de type .ini sous la forme d'un dictionnaire de dictionnaires (OrderedDict) en mémoire """   from configparser import ConfigParser from collections import OrderedDict   ############################################################################# def chargini(ficini, encodage="utf-8"): """Charge le contenu du fichier ficini (type .ini) avec l'encodage donné        Retourne le dictionnaire de dictionnaires (OrderedDict) des données     """ cfg = ConfigParser(interpolation=None) with open(ficini, 'r', encoding=encodage) as fsrce: cfg.read_file(fsrce) dicini = OrderedDict() for section in cfg.sections(): dicini[section] = OrderedDict() for option, valeur in cfg.items(section): dicini[section][option] = valeur return dicini   ############################################################################# def sauvini(dicini, ficini, encodage="utf-8"): """Sauve le dictionnaire de dictionnaires (OrderedDict) dicini dans le        fichier ficini avec l'encodage donné     """ cfg = ConfigParser(interpolation=None) cfg.read_dict(dicini, source='<OrderedDict>') with open(ficini, 'w', encoding=encodage) as fdest: cfg.write(fdest)

---

J'utilise un dictionnaire ordonné, afin que les données du fichier ini soit toujours dans le même ordre.

la fonction chargini charge le contenu du fichier ini donné "ficini", et retourne un dictionnaire ordonné "dicini".

La fonction sauvini enregistre le dictionnaire ordonné "dicini" dans le fichier "ficini".

L'avantage supplémentaire de cette solution est que l'on peut consulter le fichier ini avec un simple éditeur de texte (avec le bon encodage, "utf-8" ici) et, si nécessaire, le modifier en dehors d'une session du programme.

Bonjour à tous,

Merci beaucoup pour votre aide.
Le but est juste de factoriser des infos sur les PATH que j'utilise et de ne devoir les modifier qu'a un seul endroit si besoin

La solution de Sve@r me semble la plus adapté à ma problématique en mode complètement statique
Tu peux me donner un exemple de ton fichier 'cEnv' et comment tu l'appel/charge dans tes autres fichiers ??

Encore merci pour ces réponses de très haut niveau ;-)

Thais

pour ta fonction chargini(),
je vais préférer passer des valeurs "usine" par défaut (injecter). Et ne pas utiliser open() mais read() si le fichier n'existe pas encore

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

def chargini(ficini, defaults=None, encodage="utf-8"): cfg = configparser.ConfigParser(interpolation=None) if defaults: cfg.read_dict(defaults) cfg.read(ficini, encoding=encodage) ret = {} for section in cfg.sections(): for key, value in cfg[section].items(): ret.setdefault(section, {})[key] = value return ret   ini = chargini("truc.ini", {'dev': {'debug': 0}})

---

Citation:

---

Envoyé par thais781

Bonjour à tous,
ma problématique en mode complètement statique
Tu peux me donner un exemple de ton fichier 'cEnv' et comment tu l'appel/charge dans tes autres fichiers ??

---

ici, on parles donc de constantes !
?? c'est ce que tu fais déjà ? si tu as déjà quelques fichiers.

Un fichier est un objet (en python), il te suffit d'y mettre tes constantes (ce que je te disais)

Code:

---

1 2 3 4 5 6

#fichier config.py VAR_ONE = 1   # autre fichier import config print(config.VAR_ONE)

---

Parfois, on peut créer une classe "statique" dans ce fichier, mais ce n'est pas une solution pythonnesque, en particulier pour des constantes et cela n'apporte rien de plus (sauf créer X classes si tu as X types de constantes).

Code:

---

1 2 3 4 5 6 7 8

# constantes.py class Config: VAR_ONE = 1 VAR_TWO = 2   # autre fichier from constantes import Config print(Config.VAR_ONE)

---

Citation:

---

Envoyé par papajoker

pour ta fonction chargini(),
je vais préférer passer des valeurs "usine" par défaut (injecter) et ne pas utiliser open() si le fichier n'existe pas encore

---

Dans ce que je fais, le test d'existence du fichier est fait avant avec os.access(...).

Genial,

Merci pour votre aide, ca me va impec.

Pour ne pas mettre ce fichier 'constantes.py' au meme niveau que les autres fichiers, j'utilise la méthode suivante.

Code:

---

1 2 3 4

import sys sys.path.insert(0, '/Users/.........') from constantes import Config

---

Mais ca me met toujours une erreur/warning dans jupyter :

Code:

---

1 2	Import "Config" could not be resolved

---

Avez-vous une autre méthode pour faire cela ? ou permettant de resoudre ce warning ?

Citation:

---

Envoyé par thais781

Pour ne pas mettre ce fichier 'constantes.py' au meme niveau que les autres fichiers, j'utilise la méthode suivante.
Mais ca me met toujours une erreur/warning dans jupyter : Import "Config" could not be resolved...

Avez-vous une autre méthode pour faire cela ? ou permettant de resoudre ce warning ?

---

Est-ce que le fichier "constantes.py" contient une fonction ou classe "Config" ? Parce que c'est ce que tu demandes quand tu écris from constantes import Config.

Et je ne sais pas trop où tu le mets mais tu le mettrais dans un sous-dossier du script principal tu n'aurais pas besoin de ce sys.path.insert(0, '/Users/.........') qui n'est pas des plus rassurants.

? quel niveau ?
Normalement, on va juste créer un sous-dossier (au projet racine du projet) et y mettre ce fichier
reste à indiquer ce sous-dossier à l'import
from constantes import Config si fonctionnait avant déplacement du fichier dans le sous-dossier "rangement", devient :
from rangement.constantes import Config

Ma structure du projet est celle-ci :

Projet
-----Module 1
----------Lot A
---------------fichier.py
-----Module 2
-----Environnement
----------constantes.py

Et c'est dans fichier.py que je doit faire mon import constantes :roll:

projet est donc aussi un "module" ? il le faut... (pour justement trouver la racine du projet)

# dans fichier.py
from ...environnement.constantes import Config
#ou la forme classique
from projet.environnement.constantes import Config

Code:

---

1 2 3 4 5 6 7 8 9

main.py projet -----Module 1 ----------Lot A ---------------fichier.py -----Module 2 -----environnement ----------constantes.py

---

un module normalement devrait être indépendant, avec ta structure Module{1,2,...} ne le sont pas :( on va dire que ce ne sont pas de véritables modules, mais plus un "rangement" et que le seul véritable module python est "projet"

Citation:

---

Envoyé par thais781

Ma structure du projet est celle-ci :

Projet
-----Module 1
----------Lot A
---------------fichier.py
-----Module 2
-----Environnement
----------constantes.py

Et c'est dans fichier.py que je doit faire mon import constantes :roll:

---

Essayez de visualiser ce qui structure un projet Python avant de découper votre projet... sinon, vous allez avoir de mauvaise surprises. A noter que c'est un sujet complètement différent de la question initiale.

- W

Citation:

---

Envoyé par thais781

Et c'est dans fichier.py que je doit faire mon import constantes :roll:

---

Ben t'as raison de faire le blasé. Tu organises ton projet n'importe comment et après tu t'étonnes que ça ne fonctionne pas :roll:
Cela ne peut fonctionner que si ton projet est organisé de cette façon...

Code:

---

1 2 3 4 5 6 7 8

Projet -----script_de_base.py -----Module 1 ----------Lot A ---------------fichier.py -----Module 2 -----Environnement ----------constantes.py

---

... et que tu lances ton projet en appelant le script "script_de_base.py". De là, depuis n'importe quel script ou sous-script, tu pourras appeler from Environnement import constantes.py. Parce que le chemin des imports est vu depuis l'emplacement du script exécuté.

Merci pour vos conseils, j'ai bien un fichier main.py tout en haut de ma structure, mais je voulais tester individuellement mes fichiers .py en y accédant directement .... je vais modifier tout cela ;-)

Pour revenir a la question initiale, petite question subsidiaire, est ce que l'on peut faire la même chose (un fichier/classe avec les constantes) avec les différents import ?

Code:

---

1 2 3 4 5

import requests import pandas as pd from bs4 import BeautifulSoup import re

---

Citation:

---

Envoyé par thais781

Merci pour vos conseils, j'ai bien un fichier main.py tout en haut de ma structure, mais je voulais tester individuellement mes fichiers .py en y accédant directement ....

---

Alors dans ton fichier (imaginons que tu veuilles tester "fichier.py" qui doit importer "constantes.py"), tu le testes de cette façon
fichier.py

Code:

---

1 2 3 4 5 6 7 8 9

if __name__ == "__main__": import sys sys.path.append("../..")   from Environnement import constantes.py ... (suite du programme)...   if __name__ == "__main__": ... (code de test)...

---

Ainsi la modification de sys.path n'est faite que lors du test et pas lors de l'utilisation normale.

Citation:

---

Envoyé par thais781

Pour revenir a la question initiale, petite question subsidiaire, est ce que l'on peut faire la même chose (un fichier/classe avec les constantes) avec les différents import ?

Code:

---

1 2 3 4

import requests import pandas as pd from bs4 import BeautifulSoup import re

---

---

Tu les places dans un fichier "__init__.py" à la racine d'un dossier "XXX" (exemple "Environnement"). Ensuite, chaque fois que tu feras from Environnement import * ça appellera le __init__.py et exécutera tous ses imports

Citation:

---

Envoyé par thais781

Le but est juste de factoriser des infos sur les PATH

---

Le shéma (mot faible) que tu montres n'a rien d'exceptionnel, par exemple avec django il est plus que classique d'avoir une arborescence de ton type avec 3 niveaux.

MAIS

que le fichier de dernier niveau ait besoin de constantes "path" n'est pas du tout normal ! Normalement les fonctions(classes) de haut niveau sont justement au début et, au 3éme niveau on ne trouve que des fonctions(classes) de très bas niveau. Seules les fonctions de haut niveau ont besoin d'un environnement de travail.

Haut niveau exemple : Application.sauvegarder()
Bas niveau exemple : multiplier_facteur_x(x,y) , assainir_titre(), filtrer_dataframe(filtre_fonction, colonne), download_url() Et justement le travail sur panda est regroupé, le travail sur le web est regroupé, le travail sur ... Puisque tu les regroupes, tu peux parfois créer des classes "haut niveau" pour ces tâches (cela dépend beaucoup de ton app, donc pas forcément vrai)

-------
Et vouloir regrouper tes 4 librairies ... me fait penser que c'est (encore) une mauvaise chose puisque ce ne sont pas des librairies qui font les mêmes choses et devraient justement ne pas êtres toutes utiles dans les fichiers de bas niveau.

Quel talent, ca marche nickel, merci beaucoup.

Tu ne saurai pas comment enlever les warning de jupyter en utilisant cette solution ?

Je n'ai donc plus dans mon début de fichier python que :

Code:

---

1 2 3 4 5 6 7

#!/usr/bin/env python # coding: utf-8   import sys sys.path.append("../../Config/") from ___init___ import *

---

Mais dans Jupyter, il ne retrouve pas les lien :

Code:

---

1 2 3

Import "___init___" could not be resolved "pd" is not defined pylance(reportUndefinedVariable)

---

Par contre le code fonctionne bien ...

Pardon "Visual Studio Code" au lieu de "Jupyter"

Citation:

---

Envoyé par thais781

Code:

---

from ___init___ import *

---

---

BRAVO, tu as fait exactement ce que Sve@r te demandait de faire :ptdr:

J'ai l'impression que sur ces trois lignes de code il y en a trois qui sont inutiles et même nuisibles.