Appeller une fonction avec un string

Bonjour à tous !

J'essaye de comprendre comment appeller une fonction seulement à partir de son nom (stocké dans un string), et mes recherhes mènent toutes au même genre de réponse, à savoir utiliser getaddr. Cela donne généralement :

result = getattr(foo, 'bar')()

Avc bar = nom de la fonction. Le problème, c'est que je ne vois pas du tout ce qu'est censé être foo ! Les définitions de getattr me parlent d'un "objet" ou d'un "module" mais cela ne correspond à rien dans mon programme... Est-ce une erreur de conception de ma part ou de compréhension de ce getattr ? Merci d'avance de m'éclairer un peu...

Citation:

---

J'essaye de comprendre comment appeller une fonction seulement à partir de son nom (stocké dans un string)

---

Edit : Pourquoi dans un string?

Code:

---

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

>>> def add(a, b): return a+b   >>> def sub(a, b): return a-b   >>> my_func = [add, sub] >>> for func in my_func: print(func(3, 5))     8 -2

---

getattr(objet, 'data') il permet de donner l'attribut data de l'objet.

Code:

---

1 2 3 4 5 6 7

>>> class A: pass   >>> a = A() >>> a.data = 6 >>> getattr(a, 'data') 6

---

si mes souvenirs sont bon, la fonction

Code:

---

exec

---

devrait pouvoir faire l'affaire

Code:

---

1 2 3 4 5 6 7 8 9 10 11

def f1(): print 'ok'   s1 = "f" s2 = "1"   s3 = s1 + s2 + "()"   exec(s3)

---

Voilou ;)

Getattr est bon si on connait l'objet dans lequel chercher la méthode ou l'attribut de cet objet.

Exemple :

Code:

---

1 2 3 4 5 6 7 8

class A: def myMethod(self, a, b): print "argument 1 : "+a+", argument 2 : "+b   if __name__ == "__main__": obA = A() func = getattr(obA, "myMethod") func("chose", "truc")

---

L'exécution donne:

Code:

---

argument 1 : chose, argument 2 : truc

---

Si tu veux plus d'aide, détaille un peu plus ta demande.
Bon code!

Salut,

Citation:

---

Envoyé par Thibqult

Avec bar = nom de la fonction. Le problème, c'est que je ne vois pas du tout ce qu'est censé être foo ! Les définitions de getattr me parlent d'un "objet" ou d'un "module" mais cela ne correspond à rien dans mon programme...

---

Python crée cela pour vous...

Pensez getattr comme une fonction recherchant la définition d'un nom dans un espace (de noms "plat"). Avec Python tout est "objet" et tous les objets appartiennent à un "module". Un module pourrait être considéré comme un objet particulier mais...

Exemple:
>>> int.__module__
'__builtin__'

** but ** le string '__builtin__' n'est pas le module qui se récupère via:
>>> module = sys.modules['__builtin__']
>>> x = getattr(module, 'int')
>>> x
<type 'int'>

Citation:

---

Est-ce une erreur de conception de ma part ou de compréhension de ce getattr ? Merci d'avance de m'éclairer un peu...

---

Pas facile de concevoir proprement lorsqu'on ne comprend pas... Donc je dirais les deux mon capitaine, mais prenez le temps d'apprendre et çà ira bien.

- W

Et passer par globals(), à partir du moment où la fonction est dans le script lui-même ou a été importée nommément ?

dans plus.py :

Code:

---

1 2	def plus(a,b): return a+b

---

script.py :

Code:

---

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

import sys   from plus import plus   def moins(a,b): return a-b   def calcule(operation,entier_1,entier_2): function = globals()[operation] return function(entier_1,entier_2)   if __name__ == '__main__': print calcule(sys.argv[1],int(sys.argv[2]),int(sys.argv[3]))

---

à l'usage :

Code:

---

1 2 3 4

$> python script.py plus 4 5 9 $> python script.py moins 4 5 -1

---

