是否有python命名约定来避免与标准模块名称冲突? [英] Is there a python naming convention for avoiding conflicts with standard module names?

问题描述

PEP 8 建议使用单个结尾下划线以避免与python关键字冲突，但是与标准python模块的模块名称冲突又如何呢?那也应该是一个下划线吗?

PEP 8 recommends using a single trailing underscore to avoid conflicts with python keywords, but what about conflicts with module names for standard python modules? Should that also be a single trailing underscore?

我正在想像这样的东西:

I'm imagining something like this:

import time
time_ = time.time()

推荐答案

PEP 8似乎无法直接解决.

PEP 8 doesn't seem to address it directly.

当您与关键字冲突时，尾随的下划线显然是必需的，因为您的代码否则会引发SyntaxError(或者，如果您真的很不幸，则编译为完全含义)与您预期的不同).

The trailing underscore is obviously necessary when you're colliding with a keyword, because your code would otherwise raise a SyntaxError (or, if you're really unlucky, compile to mean something completely different than you intended).

因此，即使在具有要命名为class的类属性，实例属性，函数参数或局部变量的上下文中，也必须改为使用class_.

So, even in contexts where you have a class attribute, instance attribute, function parameter, or local variable that you want to name class, you have to go with class_ instead.

但time并非如此.我认为在这种情况下，您不应该在time后面加上下划线.

But the same isn't true for time. And I think in those cases, you shouldn't postfix an underscore for time.

有一个先例-stdlib中的多个类本身具有名为time的方法或数据属性(而没有一个具有time_).

There's precedent for that—multiple classes in the stdlib itself have methods or data attributes named time (and none of them have time_).

当然，在某些情况下，您要在与模块相同的作用域内创建名称(通常表示全局变量或函数).这样一来，您就有了更多的混淆可能，并且可以隐藏当前范围内其余部分访问time模块上任何内容的功能.

Of course there's the case where you're creating a name at the same scope as the module (usually meaning a global variable or function). Then you've got much more potential for confusion, and hiding the ability to access anything on the time module for the rest of the current scope.

我认为90％的时候答案是那不应该是全球性的".

I think 90% of the time, the answer is going to be "That shouldn't be a global".

但这仍然剩下其他10％.

But that still leaves the other 10%.

在某些情况下，您的名字是在受限制的名称空间中，但是该名称空间是函数内部的局部作用域，您需要访问time模块.

And there's also the case where your name is in a restricted namespace, but that namespace is a local scope inside a function where you need to access the time module.

或者，也许是在一个漫长而复杂的函数中(您不应该拥有任何函数，但是……有时却可以).如果对于人类读者来说，time是本地变量而不是模块不是很明显，那就像混淆解释器一样糟糕.

Or, maybe, in a long, complicated function (which you shouldn't have any of, but… sometimes you do). If it wouldn't be obvious to a human reader that time is a local rather than the module, that's just as bad as confusing the interpreter.

在这里，我认为剩余时间中有99％的答案是只要选择一个不同的名字"即可.

Here, I think that 99% of the remaining time, the answer is "Just pick a different name".

例如，看下面的代码:

def dostuff(iterable):
    time = time.time()
    for thing in iterable:
        dothing(thing)
    return time.time() - time # oops!

最明显的答案是重命名变量start或t0或其他名称.除了解决问题之外，它也是一个更有意义的名称.

The obvious answer here is to rename the variable start or t0 or something else. Besides solving the problem, it's also a more meaningful name.

但这仍然剩下1％.

例如，有一些库可以根据协议规范，.NET或ObjC接口生成Python代码，而这些名称不在您的控制之下.您所要做的就是将某种程序化且明确的规则应用于翻译后的名称.在那种情况下，我认为将_附加到stdlib模块名称以及关键字的规则可能是个好主意.

For example, there are libraries that generate Python code out of, say, a protocol specification, or a .NET or ObjC interface, where the names aren't under your control; all you can do is apply some kind of programmatic and unambiguous rule to the translated names. In that case, I think a rule that appends _ to stdlib module names as well as keywords might be a good idea.

您可能还会想到其他示例，其中的变量不能只是被随意重命名，并且必须(至少可能)与time模块处于同一范围内，依此类推.在任何情况下，我都会使用_后缀.

You can probably come up with other examples where the variable can't just be arbitrarily renamed, and has to (at least potentially) live in the same scope as the time module, and so on. In any such cases, I'd go for the _ suffix.

这篇关于是否有python命名约定来避免与标准模块名称冲突?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！