Pourquoi utiliser «eval» est-il une mauvaise pratique?

J'utilise la classe suivante pour stocker facilement les données de mes chansons.

class Song:
    """The class to store the details of each song"""
    attsToStore=('Name', 'Artist', 'Album', 'Genre', 'Location')
    def __init__(self):
        for att in self.attsToStore:
            exec 'self.%s=None'%(att.lower()) in locals()
    def setDetail(self, key, val):
        if key in self.attsToStore:
            exec 'self.%s=val'%(key.lower()) in locals()

Je pense que c'est juste beaucoup plus extensible que d'écrire un if/elsebloc. Cependant, evalsemble être considéré comme une mauvaise pratique et dangereux à utiliser. Si oui, quelqu'un peut-il m'expliquer pourquoi et me montrer une meilleure façon de définir la classe ci-dessus?

Oui, utiliser eval est une mauvaise pratique. Pour ne citer que quelques raisons:

1. Il y a presque toujours une meilleure façon de le faire
2. Très dangereux et peu sûr
3. Rend le débogage difficile
4. Lent

Dans votre cas, vous pouvez utiliser setattr à la place:

class Song:
    """The class to store the details of each song"""
    attsToStore=('Name', 'Artist', 'Album', 'Genre', 'Location')
    def __init__(self):
        for att in self.attsToStore:
            setattr(self, att.lower(), None)
    def setDetail(self, key, val):
        if key in self.attsToStore:
            setattr(self, key.lower(), val)

ÉDITER:

Dans certains cas, vous devez utiliser eval ou exec. Mais ils sont rares. Utiliser eval dans votre cas est certainement une mauvaise pratique. Je mets l'accent sur les mauvaises pratiques car eval et exec sont souvent utilisés au mauvais endroit.

MODIFIER 2:

Il semble que certains ne soient pas d'accord sur le fait que l'évaluation est «très dangereuse et peu sûre» dans le cas de l'OP. Cela pourrait être vrai pour ce cas précis, mais pas en général. La question était générale et les raisons que j'ai énumérées sont également valables pour le cas général.

EDIT 3: réorganisé les points 1 et 4

L'utilisation evalest faible, ce n'est clairement pas une mauvaise pratique.

1. Il viole le «principe fondamental du logiciel». Votre source n'est pas la somme totale de ce qui est exécutable. En plus de votre source, il y a les arguments pour eval, qui doivent être clairement compris. Pour cette raison, c'est l'outil de dernier recours.

2. C'est généralement le signe d'un design irréfléchi. Il y a rarement une bonne raison pour un code source dynamique, construit à la volée. Presque tout peut être fait avec la délégation et d'autres techniques de conception OO.

3. Cela conduit à une compilation à la volée relativement lente de petits morceaux de code. Une surcharge qui peut être évitée en utilisant de meilleurs modèles de conception.

En note de bas de page, entre les mains de sociopathes dérangés, cela peut ne pas bien fonctionner. Cependant, lorsqu'ils sont confrontés à des utilisateurs ou administrateurs sociopathes dérangés, il est préférable de ne pas leur donner Python interprété en premier lieu. Entre les mains du vraiment pervers, Python peut être un handicap; evaln'augmente pas du tout le risque.

Dans ce cas, oui. Au lieu de

exec 'self.Foo=val'

vous devez utiliser la fonction intégréesetattr :

setattr(self, 'Foo', val)

Oui, ça l'est:

Pirater en utilisant Python:

>>> eval(input())
"__import__('os').listdir('.')"
...........
...........   #dir listing
...........

Le code ci-dessous répertorie toutes les tâches exécutées sur une machine Windows.

>>> eval(input())
"__import__('subprocess').Popen(['tasklist'],stdout=__import__('subprocess').PIPE).communicate()[0]"

Sous Linux:

>>> eval(input())
"__import__('subprocess').Popen(['ps', 'aux'],stdout=__import__('subprocess').PIPE).communicate()[0]"

Il convient de noter que pour le problème spécifique en question, il existe plusieurs alternatives à l'utilisation eval:

Le plus simple, comme indiqué, consiste à utiliser setattr:

def __init__(self):
    for name in attsToStore:
        setattr(self, name, None)

Une approche moins évidente consiste à mettre à jour __dict__directement l'objet de l' objet. Si tout ce que vous voulez faire est d'initialiser les attributs sur None, c'est moins simple que ce qui précède. Mais considérez ceci:

def __init__(self, **kwargs):
    for name in self.attsToStore:
       self.__dict__[name] = kwargs.get(name, None)

Cela vous permet de transmettre des arguments de mot-clé au constructeur, par exemple:

s = Song(name='History', artist='The Verve')

Cela vous permet également de rendre votre utilisation locals()plus explicite, par exemple:

s = Song(**locals())

... et, si vous voulez vraiment attribuer Noneles attributs dont les noms se trouvent dans locals():

s = Song(**dict([(k, None) for k in locals().keys()]))

Une autre approche pour fournir un objet avec des valeurs par défaut pour une liste d'attributs consiste à définir la __getattr__méthode de la classe :

def __getattr__(self, name):
    if name in self.attsToStore:
        return None
    raise NameError, name

Cette méthode est appelée lorsque l'attribut nommé n'est pas trouvé de la manière normale. Cette approche est un peu moins simple que de simplement définir les attributs dans le constructeur ou de mettre à jour le __dict__, mais elle a le mérite de ne pas créer réellement l'attribut à moins qu'il n'existe, ce qui peut réduire considérablement l'utilisation de la mémoire de la classe.

Le point de tout cela: il y a beaucoup de raisons, en général, à éviter eval- le problème de sécurité de l'exécution de code que vous ne contrôlez pas, le problème pratique du code que vous ne pouvez pas déboguer, etc. Mais une raison encore plus importante est-ce que généralement, vous n'avez pas besoin de l'utiliser. Python expose tellement de ses mécanismes internes au programmeur que vous avez rarement vraiment besoin d'écrire du code qui écrit du code.

D'autres utilisateurs ont souligné comment votre code peut être modifié pour ne pas dépendre de eval; Je vais proposer un cas d'utilisation légitime eval, celui que l'on trouve même dans CPython: testing .

Voici un exemple que j'ai trouvé dans test_unary.pylequel un test pour savoir si (+|-|~)b'a'lève un TypeError:

def test_bad_types(self):
    for op in '+', '-', '~':
        self.assertRaises(TypeError, eval, op + "b'a'")
        self.assertRaises(TypeError, eval, op + "'a'")

L'usage n'est clairement pas une mauvaise pratique ici; vous définissez l'entrée et observez simplement le comportement. evalest pratique pour les tests.

Jetez un oeil à cette recherche pour eval, effectuée sur le dépôt git CPython; les tests avec eval sont largement utilisés.

Quand eval()est utilisé pour traiter l'entrée fournie par l'utilisateur, vous autorisez l'utilisateur à Drop-to-REPL en fournissant quelque chose comme ceci:

"__import__('code').InteractiveConsole(locals=globals()).interact()"

Vous pouvez vous en tirer, mais normalement vous ne voulez pas de vecteurs pour l'exécution de code arbitraire dans vos applications.

En plus de la réponse @Nadia Alramli, puisque je suis nouveau sur Python et que je voulais vérifier comment l'utilisation evalaffectera les horaires , j'ai essayé un petit programme et ci-dessous se trouvaient les observations:

#Difference while using print() with eval() and w/o eval() to print an int = 0.528969s per 100000 evals()

from datetime import datetime
def strOfNos():
    s = []
    for x in range(100000):
        s.append(str(x))
    return s

strOfNos()
print(datetime.now())
for x in strOfNos():
    print(x) #print(eval(x))
print(datetime.now())

#when using eval(int)
#2018-10-29 12:36:08.206022
#2018-10-29 12:36:10.407911
#diff = 2.201889 s

#when using int only
#2018-10-29 12:37:50.022753
#2018-10-29 12:37:51.090045
#diff = 1.67292