当前位置：文江博客话题详情

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

发布于 2024-07-14 11:38:16 字数 1363 浏览 13 评论 0原文

存在Python 静态分析工具，但编译时检查往往与运行时绑定哲学截然相反 Python 所拥抱的。可以使用静态分析工具包装标准 Python 解释器来强制执行一些“使用严格的“类似约束，但我们没有看到这样的事情被广泛采用。

Python 是否有某些东西使得“使用严格”行为变得不必要或特别不可取？

或者，尽管 Perl 被广泛采用，但“use strict”行为在 Perl 中是否不必要？

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

注意：Python 解释器包装器不需要要求“use strict”之类的约束——您可以使用类似于“use strict”的伪编译指示，普通解释器会忽略它。我不是在谈论添加语言级功能。

更新：根据评论解释 Perl 中“use strict”的作用。（官方文档的链接位于第一段中。）

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

use strict vars：静态检查程序中词法作用域变量的使用情况。（请记住，在 Python 中，基本上只有 global 作用域和 local 作用域）。许多 Python linter 都会检查此类事情。由于这是它们能做的唯一静态分析，所以 linters 假设您使用简单的词法范围，并警告您在这个意义上出现错误的事情，直到您告诉它们闭嘴为止；即
<前><代码>FOO = 12 富+= 3
如果您没有对命名空间做任何花哨的事情，这对于检查拼写错误可能很有用。
使用严格引用：防止符号命名空间解除引用。 Python 最接近的模拟是使用 locals() 和 globals() 进行符号绑定和标识符查找。
使用严格的 subs：Python 中没有真正的模拟。

原文

There exist static analysis tools for Python, but compile time checks tend to be diametrically opposed to the run-time binding philosophy that Python embraces. It's possible to wrap the standard Python interpreter with a static analysis tool to enforce some "use strict"-like constraints, but we don't see any widespread adoption of such a thing.

Is there something about Python that makes "use strict" behavior unnecessary or especially undesirable?

Alternatively, is the "use strict" behavior unnecessary in Perl, despite its widespread adoption?