@Pymento

La fonction exec n'est surtout pas une bonne chose en python, on l'utilise vraiment que lorsqu'elle est indispensable car c'est une fonction source de bugs, de manque de contrôle de son programme, de destruction des performances, etc...

Martelli lui même en parle de cette façon

Citation:

---

Use exec only when it's really indispensable

---

Hors dans ce cas, ça ne l'est pas.

Bonjour, tu peux exécuter une chaîne de caractère avec la fonction eval comme il suit

Code:

---

eval('1 + 2')

---

je ne sais pas exactement ce que tu peux faire de plus avec
sinon, autre solution :
tu ecris ton code dans un fichier et tu l'importes ensuite genre

Code:

---

1 2 3 4

c = open('toto.py') c.write(moncode) c.close() from toto import *

---

Je comprends qu'à la vue d'un string certains puissent perdre leur sang froid mais la question initiale portait sur getattr et non sur comment écrire un "interpréteur" de commandes ingérable.
- W
PS: Si tel était le cas, les modules cmd et shlex sont à regarder.

Citation:

---

Bonjour, tu peux exécuter une chaîne de caractère avec la fonction eval comme il suit

---

Il y a le module ast, qui est plus safe que la fonction builtin eval().

Code:

---

1 2 3

>>> import ast >>> ast.literal_eval('2+1') 3

---

Citation:

---

Je comprends qu'à la vue d'un string certains puissent perdre leur sang froid mais la question initiale portait sur getattr

---

Dans ce cas je n'utiliserais pas getattr mais cette solution

Code:

---

1 2 3 4 5

>>> def test(a): return a   >>> print(globals()['test'](5)) 5

---

Edit : Je crois avoir été grilled par plxpy :mouarf:

Citation:

---

mais la question initiale portait sur getattr

---

Non. Getattr est ce qu'avait trouvé Thibqult pour tenter de résoudre son problème qui était initialement de :

Citation:

---

comment appeller une fonction seulement à partir de son nom (stocké dans un string)

---

Citation:

---

comment écrire un "interpréteur" de commandes ingérable

---

L'exemple choisi n'avait pour but que de montrer que ça fonctionnait, rien d'autre. Je ne sais pas ce que Thibqult souhaite faire.

Bonjour,

Petit complément: il est quelquefois intéressant de conserver la relation nomdefonction <=> fonction avec un dictionnaire:

Code:

---

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

def plus(x, y): return x+y   def moins(x, y): return x-y   Op = {"plus": plus, "moins": moins}   print Op["plus"](5,4) 9 print Op["moins"](5,4) 1

---

Ça permet de simuler un "case of" inexistant sous Python

@wiztricks: Par contre, vraiment sans polémiquer et en dehors du côté "interpréteur de commandes ingérable", j'aimerais bien que tu me/nous donnes des conseils sur l'utilisation de globals() pour ce genre de problème. Est-ce propre ? A quels problèmes on s'expose en procédant de la sorte , etc ...

Salut,

Citation:

---

Envoyé par plxpy

Par contre, vraiment sans polémiquer et en dehors du côté "interpréteur de commandes ingérable", j'aimerais bien que tu me/nous donnes des conseils sur l'utilisation de globals() pour ce genre de problème. Est-ce propre ? A quels problèmes on s'expose en procédant de la sorte , etc ...

---

globals() permettra de récupérer la définition de symboles dans le module courant. getattr sera plus générique. Le côté "fonctionnel" s'arrête là.

Le fait est que si on se pose la question, c'est qu'on a récupéré des chaînes de caractère d'on ne sait où et qu'on a peut être envie de "contrôler" plus précisément la liste des symboles qu'on se proposera de...

Ce qui n'a rien à voir avec le côté "fonctionnel" mais a plutôt trait à la sécurité ou à l'affichage de message d'erreurs circonstanciés.

Une réponse est ce que propose Tyrtamos: les symboles à traduire sont stockés dans un dict.
Ce pas là franchit, plus besoin de passer par "globals"!

