Propager des options au travers de modules et packages

Bonjour à tous,

Je cherche une manière propre de propager des options de configuration au travers de plusieurs modules et packages. Par exemple des options de debug ou autres qui vont influencer la dynamique du programme.

L'approche que j'utilisait était un module config qui contenant des variables globales. Cette approche marche tant que les options sont "statiques", cela se complique quand on veut les rendre "dynamiques" avec une CLI par exemple : il faut faire un import avant chaque requête à ce module sinon les changements effectués par d'autres modules ne sont pas visibles.

Une solution ?

Merci.

Utiliser shelve ?

Citation:

---

Envoyé par N.tox

Utiliser shelve ?

---

Je trouve assez lourd de devoir utiliser un fichier pour connaitre les options passés à mon programme.

Edit: De plus cette configuration est non persistante.

En fait après un rapide test, des variable mises dans un module importé par d'autres, peuvent être dynamiquement modifiées :
module cmn.py:

Code:

---

ze_var=10

---

module a.py

Code:

---

1 2 3 4 5 6 7

import cmn   def double(): cmn.ze_var *= 2   def print_(): print cmn.ze_var

---

module b.py:

Code:

---

1 2 3 4 5 6 7

import cmn   def quart(): cmn.ze_var /= 4   def print_(): print cmn.ze_var

---

module test.py:

Code:

---

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

import a import b   a.print_() a.double() b.print_() b.quart() a.print_() print 'import' import cmn print cmn.ze_var a.print_() input()

---

l’exécution du script test.py me donne ceci:

Code:

---

1 2 3 4 5 6

10 20 5 import 5 5

---

Cela marche bien, cependant ça ne marche plus quand on a des packages.

Structure du test:

Code:

---

1 2 3 4 5

base/__init__.py base/cmn.py base/test.py base/child/__init__.py base/child/test.py

---

les fichiers __init__.py sont vides.

Le fichier base/cmn.py :

Code:

---

ze_var=10

---

le fichier base/test.py :

Code:

---

1 2 3 4 5 6 7 8

import cmn import child.test as t   cmn.ze_var = 15   print cmn.ze_var t.print_() print cmn.ze_var

---

le fichier base/child/test.py

Code:

---

1 2 3 4

from base import cmn   def print_(): print cmn.ze_var

---

Une fois la variable d'environnement PYTHONPATH mise à jour avec le répertoire courant, l'exécution de python base/test.py produit le résultat suivant:

Code:

---

1 2 3

15 10 15

---

Tu n'as pas besoin d'ajouter le package dans le python path pour que les imports intra-package s'effectuent.
Tiens, tu devrais trouver cela intéressant.
Néanmoins, cela ne résoudra pas ton pb pour autant... utiliser un serveur local ?

Citation:

---

Envoyé par N.tox

Tu n'as pas besoin d'ajouter le package dans le python path pour que les imports intra-package s'effectuent.
Tiens, tu devrais trouver cela intéressant.
Néanmoins, cela ne résoudra pas ton pb pour autant... utiliser un serveur local ?

---

J'évite d'utiliser les imports relatifs, je trouve la notation absolue plus intuitive et plus simple à maintenir. Mais c'est plus une question de gout. Je conçois très bien que cela peut poser problème lorsqu'on décide de déplacer le package...

Revenons à nous moutons, baaaaaaah, pour l'instant j'ai décidé de passer par shelve, comme tu m'as suggéré dans ton premier message. Je trouve ça dommage de passer par un fichier, mais cette approche a le mérite de marcher. Tant que je ne trouve pas mieux je vais utiliser cette solution.

Le topic n'est donc pas clos j'attends toujours des propositions :)

Hmmm... si t'es sous linux, tu peux créer un hardlink de base/cmn.py dans /base/child/
Je n'ai aucune idée de la viabilité de cette proposition

Pour ma part j'utilise des attributs de classe

Code:

---

1 2 3 4

class options: debug= True parametre= 1

---

Mais pour éviter les imports cycliques, je suis la plupart du temps obligé de placer cette classe dans un fichier séparé genre config.py, du coup j'ai les mêmes problèmes que toi.

Cela dit, passer par une classe plutot que par le module lui même permet plus de flexibilité (p.ex: décoration de la classe d'options pour aller chercher les valeurs dans un fichier)

salut,

s'il s'agit de configuration pourquoi ne pas utiliser ConfigParser ? et de rendre l'instance de configuration disponible depuis tous tes modules (via import ou passage explicite en argument)

Citation:

---

Envoyé par kango

salut,

s'il s'agit de configuration pourquoi ne pas utiliser ConfigParser ? et de rendre l'instance de configuration disponible depuis tous tes modules (via import ou passage explicite en argument)

---

J'utilise argparse pour récupérer les arguments, c'est le fait de rendre des données disponibles depuis tous les modules qui est problématique à partir du moment où on a des sous packages (cf. plus haut). Pour ce qui est du passage explicite, c'est ce que je veux éviter à tout prix.

ok, tu as les options de configurations depuis la ligne de commande, je pensais qu'elles venait depuis un fichier.

personnellement, je m'inspirerai de l'approche du module logging de python.

celui contient un logger qui est un singleton que l'on configure du module que l'ont veut, et que l'on appelle du module que l'on veut (en passant par un import logging).

cela revient à utiliser les approches exposées ci dessus mais de partager un objet (aussi simple ou complexe que tu le désires) en lieu et place de variable chaines ou entières.

Avec un singleton le résultat sera le même qu' ici.

Le fait est que lorsqu'on parle de modules tout va bien mais lorsqu'on parle de packages cela se complique...

le cas que tu mentionnes ne fonctionne pas uniquement parce que la variable globale est non mutable (dans ton cas un integer) :)

