Système de script souple avec eval()

Bonsoir,

J'aimerai réaliser et utiliser un système de scripts qui aurait le comportement suivant :
Charger dans un dict tout les fichiers contenus dans un dossier contenant chacun une réimplémentation d'une classe.

Je ne sais pas si cela veut dire quelque-chose ou pas, mais je pense que des exemples seront beaucoup plus parlants à vous comme à moi :

Voici la classe abstraite AbstractBlock qui comporte peut d’éléments (c'est juste pour l'exemple) :

Code:

---

1 2 3 4 5 6

class AbstractBlock: def __init__(self): pass   def onCross(self, vehicle): pass

---

Et voici par exemple un fichier "grass_radioactive.block" :

Code:

---

1 2 3 4 5 6

class GrassRadioactiveBlock(AbstractBlock): def __init__(self): pass   def onCross(self, vehicle): vehicle.damage(10)

---

Comme vous pouvez le constater, le fichier "grass_radioactive.block" ne comporte pas d'include vers la classe AbstractBlock, car en effet je veux que ce soit un fichier de script et donc qu'il se limite au minimum et que les import se fassent en interne, pas dans le script. Je pourrais toujours rajouter le "import" dans la chaine de caractère avant de la passer à eval().

De plus, une fois tout les fichiers chargés, je voudrais avoir un dict contenant pour clé le nom du fichier (sans l'extension) et comme valeur la classe contenue dedans, par exemple ici mon dict peut être représenté comme ceci :

Code:

---

blocks = {"radioactive_grass": RadioactiveGrassBlock}

---

Je ne sais pas si cette méthode est trop dure à implémenter (à priori non à l'aide de eval()) ni si elle est "sâle" ou pas, mais je tiens absolument à séparer les fichiers de script du "moteur" du jeu.

Auriez vous déjà des idées pour charger ces classes dans le dict ? Car je ne vois pas comment faire avec eval()...
Merci d'avance pour vos éventuelles remarques et réponses :)

eval évalue une expression, mais ici c'est une bloc d'instructions et c'est donc plutôt exec qu'il faut utiliser (ou, dans ton cas, execfile est sans doute plus approprié).

Ajouter une instruction import ... n'est pas nécessaire, tu peux passer un dictionnaire en argument (globals) à eval/exec/execfile qui contient déjà le module nécessaire chargé.

Pour récupérer la classe après exécution, à priori je pense à parcourir le dictionnaire passé en globals au script à la recherche d'une sous-classe de AbstractBlock.

Si le principe est de permettre aux utilisateurs de scripter ton application, c'est bien sûr très dangereux d'exécuter du code python arbitraire, mais je suppose que tu es conscient de ça...

Bonsoir.

Citation:

---

Envoyé par dividee

... c'est bien sûr très dangereux d'exécuter du code python arbitraire, mais je suppose que tu es conscient de ça...

---

eval is evil !

Citation:

---

Envoyé par rambc

eval is evil !

---

Bert is evil! go back!
(pour ceux qui comprennent :P)

Bonjour,

Comme ceci ?

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

#!/usr/bin/env python # -*- coding: ISO8859-1 -*- # # class AbstractBlock: def __init__(self): pass   def onCross(self, vehicle): pass   grass_radioactive = """class GrassRadioactiveBlock(AbstractBlock):     def __init__(self):         pass       def onCross(self, vehicle):         return vehicle"""   exec(grass_radioactive) # Ou execfile si c'est un fichier   blocks = {"radioactive_grass": GrassRadioactiveBlock}   inst = blocks['radioactive_grass']() print(inst.onCross('Patin à roulette')) print(inst)

---

Mais bon... Utiliser exec/eval pour du code Python...
Vous devriez suivre le conseil de dividee et penser à un autre système.

@+

Merci pour vos réponses, j'irai faire un tour sur la doc pour exec et execfile :)

Sinon, je suis conscient des risques mais le jeu sera lui-même opensource, alors entre mettre des failles dans le code source ou dans les scripts, je vois pas trop la différence. Sur un plan technique, on peut imaginer un site officiel qui distribue les "extensions" (ensemble de scripts et textures) qui vérifie ces extensions avant de les publier.
Non, pour moi, cela n'introduit pas trop de grosses failles, je ne vois pas l'intérêt de mettre des failles dans les scripts alors que ce serai plus simple dans le code source 8-)

Sinon, au niveau du script, j'aimerai alléger le plus possible les fichiers de script. Prenons ici le fichier d'extension .block précedent :

Code:

---

1 2 3 4 5 6

class GrassRadioactiveBlock(AbstractBlock): def __init__(self): pass   def onCross(self, vehicle): vehicle.damage(10)

---

Il pourrait alors devenir :

Code:

---

1 2 3 4 5

def __init__(self): pass   def onCross(self, vehicle): vehicle.damage(10)

---

Le nom de la classe n'ayant pas d'importance (car gestion par dictionnaire), il pourra être généré par le nom du fichier. Je veux vraiment que l'on évite les détails techniques dans les scripts (redéclarer une classe à chaque fois me parait abusif pour le scripteur :roll: ).

Mais bon, je fonce tête baissée dans mon idée mais je ne sais pas du tout si elle sera maintenable dans le temps et pas trop compliquée à mettre en place. J'attends donc vos avis sur ce système en lui même, si on exclue bien sûr les éventuelles failles de sécurité (comme j'en ai parlé plus haut).

