我在Eclipse中使用PyDev，并且我有一些仅在运行时设置的属性。通常我可以像这样解决PyDev的错误：
obj.runtime_attr # @UndefinedVariable
但是，由于我的陈述很长，因此，对于PEP8，多行，它看起来像这样：
some.long.statement.\
with.multiline(obj.runtime_attr).\
more()
现在我无法添加@UndefinedVariable，因为它会中断行继续（PEP8要求在行结束注释之前有两个空格）。但是，我不能把它放在行的末尾（它只是不起作用）：
some.long.statement.\
with.multiline(obj.runtime_attr).\
more() # @UndefinedVariable
有什么方法可以解决这个问题吗？这只是一个缺失的功能，你不能正确吗？
答案 0 :(得分：0)
首先，请记住the most important rule of PEP 8是：
但最重要的是：知道何时不一致 - 有时风格指南不适用。如有疑问，请使用您的最佳判断。查看其他示例并确定最佳效果。
它特别指出要避免一条规则：
应用规则会使代码的可读性降低，即使对于习惯阅读遵循规则的代码的人也是如此。
话虽如此，你已经违反了PEP 8的字母和精神，只要拥有这些代码，除非你不能避免它而不会让事情变得更糟。正如Maximum Line Length所说，使用反斜杠延续是处理长行的最不优选的方法。最重要的是，它特别说“确保适当地缩进续行”，这是你没有做的。
解决这个问题的明显方法是使用一些中间变量。这不是C ++;没有“复制构造函数”成本需要担心。在一个现实生活中的例子中（与这个玩具示例不同），你可以想出的好名字比他们取代的长表达更有意义。
intermediate = some.long.statement
multiline = intermediate.with.multiline(obj.runtime_attr)
more = multiline.more()
如果这不合适，正如PEP 8明确指出的那样，最好依靠括号延续而不是反斜杠延续。这可行吗？肯定的是：
some.long.statement.with.multiline(
obj.runtime_attr).more()
或者，如果最坏的情况发生：
(some.long.statement.
with.multiline(obj.runtime_attr).more())
这有时会降低可读性而不是更多，在这种情况下你不应该这样做。但它始终是一种选择。如果你不得不竭尽全力为你做反斜杠继续工作，它可能会比过度括号的最严重过度更糟糕。
无论如何，以这些方式做事意味着你可以对每一行的结尾发表评论，所以你的问题一开始就不会出现。