lancer une fonction quand on n'a que son emplacement sur le disque

bonjour,

je construit sur une base Mysql et python un applicatif.

Comme je ne veut pas écrire tout les enchainement en dur des fonctions pour avoir une souplesse d'évolution. Je souhaite avoir un système plus automatique de lancement de calcul.

pour synthétiser la situation :
en résumé j'ai un père, des enfants et des liens.
un enfant peut avoir plusieurs pères.

quand je modifie une valeur (qui a un type) chez un enfant, je prends le(s) lien(s) vers son(ses) père(s) et je vérifie s'il y à des fonctions attachées au père qui utilise ce type de données.

la c'est facile car je fait des vérifications dans des bases.
je fait la liste des pointeurs me donnant la position sur le disque des fonctions utilisatrices de cette valeur .

j'ai créé une table à quatre entrées :
- un Identifiant du père
- des DE
- un pointeur qui me donne accès à un lieu de stockage sur le disque et
- un nom de fonction python à utiliser
et tous cela bouge à chaque fois que je rentre une perturbation dans le système

mon problème est de lancer la fonction automatiquement !

merci d'avance

Salut
peut être en utilisant la mécanique d'import dynamique decrite dans ce post récent.
- W

bonjour,

En fait j’ai dû mal exprimer mon Pb

J’ai des tables
Table 1 : IdObjet – NomObjet – IdTypeObjet – DateStart – histoObjetavant – HistoObjetaprès – DateEnd
Table 2 : IdFonction – NomFonction – typeDEntrée – TypeDSortie
Table 3 : IdObjet – IdFonction
Table 4 : IdObjetAvant – IdObjetAprès
Table 5 : IdEnregistrement - IdObjet – IdTypeValeur – Valeur


Table 1 : j'associe des caractéristiques
Table 2 : Les fonctions ont été compilées par ailleurs dans des « class » diverses. Je fait le lien entre un nom de fonction compilée et les type en entrée et en sortie
Table 3 : Je spécifie quelle fonction sont utilisable par l'objet
Table 4 : je spécifie le sens de propagation entre objet
Table 5 : je spécifie l'élément originel de la perturbation

Un enregistrement se fait au travers d’un formulaire. De ce fait le type valeur est connu. Je veux donc propager la perturbation (conséquences en cascade du nouvel enregistrement).

J’ai créé une boucle qui à un moment me sort un couple (IdFonction ; DonnéesEntrée).
Ce couple varie à chaque perturbation et varie lors de l’avancement dans la cascade.

Je souhaite alors exécuter ValSortie = Fonction(DonnéeEntrée)

C’est ce qui me bloque.

merci d'avance

Bonjour,

je pense que l'idée de tout mettre en base est contre productive.

le probleme peut être a mon avis résolu avec une architecture plus sophistiquée. en l'occurence je pense qu'il faudrait utiliser une interface que une ou plusieurs classes abstraites desquelles les classes finales pourront hériter.

Salut,
Je ne sais pas trop comment vous posez le problème mais c'est il s'agit de mettre en correspondance les identifiants récupérés dans la BDD avec des objets Python de type "function".
Un objet fonction sera cree lorsque l'interpreteur rencontre une instruction "def", exemple:

Code:

---

1 2	def function(*args, **kwds): pass

---

fabrique l'objet "fonction" et cree une référence a cet objet via la creation d'une entree dans le dictionnaire parent. Si c'est un module, ce sera globals().
L'utilisateur (programmeur en l'occurence) pourra utiliser cet objet, i.e l'appeler avec les paramètres requis - le minimum pour ce type d'objet - en écrivant:

Code:

---

function(1, 2, 3)

---

Mais, il aura pu le faire "indirectement", en désignant l'objet via le nom de sa clef dans le dict globals():

Code:

---

globals()["fonction"](1, 2, 3)

---

Ça fait la même chose: appel de l'objet "function" avec les paramètres (1, 2, 3) mais l'objet n'est plus accède via la /variable/ nommée "function" mais via une chaîne de caractère - un /str/ - qui pourrait être construit en fonction des identifiants récupérés en base.
Plus généralement ça s'appelle "introspection". C'est une mécanique qui ne fonctionne qu'avec le support de "métadonnées".

En Python, c'est assez simple: les objets sont crées dans une arborescence hiérarchique de "dict". Leurs /clefs/ sont le nom des /variables/ et leur /valeur/ l'objet associe. Les fonctions/méthodes getattr, setattr,... les modules comme importlib et inspect supportent la mécanique d'introspection.
Il y a la possibilité d'avoir des alias:

Code:

---

1 2	toto=function toto(1, 2, 3)

---

Ca ne fait qu'ajouter une entree dans globals() avec une référence supplémentaire a l'objet "fonction"
ou des soft-links:

Code:

---

import m1.m2.m3 as module

---

(importlib accepte les chaînes de caractères)

Citation:

---

Envoyé par utopman

je pense que l'idée de tout mettre en base est contre productive.

---

Ce qui n'est pas en base doit etre (re)construit lors de toute activation du "programme" via la commande python "monscript.py".
L’arborescence des modules, un fichier de configuration, l’état de la session utilisateur, les enregistrements des commandes passes par les clients,...
Tout est dans différentes bases.

La gestion de ces informations est déjà "codifiée". L’intérêt d'un langage de programmation est de proposer des solutions a des questions auxquelles il serait sinon nécessaire de bâtir une solution /ad hoc/.
En matière de "calling-standard" ce ad hoc limite l’interopérabilité et coûte de devoir être refait a chaque fois.

Si on traite un problème "semblable", dommage d'ignorer ce qui est déjà fait voire utilisable directement ou avec quelques adaptations.

Ce que je trouve dommage dans le "design" propose dans ce post n'est pas le "tout en base" c'est que la question soit posée dans un forum Python!

Si je codais ce genre de truc en Python, je commencerais par définir les informations a récupérer et écrire en base. Mais je ne me poserai pas trop de questions cote base mais plutôt a ce qu'on devra pouvoir faire de ces informations.

In fine, les enregistrements de la base devront se traduire par une hiérarchie de classes. Les instances pourraient etre definies dans le script pour pouvoir "tester".

Dans le cas particulier, les identifiants seraient "strings", ou liste de... ou peut être du code a charger de façon dynamique.
Si on n'oublie pas que tout cela devra être échange avec la base - pour ne pas faire n'importe quoi - utiliser ces informations a partir d'un code Python passe par cette hiérarchie de classe. Les attributs des objets sont des "objets" Python d'un certain type.

Comment trouver le module/fonction a partir de la... est une question Python, comment associer cette hiérarchie aux tables de la BDD c'est le boulot de la DBAPI ou mieux de SQLAlchemy,... et le design de la persistance pour "aligner" objets et tables, c'est un cote SGDB qui n'a rien a voir avec Python.

Si on ne fait pas la part des choses, on se retrouve a mélanger différents niveaux d'abstraction (il n'est pas interdit de créer de nouveaux concepts) et dans l’incapacité de trouver les points d'association entre ces différents niveaux - en francais, on est paume -.

Bon, je retourne bosser.
- W