Merci pour vos réponses ;)

EDIT :

Citation:

---

Vous devriez suivre le conseil de dividee et penser à un autre système.

---

Je n'ai pas compris ce conseil :?
Mais sinon, qu'avez vous d'autre à proposer ? Garder du code python générique et s'embêter à faire des import en boucle ?

Citation:

---

Envoyé par darkrojo

Sinon, au niveau du script, j'aimerai alléger le plus possible les fichiers de script. Prenons ici le fichier d'extension .block précedent :

Code:

---

1 2 3 4 5 6

class GrassRadioactiveBlock(AbstractBlock): def __init__(self): pass   def onCross(self, vehicle): vehicle.damage(10)

---

Il pourrait alors devenir :

Code:

---

1 2 3 4 5

def __init__(self): pass   def onCross(self, vehicle): vehicle.damage(10)

---

Le nom de la classe n'ayant pas d'importance (car gestion par dictionnaire), il pourra être généré par le nom du fichier. Je veux vraiment que l'on évite les détails techniques dans les scripts (redéclarer une classe à chaque fois me parait abusif pour le scripteur :roll: )

---

Dans ce cas autant éviter Python et passer directement par un fichier de configuration avec section. Comprendre (par exemple)

Code:

---

1 2	[onCross] vehicle.damage = 10

---

A vous de traiter le fichier avec Python dans votre code

Sinon, comme dirait dividee, You've been warned

Citation:

---

Envoyé par dividee

Bert is evil! go back!
(pour ceux qui comprennent :P)

---

Moi pas comprendre... :aie:

Citation:

---

Envoyé par rambc

Moi pas comprendre... :aie:

---

Bah, moi non plus…:cry:

Je propose ceci:

Code:

---

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

class AbstractBlock: def __init__(self): pass   def onCross(self, vehicle): pass   def load_class(name, bases, filename): attrs = {'__builtins__' : __builtins__ } execfile(filename, attrs) del attrs['__builtins__'] globals()[name] = type(name, bases, attrs)     load_class("GrassRadioactiveBlock",(AbstractBlock,),"grass_radioactive.block")

---

Citation:

---

Envoyé par dividee

Bert is evil! go back!
(pour ceux qui comprennent :P)

---

Bah, c'était un référence à Python Challenge. Il semblerait que pas grand monde ici soit arrivé jusqu'au niveau 13 ;)

Bonjour dividee,

[courge_attitude]

Pourquoi __builtins__ ?