Note: By "necessary" I mean "practically necessary", not strictly necessary. Obviously you can write Perl without "use strict," but (from what I've seen) most Perl programmers do use it.

Note: The Python interpreter-wrapper need not require "use strict"-like constraints -- you could use a pseudo-pragma similar to "use strict" that would be ignored by the normal interpreter. I'm not talking about adding a language-level feature.

Update: Explaining what "use strict" does in Perl per comments. (Link to official docs is in the first paragraph.)

The "use strict" directive has three distinct components, only two of which are really interesting:

use strict vars: Statically checks lexically scoped variable usage in your program. (Keep in mind that, in Python, there is basically only global scope and local scope). Many Python linters check for this sort of thing. Since it's the only static analysis that they can do, the linters assume you use straightforward lexical scoping and warn you about things that appear wrong in that sense until you tell them to shut up; i.e.
```
FOO = 12
foo += 3
```
If you're not doing anything fancy with your namespaces this can be useful to check for typos.
use strict refs: Prevents symbolic namespace dereferencing. Python's closest analog is using locals() and globals() to do symbolic binding and identifier lookup.
use strict subs: No real analog in Python.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

ゃ人海孤独症 2024-07-21 11:38:16

好吧，我不是一个 Python 程序员，但我想说答案是“是”。

任何允许您随时创建具有任何名称的变量的动态语言都可以使用“严格”编译指示。

Perl 中的严格变量（Perl 中严格的选项之一，“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% 的覆盖率，您可以轻松地传递此错误。

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

因此，重申一下，Python 可以使用“严格”编译指示来打开编译时检查，以检查可以在编译时检查的内容。我想不出要添加任何其他检查，但更好的 Python 程序员可能会想到一些。

注意我关注 Perl 中 stic 变量的实用效果，并掩盖了一些细节。如果您确实想了解所有详细信息，请参阅严格的 perldoc。

更新：对一些评论的回应

Jason Baker：像 pylint 这样的静态检查器很有用。但它们代表了一个可以而且经常被跳过的额外步骤。在编译器中构建一些基本检查可以保证这些检查的执行一致。如果这些检查可以通过编译指令控制，那么即使与检查成本有关的反对意见也变得毫无意义。

popcnt：我知道python会生成运行时异常。我也说了这么多。我主张尽可能检查编译时。请重读该帖子。

mpeters：计算机对代码的分析无法找到所有错误——这相当于解决停机问题。更糟糕的是，要查找赋值中的拼写错误，编译器需要了解您的意图并找到您的意图与代码不同的地方。这显然是不可能的。

但这并不意味着不应该进行检查。如果存在易于检测的问题类别，那么捕获它们就有意义。

我对 pylint 和 pychecker 不太熟悉，无法说出它们会捕获哪些类型的错误。正如我所说，我对 python 非常缺乏经验。

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

更新2：

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

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

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

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

一旦将编译指示添加到混合中，您就开始走下坡路，分析器的复杂性必须与您在编译指示中提供的功能和灵活性成比例地增长。如果你不小心，你可能会像 Perl 一样，然后“只有 python 可以解析 Python”，这是我不想看到的未来。

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

（当我说 Python 不能像 Perl 那样对编译时行为进行模糊处理时，我绝对无意指责 Python 的功能。我有预感，这是一个经过深思熟虑的设计决定，恕我直言，我可以看到 Perl 在编译时的极端灵活性，这是该语言的一个巨大优势，也是一个可怕的弱点；我也看到了这种方法的智慧。）

Well, I'm not much of a python programmer, but I'd say that the answer is 'YES'.

Any dynamic language that lets you create a variable with any name at any time, could use a 'strict' pragma.

Strict vars (one of the options for strict in Perl, 'use strict' turns them all on at once) in Perl requires that all variables are declared before they are used. Which means that this code:

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

Generates a fatal error at compile time.

I don't know of a way to get Python to reject this code at compile time:

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

You will get a run-time exception that strict_iS_good is undefined. But only when the code is executed. If your test suite does not have 100% coverage, you can easily ship this bug.

Any time I work in a language that does not have this behavior (PHP for example), I get nervous. I am not a perfect typist. A simple, but hard to spot, typo can cause your code to fail in ways that may be hard to track down.

So, to reiterate, YES Python could use a 'strict' pragma to turn on compile time checks for things that can be checked at compile time. I can't think of any other checks to add, but a better Python programmer probably could think of some.

Note I focus on the pragmatic effect of stict vars in Perl, and am glossing over some of the details. If you really want to know all the details see the perldoc for strict.

Update: Responses to some comments

Jason Baker : Static checkers like pylint are useful. But they represent an extra step that can be and often is skipped. Building some basic checks into the compiler guarantees that these checks are performed consistently. If these checks are controllable by a pragma, even the objection relating to the cost of the checks becomes moot.

popcnt : I know that python will generate a run time exception. I said as much. I advocate compile time checking where possible. Please reread the post.

mpeters : No computer analysis of code can find all errors--this amounts to solving the halting problem. Worse, to find typos in assignments, your compiler would need to know your intentions and find places where your intentions differ from your code. This is pretty clearly impossible.

However this does not mean that no checking should be done. If there are classes of problems that are easy to detect, then it makes sense to trap them.

I'm not familiar enough with pylint and pychecker to say what classes of errors they will catch. As I said I am very inexperienced with python.

These static analysis programs are useful. However, I believe that unless they duplicate the capabilities of the compiler, the compiler will always be in a position to "know" more about the program than any static checker could. It seems wasteful not to take advantage of this to reduce errors where possible.

Update 2:

cdleary - In theory, I agree with you, a static analyzer can do any validation that the compiler can. And in the case of Python, it should be enough.

However, if your compiler is complex enough (especially if you have lots of pragmas that change how compilation occurs, or if like Perl, you can run code at compile time), then the static analyzer must approach the complexity of the compiler/interpreter to do the analysis.

Heh, all this talk of complex compilers and running code at compile time shows my Perl background.

My understanding is that Python does not have pragmas and can not run arbitrary code at compile time. So, unless I am wrong or these features are added, a relatively simple parser in the static analyzer should suffice. It certainly would be helpful to force these checks at every execution. Of course, the way I'd do this is with a pragma.

Once you add pragmas to the mix, you have started down a slippery slope and the complexity of you analyzer must grow in proportion to the power and flexibility you provide in your pragmas. If you are not careful, you can wind up like Perl, and then "only python can parse Python," a future I wouldn't want to see.

Maybe a command line switch would be a better way to add forced static analysis ;)