Mais on pourrait très bien emballer les fonctions dans une classe et se servir de la boîte "classe" ou "instance" (et getattr) plutôt que d'un dict simple.

Cela pourrait donner une chose de la forme:

Code:

---

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

class A:     @classmethod def _plus(cls, x, y): return x+y       @classmethod def _moins(cls, x, y): return x-y       @classmethod def call(cls, name, *args, **kwds): name = '_' + name if hasattr(cls, name): return getattr(cls, name)(*args, **kwds)   print A.call('plus', 1, 2) print A.call('moins', 1, 2)

---

Ce qui est un peu "over-engineered" pour ce cas particulier.
- W

@wiztricks Merci pour ces précisions

Bonjour,

Citation:

---

Envoyé par wiztricks

globals() permettra de récupérer la définition de symboles dans le module courant.

---

En soit n'est il pas risqué de 'stocker' quelque chose dans une boite aussi 'volatile' (les dicos global) ?
Cela n'a pas d'importance ici mais pour du code plus important n'est ce pas le meilleur moyen de 'perdre des petits en route' ?
Outre l'aspect 'injection' le fait d'avoir une 'boite' (objet) bien définie me semble la meilleure façon de 'suivre' ses variables, non ?
Quant a getattr il a au moins l'avantage de limiter les 'dégâts'

Code:

---

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

>>> class A: ... pass ... >>> getattr(A, 'toto') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: type object 'A' has no attribute 'toto' >>> class A: ... toto=1 ... >>> getattr(A, 'toto') 1

---

@+

Salut,

Citation:

---

Envoyé par PauseKawa

En soit n'est il pas risqué de 'stocker' quelque chose dans une boite aussi 'volatile' (les dicos global) ?

Cela n'a pas d'importance ici mais pour du code plus important n'est ce pas le meilleur moyen de 'perdre des petits en route' ?

---

En python, tout étant "dynamique".... je ne connais pas de boîtes qui soient des "coffres forts" inviolables.

classe ou module, ce qui me semble "important", c'est la durée de vie de l'objet: tous deux sont, par défaut, crées et détruits au lancement et à la fin... mais le premier paramètre de getattr fonctionne avec les deux...

note: en fait tout est dans des dict plus ou moins aménagés...

- W

Citation:

---

Envoyé par wiztricks

En python, tout étant "dynamique".... je ne connais pas de boîtes qui soient des "coffres forts" inviolables.

classe ou module, ce qui me semble "important", c'est la durée de vie de l'objet: tous deux sont, par défaut, crées et détruits au lancement et à la fin... mais le premier paramètre de getattr fonctionne avec les deux...

note: en fait tout est dans des dict plus ou moins aménagés...

---

C'est bien le sens de mes 'questions': La visibilité et le type de la 'boite'.
La 'boite' class boite(dict) me semble bien pour du code propre.

@+

Un truc continue à me turlupiner. Vous êtes plusieurs à éviter autant que possible d'utiliser globals() - le dictionnaire retourné - avec, comme clé, le nom de la fonction à appeler.

