A brief introduction to the use of "_" in Python

0. Background

The underscore "_" in Python is much more frequent than other mainstream languages, and it has its own unique use in Python. This article focuses on: the use of underline in Python common sense.

1. Single underline-encapsulates a name into a class

If you want to encapsulate the "private" data in a class on an instance of a class, you need to consider Python's lack of access control to the property. Rather than relying on language features to encapsulate data, Python programmers expect specific naming conventions to express the use of data and methods.

The first rule is that any name that begins with a single underscore (_) should always be considered an internal implementation.

Like what:

 class A:     def __init__(self):Self._internal =0  # prefix joins "_", which is an "internal (internal)" attribute in the classSelf.public =1     # A public property in the # class     def public_method(slef):        ' a public method '        Pass     def _internal_method(self):        ' an internal (internal) method '        Pass

Python itself does not prevent others from accessing the internal name. But if someone does this, it is considered rude and can lead to the creation of fragile code. It should be mentioned that the following underlined prefixes are also available for module names and module-level functions. For example, if you see a module name with an underscore prefix (for example, _socket ), then it is an internal implementation. Similarly, module-level functions, such as sys._getframe() use, should be used with extreme caution.

2. Double Underline-Name reorganization ( name mangling)

We should also see a name prefixed with a double-glide line (__) in the class definition. For example:

class  b :  def  __init__   (self) :  self.__private =    Span class= "Hljs-number" >0  # name after reorganization: _b__private  def  __private_method  :   pass  def  public_method   (self) :  self. __private_method ()  

A name prefixed by a double underscore causes name mangling the behavior of the name reorganization () to occur. Such properties cannot be overridden by inheritance.

Specifically, the private properties in this class are renamed to _B__private and separately _B__private_method . In fact, the purpose of a name reorganization like this is to inherit--such a property cannot be overridden by inheritance.

class     c   (B) :  def  __init  :  super (). __init () self.__private = 1 # this statement does not overwrite b.__private   "This method does not overwrite B.__private_method ( Because the name is re-_b__private_method after the reorganization: "_c__private_method", and this function is restructured: " 
       
        def 
        __private_method   ( Self) :  pass   

Here, the private name is renamed __private __private_method to _C__ptvate and _C_private_method , which differs from the reorganization name in base class B.

The fact that the "private" attribute has two different naming conventions (single underline and double underline) raises the obvious question: which style should be used?

For most code, we should let the non-public name begin with a single underscore. However, if we know that subclasses are involved in the code, and some internal properties should be hidden from the child class, you should start with a double underscore.

3. Suffix single underline-avoids keyword collisions

It should also be noted that sometimes you might want to define a variable, but the name may conflict with the reserved word. Based on this, a single underline should be added at the end of the name to differentiate. Like what:

2.0# 添加后缀下划线_ ，以避免与关键字"lambda"冲突

The reason for not using the underscore prefix here is to avoid confusion with intent, and if it starts with an underscore, it might be interpreted as a private variable, rather than being considered to avoid a critical conflict.

A brief introduction to the use of "_" in Python