Discussion :

[darkrojo]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[dividee]

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...

[rambc]

Bonsoir.

... 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 !

[dividee]

eval is evil !

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

[PauseKawa]

Bonjour,

Comme ceci ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

@+

[darkrojo]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ).

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 :

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 ?

[PauseKawa]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 )

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[rambc]

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

Moi pas comprendre...

[mont29]

Moi pas comprendre...

Bah, moi non plus…

[dividee]

Je propose ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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")

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

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

[PauseKawa]

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]

@+

[PauseKawa]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
class GrassRadioactiveBlock(AbstractBlock):
...

et non

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

@+

[dividee]

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:

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__

[PauseKawa]

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

[mont29]

À 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

class AbstractBlock():

[PauseKawa]

Pas vraiment

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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'>

[PsycoPy]

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).

[mont29]

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

[pfeuh]

Salut,

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! Mais comme je suis têtu je sens que je vais y passer du temps.

A+

Pfeuh

[PauseKawa]

Salut,



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

A+

Pfeuh

2^