除了最好的做法,有没有令人信服的理由不这样做?
我正在编写一个post-commit钩子,用于Google Code项目,该项目通过JSON对象提供提交数据.GC提供HMAC身份验证令牌以及请求(在JSON数据之外),因此通过验证该令牌,我可以高度确信JSON数据是良性的(因为不信任Google)并且有效.
我自己(简短)的调查表明,JSON恰好是完全有效的Python,但"\/"
转义序列除外- GC似乎没有生成.
因此,当我使用Python 2.4(即没有json
模块)时,eval()
看起来真的很诱人.
编辑:为了记录,我不是在问这是不是一个好主意.我非常清楚它不是,我非常怀疑即使我最终将它用于这个项目,我也会将这项技术用于任何未来的项目.我只是想确保我知道如果我这样做会遇到什么样的麻烦.:-)
Kiv*_*Kiv 29
如果你对你的脚本工作正常一段时间感觉很舒服,然后在一些不起眼的边缘情况下随机失败,我会选择eval.
如果你的代码很健壮很重要,我会花时间添加simplejson.你不需要C部分来加速,所以将一些.py文件转储到某个目录中真的不难.
作为可能咬你的东西的一个例子,JSON使用Unicode而simplejson返回Unicode,而eval返回str:
>>> simplejson.loads('{"a":1, "b":2}')
{u'a': 1, u'b': 2}
>>> eval('{"a":1, "b":2}')
{'a': 1, 'b': 2}
Run Code Online (Sandbox Code Playgroud)
编辑:eval()行为不同的更好示例:
>>> simplejson.loads('{"X": "\uabcd"}')
{u'X': u'\uabcd'}
>>> eval('{"X": "\uabcd"}')
{'X': '\\uabcd'}
>>> simplejson.loads('{"X": "\uabcd"}') == eval('{"X": "\uabcd"}')
False
Run Code Online (Sandbox Code Playgroud)
编辑2:看到今天SilentGhost指出的另一个问题:eval不能处理true - > True,false - > False,null - > None not correct.
>>> simplejson.loads('[false, true, null]')
[False, True, None]
>>> eval('[false, true, null]')
Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
File "<string>", line 1, in <module>
NameError: name 'false' is not defined
>>>
Run Code Online (Sandbox Code Playgroud)
Jam*_*son 11
最佳实践的观点是,在大多数情况下,忽视它们是一个坏主意.如果我是你,我会使用解析器将JSON解析为Python.尝试使用simplejson,在我上次尝试时解析JSON非常简单,它声称与Python 2.4兼容.
我不同意谷歌不信任这一点.我不会不信任他们,但我会验证你从他们那里得到的数据.我实际使用JSON解析器的原因正好在你的问题中:
我自己(简短)的研究表明,JSON恰好是完全有效的Python,除了"/"转义序列 - GC似乎没有生成.
是什么让你认为Google Code永远不会产生这样的转义序列?
如果使用正确的工具,解析是一个已解决的问题.如果你试图采用这样的快捷方式,你最终会被错误的假设所困扰,或者当你的选择语言已经存在解析器时,你会做一些事情,比如尝试用正则表达式和布尔逻辑来破解解析器.
归档时间: |
|
查看次数: |
12953 次 |
最近记录: |