为什么使用“eval”是一种不好的做法？

问题描述：

我使用以下类来轻松存储我的歌曲的数据。

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

我觉得这比写出一个if/else块更具可扩展性。但是，我听说这eval不安全。是吗？风险是什么？我如何解决我的类中的底层问题（self动态设置属性）而不承担这种风险？

解决方案 1：

是的，使用eval是一种不好的做法。仅举几个原因：

1. 几乎总是有更好的方法来实现它

2. 非常危险和不安全

3. 使调试变得困难

4. 慢的

在你的情况下，你可以使用setattr代替：

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)

在某些情况下，您必须使用eval或exec。但这种情况很少见。eval在您的案例中使用 肯定是一种不好的做法。我强调的是不好的做法，因为eval和exec经常用在错误的地方。

回复评论：

看起来有些人不同意evalOP 案例中“非常危险和不安全”的说法。对于这个具体案例来说，这可能是正确的，但对于一般情况来说并非如此。这个问题很普遍，我列出的原因也适用于一般情况。

解决方案 2：

使用eval很弱，但不是一种明显的坏习惯。

1. 它违反了“软件基本原则”。源代码不是可执行文件的总和。除了源代码之外，还有 的参数eval，必须清楚地理解。因此，它是最后的手段。

2. 这通常是设计不周全的表现。动态源代码很少是即时构建的，几乎没有什么好的理由。几乎任何事情都可以通过委托和其他 OO 设计技术来完成。

3. 这会导致小段代码的即时编译速度相对较慢。使用更好的设计模式可以避免这种开销。

顺便说一句，在精神错乱的反社会者手中，它可能不会奏效。但是，当面对精神错乱的反社会用户或管理员时，最好一开始就不要给他们解释过的 Python。在真正邪恶的人手中，Python 可能是一种负担；eval根本不会增加风险。

解决方案 3：

是的：

使用 Python 进行破解：

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

下面的代码将列出 Windows 机器上运行的所有任务。

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

在 Linux 中：

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

解决方案 4：

在这种情况下，是的。而不是

exec 'self.Foo=val'

您应该使用内置函数setattr：

setattr(self, 'Foo', val)

解决方案 5：

值得注意的是，对于所讨论的具体问题，有几种替代方法eval：

如上所述，最简单的方法是使用setattr：

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

一种不太明显的方法是直接更新对象的__dict__对象。如果您只想将属性初始化为None，那么这种方法就不如上述方法简单。但请考虑这一点：

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

这允许您将关键字参数传递给构造函数，例如：

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

它还允许您使用locals()更明确的内容，例如：

s = Song(**locals())

...并且，如果您确实想要分配None给在中找到名称的属性locals()：

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

为对象提供属性列表的默认值的另一种方法是定义类的__getattr__方法：

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

当以正常方式找不到指定属性时，将调用此方法。这种方法比简单地在构造函数中设置属性或更新 稍微不那么直接__dict__，但它的优点是除非属性存在，否则不会实际创建该属性，这可以大大减少类的内存使用量。

所有这些的要点是：通常，有很多理由需要避免eval- 执行您无法控制的代码的安全问题、无法调试的代码的实际问题等。但更重要的原因是，通常您不需要使用它。Python 向程序员公开了如此多的内部机制，以至于您很少真正需要编写编写代码的代码。

解决方案 6：

其他用户指出了如何将代码更改为不依赖于eval；我将提供一个使用 的合法用例eval，一个甚至可以在 CPython 中找到的用例：测试。

下面是我发现的一个例子，其中对是否引发的test_unary.py测试：(+|-|~)b'a'`TypeError`

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

这里的用法显然不是坏习惯；您定义输入并仅观察行为。eval对于测试很方便。

看一下eval在 CPython git 存储库上执行的这个搜索；使用 eval 进行测试被大量使用。

解决方案 7：

当eval()用于处理用户提供的输入时，您可以使用Drop-to-REPL为用户提供如下内容：

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

您可能会逃脱惩罚，但通常您不希望在应用程序中存在用于任意代码执行的向量。

解决方案 8：

除了@Nadia Alramli 的回答之外，由于我是 Python 新手，并且急于检查使用eval将如何影响时间，所以我尝试了一个小程序，以下是观察结果：

#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