(In no way do intend to impugn Python's capabilities when I say that it can't futz with compile time behavior like Perl can. I have a hunch that this is a carefully considered design decision, and I can see the wisdom in it. Perl's extreme flexibility at compile time is, IMHO, a great strength and a terrible weakness of the language; I see the wisdom in this approach as well.)

回复收藏 0 原文

戒ㄋ 2024-07-21 11:38:16

Python 确实有一些可以改变脚本语法的东西：

from __future__ import print_function

以及具有语法含义的各种其他未来功能。只是Python的语法比历史上的Perl更严格、更稳定、定义更明确； Python 中从来不存在“严格引用”和“严格替换”所禁止的事情。

'strict vars' 主要是为了阻止错误的引用和遗漏的 'my's 创建意外的全局变量（嗯，Perl 术语中的包变量）。这在 Python 中不会发生，因为裸赋值默认为本地声明，而裸未赋值的符号会导致异常。

（仍然存在这样的情况：用户意外地尝试直写全局变量，而没有使用“全局”语句声明它，从而导致意外的本地错误，或者更常见的是 UnboundLocalError。这往往很快就能学会，但它是一个有争议的情况，必须声明本地变量可能会有所帮助，尽管很少有经验丰富的 Python 程序员会接受可读性负担。）

不涉及语法的其他语言和库更改是通过警告系统。

Python does have something that can change script syntax:

from __future__ import print_function

and various other future-features that have syntax implications. It's just that Python's syntax has been stricter, stabler and more well-defined than historical Perl; the kind of things that ‘strict refs’ and ‘strict subs’ prohibit have never existed in Python.

‘strict vars’ is primarily intended to stop typoed references and missed-out ‘my’s from creating accidental globals (well, package variables in Perl terms). This can't happen in Python as bare assignments default to local declaration, and bare unassigned symbols result in an exception.

(There is still the case where users accidentally try to write-through to a global without declaring it with a ‘global’ statement, causing either an accidental local or, more often, an UnboundLocalError. This tends to be learned fairly quickly, but it is an arguable case where having to declare your locals could help. Although few experienced Python programmers would accept the readability burden.)

Other language and library changes that do not involve syntax are handled through the warnings system.

回复收藏 0 原文

爱你不解释 2024-07-21 11:38:16

“Python 所拥护的运行时绑定理念……使得“使用严格”行为变得不必要，并且特别不可取”

非常好的总结。谢谢。

本质上就是这样。静态分析工具对 Python 的帮助不够，不值得。

编辑

“我要求我们反思为什么我们不需要它，以及相关的为什么 Perl 程序员认为他们确实需要它。”

原因正是您已经给出的原因。我们不需要它，因为它没有帮助。显然，你不喜欢这个答案，但也没什么可说的了。编译时或预编译时检查根本没有帮助。

但是，既然您花时间再次提出问题，我将为您已经给出的答案提供更多证据。

我写 Java 的次数几乎和写 Python 一样多。 Java的静态类型检查并不能防止任何逻辑问题；它不利于满足性能要求；它无助于满足用例。它甚至没有减少单元测试的量。

虽然静态类型检查确实可以发现方法偶尔的误用，但在 Python 中您也能很快发现这一点。在 Python 中，您可以在单元测试时找到它，因为它不会运行。注意：我并不是说通过大量聪明的单元测试可以发现错误的类型，我是说大多数错误的类型问题是通过未处理的异常发现的，在这些异常中，事情根本无法运行足够远来测试断言。

Python 爱好者不会在静态检查上浪费时间的原因很简单。我们不需要它。它不提供任何价值。这是一个没有经济效益的分析水平。它并不能让我更有能力解决人们使用真实数据遇到的实际问题。

查看与语言（而非问题域或库）相关的最流行的 SO Python 问题。

“foo is None”之间有什么区别和“foo == None”？ - == 与 is。静态检查对此无济于事。另请参阅 `==` 和 ` 之间有区别吗？在 Python 中是`？

**（双星）和* (star) 对参数做什么？ -- *x 给出一个列表，**x 给出一个字典。如果您不知道这一点，当您尝试执行不适合这些类型的操作时，您的程序将立即终止。 “如果你的程序从不做任何‘不适当’的事情怎么办？” 然后你的程序就可以运行了。 '纳夫说。

如何在 Python 中表示“枚举”？< /a>——这是对某种有限域类型的请求。具有班级级别值的班级几乎可以完成这项工作。 “如果有人改变任务怎么办”。易于构建。覆盖__set__以引发异常。是的，静态检查可能会发现这一点。不，实际上不会发生有人对枚举常量和变量感到困惑的情况。当它们发生时，很容易在运行时发现。 “如果逻辑永远不会被执行怎么办”。嗯，这是糟糕的设计和糟糕的单元测试。引发编译器错误并放入从未测试过的错误逻辑并不比从未测试过的动态语言中发生的情况更好。

生成器表达式与列表理解 - 静态检查无助于解决此问题。

为什么 1+++2 = 3？ -- 静态检查不会'没发现这个。尽管进行了所有编译器检查，C 中的 1+++2 是完全合法的。 Python 中的这与 C 中的不同，但同样合法。同样令人困惑。

意外地跨子列表反映的列表更改列表 - 这是完全是概念性的。静态检查也无助于解决这个问题。 Java 的等价物也会编译并表现得很糟糕。

"the run-time binding philosophy that Python embraces... makes "use strict" behavior unnecessary [and] especially undesirable"

Pretty good summary. Thanks.

That is essentially it. Static analysis tools don't help Python enough to be worthwhile.

Edit

"I'm asking for us to introspect on why we don't need it and, relatedly, why Perl programmers think they do need it."

The reason why is precisely the reason you already gave. We don't need it because it doesn't help. Clearly, you don't like that answer, but there's not much more to be said. Compile-time or pre-compile time checking simply does not help.

However, since you took the time to asked the question again, I'll provide more evidence for the answer you already gave.

I write Java almost as much as I write Python. Java's static type checking does not prevent any logic problems; it doesn't facilitate meeting performance requirements; it doesn't help meet the use cases. It doesn't even reduce the volume of unit testing.

While static type checking does spot the occasional misuse of a method, you find this out just as quickly in Python. In Python you find it at unit test time because it won't run. Note: I'm not saying wrong types are found with lots of clever unit tests, I'm saying most wrong type issues are found through unhandled exceptions where the thing simply won't run far enough to get to test assertions.

The reason why is Pythonistas don't waste time on static checking is simple. We don't need it. It doesn't offer any value. It's a level of analysis that has no economic benefit. It doesn't make me any more able to solve the real problems that real people are having with their real data.

Look at the most popular SO Python questions that are language (not problem domain or library) related.

Is there any difference between "foo is None" and "foo == None"? -- == vs. is. No static checking can help with this. Also, see Is there a difference between `==` and `is` in Python?

What does ** (double star) and * (star) do for parameters? -- *x gives a list, **x gives a dictionary. If you don't know this, your program dies immediately when you try to do something inappropriate for those types. "What if your program never does anything 'inappropriate'". Then your program works. 'nuff said.

How can I represent an 'Enum' in Python? -- this is a plea for some kind of limited-domain type. A class with class-level values pretty much does that job. "What if someone changes the assignment". Easy to build. Override __set__ to raise an exception. Yes static checking might spot this. No, it doesn't happen in practice that someone gets confused about an enum constant and a variable; and when they do, it's easy to spot at run time. "What if the logic never gets executed". Well, that's poor design and poor unit testing. Throwing a compiler error and putting in wrong logic that's never tested is no better than what happens in a dynamic language when it's never tested.

Generator Expressions vs. List Comprehension -- static checking doesn't help resolve this question.

Why does 1+++2 = 3? -- static checking wouldn't spot this. 1+++2 in C is perfectly legal in spite of all the compiler checking. It's not the same thing in Python as it is in C, but just as legal. And just as confusing.

List of lists changes reflected across sublists unexpectedly -- This is entirely conceptual. Static checking can't help solve this problem either. The Java equivalent would also compile and behave badly.

回复收藏 0 原文

转身以后 2024-07-21 11:38:16

从我看到的评论来看，我认为“use strict”的作用有些混乱。它不会打开编译时类型检查（就像 Java 一样）。从这个意义上说，Perl 程序员与 Python 程序员是一致的。正如 S.Lott 上面所说，这些类型的检查不能防止逻辑错误，不能减少需要编写的单元测试的数量，而且我们也不太热衷于束缚编程。

以下是“use strict”的作用列表：

使用符号引用是一个运行时错误。这可以防止你做疯狂的事情（但有时是有用的事情，比如）
$var = 'foo';
$foo = 'bar';
打印$$var; # 这将包含 $foo 的内容，除非在严格下运行
使用未声明的变量是一个运行时错误（这意味着您需要使用“my”、“our”或“local”来声明您的变量）
All裸字被认为是编译时语法错误。裸字是没有声明为符号或子例程的单词。这主要是为了禁止历史上做过但被认为是错误的事情。

回复收藏 0 原文

甜扑 2024-07-21 11:38:16

这个原始答案是正确的，但可能无法解释情况
从实际意义上来说。

Python 存在静态分析工具，但编译时检查往往与 Python 所拥护的运行时绑定理念截然相反。

Perl 中的“use strict”提供的是确保拼写错误的内容的能力
或者变量名（通常）在编译时被捕获。这确实改进了代码
可靠性，并加快开发速度。但为了让这样的事情变得有价值
你需要声明变量。 Python 风格似乎不鼓励这种做法。

所以在 Python 中，你永远不会发现拼写错误的变量，除非你注意到
运行时，您认为自己所做的分配并未进行，或者
表达式似乎解析为意外值。捕获此类错误可以是
耗时，尤其是当程序变得很大并且人们被迫维护时
别人开发的代码。

Java 和 C/C++ 更进一步，使用类型检查。动机很实际，
而不是哲学。如何尽快捕获尽可能多的错误，并确保在将代码发布到生产环境之前消除所有错误？
每种语言似乎都采取特定的策略并根据它们的内容来运行它
认为很重要。在像 Perl 这样不支持运行时绑定的语言中，
利用“use strict”使开发变得更容易是有意义的。

回复收藏 0 原文

陌若浮生 2024-07-21 11:38:16

Python 没有真正的词法作用域，因此严格的变量不是很明智。 AFAIK 它没有符号引用，因此不需要严格的引用。它没有裸字，因此不需要严格的变量。

老实说，我只是怀念词法范围。另外两个我认为是 Perl 中的缺陷。

回复收藏 0 原文

红尘作伴 2024-07-21 11:38:16

我认为 Perl 中的 'use strict' 更像是您暗示的编译指示：它改变了编译器的行为。

Perl 语言哲学与 Python 哲学不同。例如，在 Perl 中，你有足够多的绳子来反复上吊自己。

Larry Wall 对语言学很感兴趣，所以我们从 Perl 中得到了所谓的 TIMTOWTDI（比如 tim-toe-dee）原理与 Python 的 Zen 原理：

应该有一个——而且最好是
只有一种显而易见的方法。

你可以很容易地使用 pylint 和 PyChecker 为 python 提出你自己的 use strict 风格（或类似于 perl -cw *scriptname*），但是由于语言设计中的哲学不同，你在实践中不会广泛遇到这种情况。

根据您对第一张海报的评论，您熟悉 python 的 import this。其中有很多内容可以解释为什么您在 Python 中看不到与 use strict 等效的内容。如果你冥想Python禅宗中的公案，你可能会为自己找到启迪。 :)