Dans le cadre d'une parenté comme décrite plus haut, soit class GrassRadioactiveBlock(AbstractBlock), je ne vois pas comment AbstractBlock peut être visible pour GrassRadioactiveBlock au sein d'exec s'il n'est pas dans attrs.

type(name, bases, attrs) avec (AbstractBlock,) ? Dans ce cas cela ne fonctionne pas si nous n'avons pas class AbstractBlock(object), non ?

Il faudrait faire une fonction execfile pour Python 3 pour être compatible.

Pourquoi le del ?

[/courge_attitude]

@+

Bon... C'était bien ma courge attitude du week-end.
J'étais partis sur un grass_radioactive.block avec

Code:

---

1 2	class GrassRadioactiveBlock(AbstractBlock): ...

---

et non

Code:

---

1 2	def __init__(self): pass

---

comme demander.

Par contre mon questionnement reste pour ce qui est de l'utilisation de __builtins__ et type.

Code:

---

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

class AbstractBlock(object): def __init__(self): pass   def onCross(self, vehicle): pass   def loadfile(name): with open(name) as f: return f.read()   def load_class(name, bases, filename): attrs = {} exec(loadfile(filename), attrs) globals()[name] = type(name, bases, attrs)   load_class("GrassRadioactiveBlock", (AbstractBlock,), "grass_radioactive.block")

---

fonctionne tout aussi bien.

@+

Bonjour PauseKawa,

pour l'héritage de object, tu as raison je l'avais oublié...

Pour l'ajout de __builtins__ dans le dico avant l'appel de exec/execfile, c'est parce que je pensais que l'argument globals était traité comme pour eval:

Citation:

---

If the globals dictionary is present and lacks ‘__builtins__’, the current globals are copied into globals before expression is parsed.

---

Je voulais éviter que les variables globales actuelles soient passées au script et ne viennent polluer attrs. Mais effectivement, en testant un peu, il semble que seul __builtins__ soit copié dans attrs s'il est vide; on peut donc passer un dictionnaire vide.

Par contre, le del de __builtins__ reste nécessaire, sinon tu te retrouves avec une classe qui contient un attribut __builtins__

Merci pour la réponse, je commençais à avoir une surchauffe de mon monoméninge à force de chercher le pourquoi ;)

À propos de l’héritage de object, on n’est plus obligé de le préciser explicitement, si*?

normalement, les parenthèses suffisent, object est alors implicitement le parent*:

Code:

---

class AbstractBlock():

---

Pas vraiment

Code:

---

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

>>> class Foo(): ... pass ... >>> class Foo1(object): ... pass ... >>> print(dir(Foo)) ['__doc__', '__module__'] >>> print(dir(Foo1)) ['__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__'] >>> print(type(Foo)) <type 'classobj'> >>> print(type(Foo1)) <type 'type'>

---

Avec Python 3, il n'y a plus de différence entre new-style et les classic-style. Aussi, les parenthèses ne sont pas indispensable pour les classes n'héritant que de object. Toutefois, pour rendre un code portable d'une version 3 à 2 de python, il est évidemment indispensable d'utiliser la notation dite New-Style (ç-à-d: en précisant l'héritage de object).

Ah oui, effectivement, j’étais en train de faire un backport optimiste :mouarf:

Salut,

Citation:

---

Envoyé par dividee

Bah, c'était un référence à Python Challenge. Il semblerait que pas grand monde ici soit arrivé jusqu'au niveau 13 ;)

---

Ben bravo, je sens que ça va bien me pourrir la semaine, là... Même pas pu résoudre la numéro 1! :mouarf: Mais comme je suis têtu je sens que je vais y passer du temps. :?

A+

Pfeuh

Citation:

---

Envoyé par pfeuh

Salut,



Ben bravo, je sens que ça va bien me pourrir la semaine, là... Même pas pu résoudre la numéro 1! :mouarf: Mais comme je suis têtu je sens que je vais y passer du temps. :?

A+

Pfeuh

---

:mouarf: 2^