J'ai le vague sentiment que, dans certains cas, l'utilisation directe du dictionnaire retourné par globals() est préférable* (moins d'intermédiaires, code plus "ramassé" et plus lisible) à l'utilisation d'un dictionnaire géré à la main, qui associerait mots-clés/noms de fonction avec les fonctions, résultat d'un "switch" (if ... elif) géant Non, vu que c'est un dictionnaire - c'est l'initialisation, clé/fonction, une à une qui peut être lourdingue.

(*) du moins, il ne faut pas l'exclure d'emblée

Aussi, y-a-t-il, fondamentalement, une différence entre :

exécuter l'intruction

Code:

---

globals()[nom_fonction](parametres)

---

avec nom_fonction valant "fonction"

et ecrire, dans le code lui-même,

Code:

---

fonction(parametres)

---

Sous la deuxième forme, à l'exécution, l'interpréteur va rechercher le symbole nom_fonction dans l'espace de nommage local, ne pas le trouver (sauf si on est, par exemple, dans le main où locals() et globals() retournent la même chose), dans l'espace de nommage global qui est censé être récupérable via, justement, globals() et, s'il le trouve, (tenter de) lancer/appeler la dite-fonction.

Si la fonction n'existe pas, on n'aura seulement des exceptions différentes levées (NameError ou KeyError) selon l'approche.


Est-ce que je loupe quelque chose en faisant ce raisonnement ?

Bonjour plxpy,

Pour être franc (et je me trompe sans doute):
Pour moi les namespaces font partis de la tuyauterie interne, que ce soit globals() ou locals() ce n'est qu'un accès (représentation sous forme de dico) aux espaces de nom 'global' et 'local' (block).
Certes il est possible d'écrire directement dedans (non recommander pour le local bien sur) mais key = valeur en fait autant et c'est l'interpréteur qui le gère. Je préfère cela.
Ensuite viens le namespace pollution. On y ajoute quelques from tutu import * et nous voila avec une belle pagaille.
Pour finir le suivi des objets. Je trouve plus propre de faire mondico[key] que globals[key]. A moins je sais ce qu'est 'key' dans mon dico, dans le globals (qui est en r/w) je risque d'avoir des surprises. Cela fait un appel global de plus ? globals[key] aussi (et interdit de faire mumuse avec le local).
C'est juste un avis personnel sur mon approche d’autodidacte de Python.

@+

Re,

Petit oubli: Plus mes 'pseudo' questions sur le coté dynamique de tout cela.
Mais en fait on est bien loin de la question posée par Thibqult: Comment utiliser getattr (et en particulier son premier argument) dans le __main__ ;)

@++

je ne suis pas tout à fait d'accord, le PO dit

Citation:

---

J'essaye de comprendre comment appeller une fonction seulement à partir de son nom (stocké dans un string)

---

Il propose getattr, mais la solution avec globals n'est pas mauvaise je pense.

Ce que je ne comprend pas, c'est l'intérêt d'appeler une fonction par son nom version chaine de caractères, je pense à un problème de conception de son code.

En plus getattr(), en ce qui me concerne je ne le vois que comme un retour d'une valeur d'attribut d'objet, un genre de objet.nom

Exact fred1599 pour ce qui est de la question.
Maintenant pour ce qui est du problème de conception je pense plus à un problème de compréhension, d’où le getattr.
Je pense qu'il va falloir attendre une réponse du PO.

@+

Citation:

---

Envoyé par fred1599

Ce que je ne comprend pas, c'est l'intérêt d'appeler une fonction par son nom version chaine de caractères, je pense à un problème de conception de son code.

---

Quand j'ai commencé à travailler en Python, venant du C, je ne comprenais pas non plus l'intérêt d'accéder aux attributs des instances via getattr, en fournissant donc le nom du "champ" sous forme de chaine de caractères. L'idée même que 2 instances d'une même classe n'aient pas nécessairement les mêmes attributs m'avait surpris (pour ne pas dire choqué). Et puis, j'ai appris à m'en servir. Et puis j'ai trouvé ça bien pratique et, au final, bien plus propre.

En C, dans les structures (identiques pour toutes les variables de ce type), il fallait parfois bien mettre "quelque chose", même si le contexte faisait que le champ n'avait pas lieu d'être. Donc, j'y collais une "valeur impossible" ou je passais par des unions ou encore je prévoyais un champ supplémentaire juste là pour dire "ben le champ X on s'en fout, y veut rien dire et faut pas s'en occuper". En Python, je teste l'existence via hasattr et je trouve ça bien plus propre.