回复收藏 0 原文

忆离笙 2024-07-21 11:38:16

我发现我只关心检测对未声明变量的引用。 Eclipse 通过 PyDev 进行了 pylint 集成，虽然 pylint 远非完美，但它在这方面做得还不错。

它确实有点违背 Python 的动态特性，当我的代码在某些方面变得聪明时，我确实必须偶尔添加 #IGNORE。但我发现这种情况很少发生，所以我对此很满意。

但我可以看到一些类似 pylint 的功能以命令行标志的形式可用。有点像 Python 2.6 的 -3 开关，它标识 Python 2.x 和 3.x 代码之间的不兼容点。

回复收藏 0 原文

爱你是孤单的心事 2024-07-21 11:38:16

在 Perl 中如果没有“use strict”就很难编写大型程序。
如果没有“use strict”，如果您再次使用某个变量，并且由于漏掉了一个字母而拼写错误，程序仍然会运行。如果没有测试用例来检查结果，您将永远无法发现此类错误。找出由于这个原因而得到错误结果的原因可能非常耗时。

我的一些 Perl 程序由 5,000 行到 10,000 行代码组成，这些代码分为数十个模块。如果没有“use strict”，就无法真正进行生产编程。我永远不会允许在工厂中使用不强制执行“变量声明”的语言安装生产代码。

这就是 Perl 5.12.x 现在将“use strict”作为默认行为的原因。您可以将它们关闭。

由于没有强制执行变量声明，PHP 给我带来了很多问题。所以你需要限制自己使用这种语言的小程序。

只是一个意见...

abcParsing

回复收藏 0 原文

爱你不解释 2024-07-21 11:38:16

正如他们所说，Perl 是一种不受约束的语言:)。所以你可以在声明之前使用该变量；例如：如果您使用变量名称“is_array”但输入“is_arrby”，则编译器不会在没有“use strict”的情况下报告错误。所以在perl中编写长程序时，最好使用“use strict”语句。当然，运行一次脚本少于50行，没有必要:)

回复收藏 0 原文

~没有更多了~