后期绑定是否与“可靠性很重要”的哲学一致？

Question

我很抱歉所有人-我不是在这里责怪Python。这只是对我所相信的是否正确的反思。作为Python的拥趸两年来，我一直只编写小应用程序，无论我走到哪里，我都会唱起Python的赞歌。我最近有机会阅读了Django的代码，并开始怀疑Python是否真的遵循其“可读性很重要”的哲学。例如,

class A:
    a = 10
    b = "Madhu"

    def somemethod(self, arg1):
        self.c = 20.22
        d = "some local variable"
        # do something
        ....
        ...
    def somemethod2 (self, arg2):
        self.c = "Changed the variable"
        # do something 2
        ...

在实例变量是在使用时创建的情况下(即上述代码片段中的self.c )，很难跟踪代码流。在读取大量以这种方式编写的代码时，无法看到定义了哪些实例变量。即使在阅读一个只有6-8个方法并且不超过100-150行代码的类时，这也会变得非常令人沮丧。

我很想知道我对这段代码的理解是否受到C++/Java风格的影响，因为大多数其他语言都遵循与它们相同的方法。有没有一种Pythonic式的方法可以更流畅地阅读这段代码？是什么让Python开发人员在牢记“可读性”的情况下采用了这种策略？

Answer 1

您所呈现的代码片段非常不典型(这也可能是因为您可能是编造的)：

• 通常不会有一个实例变量(self.c)在某一点是一个浮点数，而在另一个点上是一个字符串。它应该总是一个数字或字符串。
• 你通常不会在一个任意的方法中将实例变量带入生活中。相反，你通常有一个初始化所有变量的构造函数(__init__)。
• 你通常没有名为a，b，c的实例变量。相反，它们有一些有说服力的名字。

解决了这些问题后，您的示例将更具可读性。

Answer 2

一个才华横溢的恶棍可以用任何语言写出难以阅读的代码。Python试图在结构和命名上强加一些规则，以推动程序员朝着正确的方向前进，但没有办法强制这样做。

为了更有价值，我试图将局部变量的范围限制在我使用的每种语言中使用的区域-对我来说，不需要维护巨大的心理字典会让我重新熟悉一些代码变得非常容易。

Answer 3

我同意你所看到的可能会令人困惑，应该伴随着文档。但是在任何语言中都可能发生令人困惑的事情。

在您自己的代码中，您应该应用使维护代码变得最容易的任何约定。关于这个特定的问题，有许多可能的事情可以帮助你。

• 使用像Epydoc这样的东西，你可以指定一个类将拥有的所有实例变量。在编写代码文档时要谨慎，并确保代码和文档保持同步。
• 采用的编码约定鼓励使用您认为最易于维护的代码类型。没有什么比树立一个好的例子更好的了。
• 让你的类和函数保持小巧和良好的定义。如果它们变得太大，就把它们拆分开来。如果你真的想要坚持在引用之前声明实例变量，你可以使用一些元类技巧( metaclass
• )。例如，您可以创建一个公共基类，该基类使用元类逻辑强制执行以下约定:只有在声明子类时声明的变量才能在以后进行设置。