Pour le sujet de cette discussion (auquel j'avais répondu, la toute première fois en parlant de globals(), j'avais mis un grand '?' final. C'était uniquement parce que je savais que ça "marchait" mais sans être sur que c'était une bonne façon de faire. Je voulais simplement avoir différents avis, sans me fermer de porte (en me rappelant que "accéder à un champ via son nom (getattr) quelle bizarrerie !" des mes débuts pythonesques, enkylosé par 20 ans de C (qui a ses atouts et que je ne renie pas !)).

Donc, le sujet de mon dernier post était de savoir si on pouvait se garder le "globals()" sous le coude au cas où, ou s'il fallait le proscrire à tout jamais (comme les goto ?).

Vos avis (PauseKawa, Wiztricks, Fred1599, Tyrtamos) m'aident à progresser : merci !

Citation:

---

Envoyé par plxpy

Quand j'ai commencé à travailler en Python, venant du C, je ne comprenais pas non plus l'intérêt d'accéder aux attributs des instances via getattr, en fournissant donc le nom du "champ" sous forme de chaine de caractères. L'idée même que 2 instances d'une même classe n'aient pas nécessairement les mêmes attributs m'avait surpris (pour ne pas dire choqué). Et puis, j'ai appris à m'en servir. Et puis j'ai trouvé ça bien pratique et, au final, bien plus propre.

---

Attention, j'ai pas dis ça!

getattr, je le trouve très utile pour retourner la valeur de l'attribut d'un objet.

D'ailleurs je le dis bien

Citation:

---

Envoyé par fred1599

je ne le vois que comme un retour d'une valeur d'attribut d'objet, un genre de objet.nom

---

Citation:

---

Envoyé par plxpy

En Python, je teste l'existence via hasattr et je trouve ça bien plus propre.

---

Toujours d'accord, même si j'ai fais très très peu de C

Citation:

---

Envoyé par plxpy

Pour le sujet de cette discussion (auquel j'avais répondu, la toute première fois en parlant de globals(), j'avais mis un grand '?' final. C'était uniquement parce que je savais que ça "marchait" mais sans être sur que c'était une bonne façon de faire. Je voulais simplement avoir différents avis, sans me fermer de porte (en me rappelant que "accéder à un champ via son nom (getattr) quelle bizarrerie !" des mes débuts pythonesques, enkylosé par 20 ans de C (qui a ses atouts et que je ne renie pas !)).

---

La clef du problème est là, globals dans son cas, qui me paraît louche, est la seule solution!!!

getattr() ne fait pas la même chose, il recherche un attribut de l'objet.

N'y a-t-il pas confusion entre attribut et fonction?

Citation:

---

Envoyé par plxpy

Donc, le sujet de mon dernier post était de savoir si on pouvait se garder le "globals()" sous le coude au cas où, ou s'il fallait le proscrire à tout jamais (comme les goto ?).

---

Pour moi clairement oui, d'où son problème de conception, il y a d'autres façon d'appeler une fonction.

Pourquoi ne pas appeler sa fonction directement, y-a-t-il un exemple où nous sommes obligés d'appeler une fonction par sa chaîne?

Citation:

---

Envoyé par plxpy

Vos avis (PauseKawa, Wiztricks, Fred1599, Tyrtamos) m'aident à progresser : merci !

---

idem

Bonjour,

Pour moi, utiliser globals, getattr, etc..., c'est utiliser la "machinerie" interne de Python: ce n'est pas du codage "normal". Je l'évite donc le plus possible, et je ne l'utilise que quand je ne peux vraiment pas faire autrement (et c'est plutôt rare).

Par contre, pour construire un module de type "bibliothèque" avec des fonctions qui manquent à Python, j'accepte de les utiliser parce que je suis dans un cadre "système".

Mais rien n'empêche de s'amuser avec ces fonctions pour des codages "hors production", parce que justement, ça permet de mieux comprendre comment fonctionne Python... :D

A noter toutefois que l’utilisation de la 'machinerie interne' (globals() ici) est plus rapide: A oublier ? Non.
Ceci dit rien ne dit que le namespace reste sous la forme d'un dico...