PEP 8建议使用单个尾部下划线,以避免与python关键字冲突,但如果与标准python模块的模块名称冲突怎么办?这也应该是一个尾部下划线吗?
我的想象是这样的:
import time
time_ = time.time()
发布于 2013-04-19 08:24:31
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
模块位于相同的作用域中,等等。在任何这样的情况下,我都会使用_
后缀。
https://stackoverflow.com/questions/16095188
复制相似问题