关于将布尔值与True或False进行比较的奇怪的PEP8建议>>

Question

在python PEP8的末尾，我正在阅读：

• 不要使用==将布尔值与True或False比较>

  Yes:   if greeting:
  No:    if greeting == True:
  Worse: if greeting is True:
  

  当布尔值为True时，我的建议没有问题，但是在检查False时听起来很奇怪

如果我想知道变量greeting是否为False，为什么我不应该写：

    if greeting == False:
如果我写if not greeting:，它将与上述陈述有非常不同的含义。如果问候语为None怎么办？如果它是空字符串怎么办？此PEP8命令是否意味着存储布尔值的变量应仅包含True或False，并且应避免对这些变量使用None？
在我看来，这看起来像是来自其他语言的带有静态类型的建议，至少与False相比，它与python不太匹配。

而且，有人知道为什么if greeting is True:比if greeting == True:更糟糕吗？我们是否还应该理解if greeting is False:也比if greeting == False:更糟糕？

在python PEP8的末尾，我正在阅读：不要使用==将布尔值与True或False进行比较是：如果问候语：否：如果问候语== True：更糟：如果问候语为True：我没有问题与...

Answer 1

据我理解，PEP的建议意味着，如果您可以合理确定foo的类型（通常是这种情况），那么测试显式错误值是多余的，并且会降低可读性。例如，在foo = [i for i in range(10) if i == x]中，您可以相当确定foo可以具有的唯一假值是[]（假设不引发任何异常）。在这种情况下，使用foo == []是多余的，而not foo更好。

另一方面，foo == []或foo == False的语义值有时更有价值，并且然后[IMHO]代替not foo使用应该

Answer 2

我相信您读错了。尽量不要将greeting看作是名词，而不是动词（“我在问候”而不是“这是问候”）。

您可以在PEP8的序言中看到线索：

Answer 3

这是鸭子打字的一部分。在Python中，您通常不希望将接受的内容限制为特定的类，而是限制为公开适当API的对象。例如，我可以这样做：

class MyProperty(object):
    """
    A file-backed boolean property.
    """
    def __init__(self, filename):
        self.value = open(filename).read()
    def __nonzero__(self):
        return self.value != "0"
    def save_to_disk(self):
        # ... and so on
        pass

def func(enabled):
    if not enabled:
        return
    # ...

enable_feature = MyProperty("enable_feature")
func(enable_feature)

Answer 4

不通过==或!=比较来比较真相的最简单的原因似乎是：

0 is False # Result: False
0 == False # Result: True; 0 evaluates comparatively to False

1 is True  # Result: False  
1 == True  # Result: True; 1 evaluates comparatively to True

Answer 5

我不确定其他评论是否回答了您的问题。你说：

如果我写if not greeting:，它将与上述陈述有非常不同的含义。 如果问候语为None怎么办？如果它是空字符串怎么办？

Answer 6

我通常以模式IsName命名我的布尔变量，因此在您的情况下为IsGreeting。这使支票读取为if IsGreeting / if not IsGreeting，这非常直观。

您用if not描述的歧义是在布尔比较中使用非布尔类型的结果。通常应该避免这种情况，因为这非常令人困惑。