PEP 8 建议使用单个尾随下划线以避免与 python 关键字冲突，但是与标准 python 模块的模块名称冲突怎么办？这也应该是一个单一的尾随下划线吗？
我在想象这样的事情：
import time
time_ = time.time()
【问题讨论】：
_file 和 _id 局部变量重命名为 file_ 和 id_...
PEP 8 似乎没有直接解决这个问题。
当您与关键字发生冲突时，结尾的下划线显然是必要的，因为否则您的代码会引发SyntaxError（或者，如果您真的不走运，编译为完全意味着某事与您的预期不同）。
因此，即使在您想要命名为class 的类属性、实例属性、函数参数或局部变量的上下文中，您也必须改用class_。
但time 并非如此。而且我认为在这些情况下，您不应该为time 添加下划线。
这是有先例的——stdlib 本身中的多个类具有名为 time 的方法或数据属性（它们都没有 time_）。
当然，您会在与模块相同的范围内创建名称（通常意味着全局变量或函数）。那么你就有更多的混淆可能性，并且在当前范围的其余部分隐藏了访问 time 模块上任何内容的能力。
我认为 90% 的情况下，答案将是“这不应该是全球性的”。
但这仍然剩下另外 10%。
还有一种情况是你的名字在一个受限的命名空间中，但是这个命名空间是一个函数内部的一个局部范围，你需要访问time模块。
或者，也许，在一个冗长而复杂的函数中（你不应该有任何一个，但是……有时你会这样做）。如果对人类读者来说time 是本地而不是模块并不明显，那与混淆解释器一样糟糕。
在这里，我认为剩下 99% 的时间，答案是“随便取个名字”。
例如看这段代码：
def dostuff(iterable):
time = time.time()
for thing in iterable:
dothing(thing)
return time.time() - time # oops!
这里的明显答案是重命名变量start 或t0 或其他名称。除了解决问题，它也是一个更有意义的名字。
但这仍然剩下 1%。
例如，有些库会根据协议规范或 .NET 或 ObjC 接口生成 Python 代码，但这些名称不受您的控制；您所能做的就是对翻译后的名称应用某种程序化且明确的规则。在这种情况下，我认为将_ 附加到 stdlib 模块名称和关键字的规则可能是个好主意。
您可能会想出其他示例，其中变量不能随意重命名，并且必须（至少可能）与time 模块位于相同的范围内，等等。在任何这种情况下，我都会选择_ 后缀。
【讨论】：
time_。但我怀疑这在你的整个编码生涯中永远不会出现。