on peut simuler le comportement indépendamment des modules, packages, etc...

Code:

---

1 2 3 4 5

a = 1 b = a b = 2 print a print b

---

Citation:

---

Envoyé par kango

le cas que tu mentionnes ne fonctionne pas uniquement parce que la variable globale est non mutable (dans ton cas un integer) :)

on peut simuler le comportement indépendamment des modules, packages, etc...

Code:

---

1 2 3 4 5

a = 1 b = a b = 2 print a print b

---

---

Non.

Voici un exemple qui met en évidence le même comportement avec un singleton (sources ici).

Structure du test:

Code:

---

1 2 3 4 5

base/__init__.py base/cmn.py base/test.py base/child/__init__.py base/child/test.py

---

Les fichiers __init__.py sont vides.

Le fichier base/cmn.py :

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

class ConfigMgr(object): __instance__ = None   def __init__(self): self.__class__.__instance__ = self self.d = {}       @classmethod def instance(cls): if not cls.__instance__: ConfigMgr() assert(cls.__instance__) return cls.__instance__   def set(**kwargs): instance = ConfigMgr.instance() for (name, value) in kwargs.iteritems(): instance.d[name] = value print " dictionnaire apres set : ", ConfigMgr.instance().d   def get(name): instance = ConfigMgr.instance() print " dictionnaire juste avant get : ", ConfigMgr.instance().d return instance.d[name]

---

Le fichier base/test.py :

Code:

---

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

import cmn import child.test as t   cmn.set(truc='blabla') print print cmn.get('truc'), ' (dans base.test)' print try: t.print_() except KeyError as ke: print "KeyError: ", ke print print cmn.get('truc'), ' (dans base.test)' print

---

Le fichier base/child/test.py

Code:

---

1 2 3 4 5

from base import cmn   def print_(): print 'base.child.test.print_' print cmn.get('truc')

---

Sortie sur la console lorsqu'on exécute base/test.py:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

dictionnaire apres set : {'truc': 'blabla'}   dictionnaire juste avant get : {'truc': 'blabla'} blabla (dans base.test)   base.child.test.print_ dictionnaire juste avant get : {} KeyError: 'truc'   dictionnaire juste avant get : {'truc': 'blabla'} blabla (dans base.test)

---

salut,

j'ai récupéré ton code source. j'ai exécuté les commandes suivantes (en interactif).

(j'ai juste ajouté un id pour vérifier que l'on a la même instance à chaque fois et c'est le cas)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

>>> import base >>> import base.test dictionnaire apres set : {'truc': 'blabla'} id : 140602658422224   dictionnaire juste avant get : {'truc': 'blabla'} id : 140602658422224 blabla (dans base.test)   base.child.test.print_ dictionnaire juste avant get : {'truc': 'blabla'} id : 140602658422224 blabla   dictionnaire juste avant get : {'truc': 'blabla'} id : 140602658422224 blabla (dans base.test)

---

du coup, c'est le comportement que tu souhaites il me semble non ?

tu dois probablement lancer le script base/test.py sans avoir importer base. (ce qui chez moi crash car base/child/test.py me retourne un import error du module base à moins que je configure PYTHONPATH de sorte que le module base soit trouvé et dans ce cas j'ai la même exception:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

python base/test.py id cnm: 139737530170008 dictionnaire apres set : {'truc': 'blabla'} id : 139737530145680   dictionnaire juste avant get : {'truc': 'blabla'} id : 139737530145680 blabla (dans base.test)   base.child.test.print_ id cnm: 139737530170848 dictionnaire juste avant get : {} id : 139737530146320 KeyError: 'truc'   dictionnaire juste avant get : {'truc': 'blabla'} id : 139737530145680 blabla (dans base.test)

---

mais du coup, comme tu peux le voir, tu as deux instances de ConfigMgr :)

cela est dû au fait que le module cnm est importé deux fois (voir le id du module cmn):

- une fois par l'intermédiaire de base/test.py qui a cnm.py dans le même répertoire
- uen fois par base/child/test.py qui importe cnm via base et la variable PYTHONPATH.

du coup ton Singleton n'en n'est plus un :) mais c'est lié au fait que le module n'est pas un Singleton non plus.

exécuter un script depuis l'intérieur d'un package sans avoir importer le package racine peut conduire à des problèmes. Mais celui là, je l'avais jamais vu ;p

le problème initial est bien lié à la nature immuable des variables globales utilisées et ce dernier problème est lié au fait que tu as deux instances de configuration différentes à cause du soucis d'import.

Comment peut-on créer un module ou package qui soit un singleton ? (ou un Borg).

un module est un singleton. le cas de ce post est quand même très particulier :)

Donc faire un import base avant chaque import base.cmn résoudrait mon problème ?

pas tout à fait. en fait, il vaut mieux selon moi ne pas lancer un script directement depuis l’intérieur d'un package python (on perd les imports relatifs).

c'est une constatation personnelle donc très certainement pas universelle. je construis toujours les scripts au même niveau que le package racine.

par exemple:

Code:

---

1 2 3 4

ton_script_1.py ton_script_2.py base `---- __init__.py

---

chaque script faisant un:

Code:

---

import base

---

ou

Code:

---

from base import ...

---

Ok, dans mon cas je pensais faire un __main__.py dans base afin de proposer une CLI basique pour mon package. Mais du coup j'aurais toujours ce problème.