是否需要“使用严格”的Python编译器？

Question

虽然存在static analysis tools for Python，但编译时检查往往与Python所包含的run-time binding philosophy截然相反。可以用静态分析工具包装标准的Python解释器，以强制执行一些类似“use strict”的约束，但是我们没有看到这种东西被广泛采用。

关于Python，是否有什么东西使得“使用严格”行为不必要或特别不受欢迎？

或者，Perl中的“使用严格”行为是否没有必要，尽管它已经被广泛采用？

注：我所说的“必要”是指“实际必要”，不是严格必要的。显然，您可以在不使用“use strict”的情况下编写Perl，但是（从我所看到的）大多数Perl程序员都使用它。

注意：Python解释器包装器不需要要求“使用严格的”类约束——您可以使用类似于“使用严格的”的伪pragma，该伪pragma将被普通解释器忽略。我不是说要添加一个语言级特性。

---

更新：解释“use strict”在Perl中的作用。（第一段是官方文件的链接。）

“use strict”指令有三个不同的组件，其中只有两个非常有趣：

• 使用严格变量：静态检查程序中词汇范围的变量用法。（请记住，在Python中，基本上只有global作用域和local作用域）。许多Python linter都会检查这种情况。因为这是他们唯一能做的静态分析，所以linter假设您使用直接的词法范围，并警告您在这个意义上出现错误的事情，直到您告诉他们闭嘴；即

  FOO = 12
  foo += 3
  

  如果你对你的名字空间不感兴趣，这对检查拼写错误很有用。

• 使用严格引用：防止符号命名空间取消引用。Python最接近的模拟是使用locals()和globals()来进行符号绑定和标识符查找。

• 使用严格的sub:Python中没有真正的模拟。

Answer 1

好吧，我不是一个很好的python程序员，但我会说答案是肯定的。

任何允许您随时创建具有任何名称的变量的动态语言都可以使用“strict”pragma。

Perl中的Strict vars（Perl中Strict的选项之一，“use Strict”一次将所有变量都打开）要求在使用之前声明所有变量。这意味着该代码：

my $strict_is_good = 'foo';
$strict_iS_good .= 'COMPILE TIME FATAL ERROR';

在编译时生成致命错误。

我不知道如何让Python在编译时拒绝此代码：

strict_is_good = 'foo';
strict_iS_good += 'RUN TIME FATAL ERROR';

您将得到一个运行时异常，即strict_iS_good未定义。但只有在代码被执行的时候。如果您的测试套件没有100%的覆盖率，您可以很容易地发布这个bug。

每当我在一种没有这种行为的语言（例如PHP）中工作时，我都会感到紧张。我不是一个完美的打字员。一个简单但很难发现的错误会导致代码以很难追踪的方式失败。

因此，重申一下，YESPython可以使用“strict”pragma来启用编译时检查，以检查在编译时可以检查的内容。我想不出还有什么可以添加的检查，但是一个更好的Python程序员可能会想到一些。

注意我关注Perl中stict vars的实用效果，并对一些细节进行了润色。如果你真的想知道所有的细节，请看the perldoc for strict。

更新：对一些评论的回复

Jason Baker：像pylint这样的静态检查程序很有用。但它们代表了一个额外的步骤，可以而且经常被跳过。在编译器中构建一些基本检查可以保证这些检查的执行是一致的。如果这些检查是由pragma控制的，那么甚至与检查成本有关的反对意见也就没有意义了。

popcnt：我知道python将生成运行时异常。我也这么说了。我主张尽可能进行编译时检查。请重读这篇文章。

mpeters：没有一个代码的计算机分析可以找到所有错误——这等于解决了停止问题。更糟糕的是，要在赋值中找到拼写错误，编译器需要知道您的意图并找到您的意图与代码不同的地方。这显然是不可能的。

但是，这并不意味着不应该进行检查。如果有一类问题很容易被发现，那么就有必要去捕捉它们。

我对pylint和pychecker还不够熟悉，不知道它们会捕获哪些类的错误。正如我所说，我对python非常缺乏经验。

这些静态分析程序很有用。但是，我相信除非它们复制了编译器的功能，否则编译器总是能够比任何静态检查器“了解”更多关于程序的信息。在可能的情况下，不利用这一点来减少错误似乎是浪费。

更新2:

理论上，我同意你的观点，静态分析器可以做任何编译器可以做的验证。对于Python来说，这就足够了。

但是，如果编译器足够复杂（特别是如果有很多改变编译方式的pragma，或者像Perl一样，可以在编译时运行代码），那么静态分析器必须接近编译器/解释器的复杂度才能进行分析。

嘿，所有关于复杂编译器和在编译时运行代码的讨论都显示了我的Perl背景。

我的理解是，Python没有pragmas，不能在编译时运行任意代码。所以，除非我错了或者添加了这些特性，否则静态分析器中相对简单的解析器就足够了。在每次执行时强制执行这些检查肯定会有帮助。当然，我这样做的方式是用一个pragma。

一旦将pragmas添加到组合中，就可以开始dow了在一个不稳定的斜坡上，分析器的复杂性必须与您在pragmas中提供的能力和灵活性成比例地增长。如果你不小心，你可以像Perl一样结束，然后“只有python可以解析python”，我不想看到未来。

也许命令行开关是添加强制静态分析的更好方法；）

（当我说Python不能像Perl那样使用编译时行为时，决不打算指责它的能力。我预感这是一个经过深思熟虑的设计决定，我可以从中看出其中的智慧。Perl在编译时的极端灵活性是，IMHO，这是语言的一大优势和一个可怕的弱点；我也看到了这种方法的智慧。）