为什么使用“eval”是一种不好的做法？
- 2024-11-15 08:36:00
- admin 原创
- 182
问题描述：
我使用以下类来轻松存储我的歌曲的数据。
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是一种不好的做法。仅举几个原因：
几乎总是有更好的方法来实现它
非常危险和不安全
使调试变得困难
慢的
在你的情况下，你可以使用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很弱，但不是一种明显的坏习惯。
它违反了“软件基本原则”。源代码不是可执行文件的总和。除了源代码之外，还有 的参数
eval，必须清楚地理解。因此，它是最后的手段。这通常是设计不周全的表现。动态源代码很少是即时构建的，几乎没有什么好的理由。几乎任何事情都可以通过委托和其他 OO 设计技术来完成。
这会导致小段代码的即时编译速度相对较慢。使用更好的设计模式可以避免这种开销。
顺便说一句，在精神错乱的反社会者手中，它可能不会奏效。但是，当面对精神错乱的反社会用户或管理员时，最好一开始就不要给他们解释过的 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
