为什么如果x在（1,2,3）：比如果x==1或x==2或x==3快：

Question

根据http://pylint.pycqa.org/en/latest/whatsnew/2.0.html，in选项比多个OR更快

从网站上引用

A new check was added, consider-using-in.

This refactoring message is emitted when a variable is compared against multiple values concatenated by ors instead of using the faster, more idiomatic "in" check.

if variable == 1 or variable == 2 or variable == 3: # bad pass

if variable in (1, 2, 3): # good pass

首先，in选项是否更快？因为它肯定必须与多个OR做相同的事情，而且每次创建元组的内存代价不值得吗

Answer 1

就像通常的情况一样，我认为派林是错误的。事实并非总是如此。在字节码编译步骤中，只有的元组可以缓存为常量，但情况并非总是如此。简单的考虑：

In [1]: def using_in(a, b, c):
   ...:     42 in (a,b,c)
   ...:

In [2]: def using_or(a, b, c):
   ...:     42 == a or 42 == b or 42 == c
   ...:

In [3]: %timeit using_in(1,2,3)
125 ns ± 3.82 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [4]: %timeit using_or(1,2,3)
119 ns ± 1.96 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

但更重要的是，这些决策几乎总是关于代码的清晰性或可维护性。性能差异通常可以忽略不计

老实说，如果您编写代码是为了在这个级别上进行优化，那么CPython可能不适合您

Answer 2

一方面，有一个constant-folding optimization将预计算常量元组，因此in (1, 2, 3)不会每次花费构建整个元组的费用。不需要每次都构建元组，in方法实际上比==方法具有更少的字节码解释开销和更快的运行速度

另一方面，这只适用于常量元组^当元组不是编译时常量时，{}通常较慢，例如in (x, y, z)。即使在in速度较慢的情况下，Pylint也会报告consider-using-in

我认为Pylint甚至会在in会改变代码含义的情况下报告consider-using-in，比如x == 1 or x == thing_with_side_effects()