eval()和 exec()这类语句存在的意义是什么？

通过可信 dsl 产生程序然后运行吧。。。

直接字符串拼接然后运行容易被注入，但是你可以自己实现一套简单的编译器，然后编译成 host 语言运行

写个稍微复杂一点的模板引擎你就知道了

动态输入代码可以提供很高的灵活性

@ipwx 你是指自举？

我用在给客人自定义模版上，内网环境下还是挺好用的

用二进制或者脚本创建子进程

@pythonee 不是自举。

模板引擎、动态执行代码，etc 。

很多需要繁琐的 if-else factory 设计模式的，用动态代码生成，有时候就很容易解决了。

退一万步，JIT 这东西知道吧？相当于它根据 JVM bytecode 产生了机器码。某种意义上也算是 CPU 的 eval 了。

元编程

只要执行的字符串可控还是挺有用的，用来实现一些黑魔法。

举个例子，自己写一个 github action ，肯定就要用到 eval ，exec 这些方法

exec 日常模版解析传入 UDF...

eval 的话, 有时候动态传入参数想保留数据类型, 又懒得用 JSON...

自古以来，程序是程序，数据是数据，程序处理数据但数据不能变成程序的一部分。

eval 打破了这个限制

没说语言，C++的话没有 exec 估计现在计算机体系不复存在了

@GeruzoniAnsasu 自古以来就没有这样的限制，图灵机是不分程序和数据的，冯诺依曼结构也不分程序存储和数据存储，哈佛结构有这种限制，但是长期以来就不是主流。现代 CPU 为了安全性加入了内存权限，但也和哈佛结构有本质区别。

比如给自己本地用的 web 工具等不需要考虑安全，只需要考虑方便的特殊场景。

@ysc3839 怎么说呢，理论模型从理论上已经是完备的，所以体现不出来我想表达的点，就比如我想说「图灵机并不能把自己的状态喂给另一个图灵机」但作为理论，图灵机完全可以按照纸带的要求把上一个状态写到纸带上。

eval 大法好啊

eval 可以将 repr 序列化的数据结构还原。持久化数据结构蛮好用的。只要把控住数据源，不用脏数据，就没问题。

昨天安装 homebrew 的时候发现用到了 eval

脚本语言大都有这个共性，调试会方便。但是在生产环境 eval=evil

Python 的模板引擎都是 eval……

说一个稍微偏一些的吧...有的时候做装饰器的时候，有一些动态类型判断，PyCharm 可能会抽风，直接调试运行会提示类型检查不通过。这时候把条件判断表达式换成 eval 的就可以欺骗过 PyCharm 。

给你举个具体例子，
比如你使用 protobuf ，传递一个具体的消息名，现在需要用这个名字构造一个对应的消息体:

func = eval("Hello_pb2.LoginRequest")
request = func()
request.serverId = 0
request.token = "i am vkingsea"
send(request)

@monetto alt + enter suppress warring for statement. 这样相当于掩耳盗铃

@aguesuka 总不能要求所有人都这样来一遍吧...

@monetto
虽然手边没有 pycharme, 但是我猜它的 suppress warning type hint 是这样实现的
https://www.python.org/dev/peps/pep-0484

Compatibility with other uses of function annotations
A number of existing or potential use cases for function annotations exist, which are incompatible with type hinting. These may confuse a static type checker. However, since type hinting annotations have no runtime behavior (other than evaluation of the annotation expression and storing annotations in the __annotations__ attribute of the function object), this does not make the program incorrect -- it just may cause a type checker to emit spurious warnings or errors.

To mark portions of the program that should not be covered by type hinting, you can use one or more of the following:

a # type: ignore comment;
a @no_type_check decorator on a class or function;
a custom class or function decorator marked with @no_type_check_decorator.
For more details see later sections.

In order for maximal compatibility with offline type checking it may eventually be a good idea to change interfaces that rely on annotations to switch to a different mechanism, for example a decorator. In Python 3.5 there is no pressure to do this, however. See also the longer discussion under Rejected alternatives below.