我认为由于 lazy evaluation 语句如：
if True and True (...):
# do something
...应该在Python解释器的True and部分后面跳过。但是，与编译代码相比，我认为Python解释器不能像显式布尔比较那样优化坏样式，对吗？
if condition == True:
# do something
编译器会对此进行优化并删除== True部分，但解释器始终必须评估哪些语句在condition ==部分之后等待，从而进行不必要的比较每次代码执行时== True？
存在更多这样的陷阱，解释器无法优化代码？我知道这最后一个问题是开放的，但我想一些流行的例子确实存在吗？
答案 0 :(得分：3)
编译本身并不多（CPython会编译成字节码），但语言极其动态的特性阻碍了＃34;传统＆＃34;优化，由在Python中编译时难以检查的不变量引导，因为语言的语义使得大多数关于代码实际应该执行的操作的信息仅在运行时可用。
你的if condition == True:示例是一个很好的例子：只有当编译器能够证明condition总是一个布尔值时才能优化比较，如果它来自任何东西，那么这是一项非常重要的任务当前范围内的文字 - 如果它可以证明在运行时没有人设法用其他东西覆盖True（仅在Python 2 IIRC中可能）。
请注意，某些类型推断是可能的，而且它实际上是像Jedi这样的代码完成工具的工作原理;然而，绝地可以采取一些捷径，并假设，例如某种标准环境，而解释器必须应对语言允许的全局变量最奇怪的修改。
所以，总的来说，CPython不会非常努力地优化任何东西 - 实际上，它似乎并没有做任何类型的＆＃34;智能＆＃34;代码分析，AFAICT他们大多试图建立一个有效但但主要是香草＆＃34;翻译。因此，期望几乎完全按照你所写的内容付费，没有优化器来保存草率代码。
顺便说一句，你的and示例并不是解释器所做的优化，而是操作员的语义是如何定义的（而且它是非常重要的＃39} ; s指定and和or进行短路评估，并且它不是可选的＆＃34;优化＆＃34;，因为它可以改变程序的可观察行为，如果正确的话手操作有副作用）。
动态的语言更好的方法是跟踪JIT 的方法 - 解释器允许代码运行一段时间，并观察似乎不变的不变量保持良好（例如，condition似乎总是一个布尔值，True总是True，一些变量总是一个整数，...），然后使用这些信息进行编译机器代码优化版本的代码。只要上面的不变量确实存在，就可以运行 - 但只要用于编译优化版本的其中一个前提被破坏，执行就会返回解释模式，并再次开始跟踪以查明是否有新的优化版本可以建造。
因此，典型的情况很好地优化，应用通常的优化技术，但每当奇怪的事情（但语言允许）发生时，运行时可以回退到常规＆＃34;字面＆＃34;字节码解释。
这是用于从大多数动态语言中挤出良好性能的方法（大多数现代JavaScript引擎使用这种基本方法的一些变体），并且在PyPy中使用Python。