Shulou(Shulou.com)06/03 Report--

This article shows you what the meaning of underlining in Python is, it is concise and easy to understand, and it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

1. Single leading underscore _ var

When it comes to variable and method names, a single underscore prefix has a conventional meaning. It is a hint for programmers-meaning that the Python community agrees on what it should mean, but the behavior of the program is not affected.

The underscore prefix means to tell other programmers that variables or methods that begin with a single underscore are for internal use only. This convention is defined in PEP8.

This is not mandatory by Python. Python does not have the strong distinction between "private" and "public" variables like Java. It's like someone put forward a little underlined warning sign and said:

"Hey, it's not really part of the public interface of the class. Just leave it alone."

Look at the following example:

ClassTest:

Def__init__ (self):

Self.foo=11

Self._bar=23

What happens if you instantiate this class and try to access the foo and _ bar properties defined in the _ _ init__ constructor? Let's take a look:

> > t=Test ()

> t.foo

eleven

> t._bar

twenty-three

You will see that a single underscore in _ bar does not prevent us from "entering" the class and accessing the value of the variable.

This is because a single underscore prefix in Python is just a convention-at least relative to variable and method names.

However, leading underscores do affect how names are imported from the module.

Suppose you have the following code in a module called my_module:

# Thisismy_module.py:

Defexternal_func ():

Return23

Def_internal_func ():

Return42

Now, if you import all names from a module using wildcards, Python will not import names with leading underscores (unless the module defines a _ _ all__ list that overrides this behavior):

> frommy_moduleimport*

> > external_func ()

twenty-three

> _ internal_func ()

NameError: "name'_internal_func'isnotdefined"

By the way, wildcard imports should be avoided because they make it unclear what names exist in the namespace. For the sake of clarity, it is better to stick to regular import.

Unlike wildcard imports, regular imports are not affected by leading individual underscore naming conventions:

> importmy_module

> > my_module.external_func ()

twenty-three

> > my_module._internal_func ()

forty-two

I know this may be a little confusing. If you follow PEP8 recommendations and avoid wildcard imports, that's all you really need to remember:

A single underscore is an Python naming convention that indicates that the name is for internal use. It is usually not enforced by the Python interpreter, but only as a hint to the programmer.

two。 Single end underlined var_

Sometimes, the most appropriate name of a variable is already occupied by a keyword. Therefore, names such as class or def cannot be used as variable names in Python. In this case, you can attach an underscore to resolve the naming conflict:

> > defmake_object (name,class):

SyntaxError: "invalidsyntax"

> > defmake_object (name,class_):

... pass

In summary, a single underscore (suffix) is a convention to avoid naming conflicts with the Python keyword. PEP8 explained the agreement.

3. Double leading underscore _ _ var

So far, the meaning of all the naming patterns we have covered comes from agreed conventions. For the properties (including variables and methods) of the Python class that starts with a double underscore, the situation is a little different.

The double underscore prefix causes the Python interpreter to override property names to avoid naming conflicts in subclasses.

This is also called name modification (namemangling)-the interpreter changes the name of the variable so that conflicts do not occur when the class is extended.

I know it sounds abstract. So, I combined a small code example to illustrate:

ClassTest:

Def__init__ (self):

Self.foo=11

Self._bar=23

Self.__baz=23

Let's look at the properties of this object with the built-in dir () function:

> > t=Test ()

> > dir (t)

['_ Test__baz','__class__','__delattr__','__dict__','__dir__'

'_ _ doc__','__eq__','__format__','__ge__','__getattribute__'

'_ _ gt__','__hash__','__init__','__le__','__lt__','__module__'

'_ _ ne__','__new__','__reduce__','__reduce_ex__','__repr__'

'_ _ setattr__','__sizeof__','__str__','__subclasshook__'

'_ _ weakref__','_bar','foo']

The above is a list of the properties of this object. Let's take a look at this list and look for our original variable names foo,_bar and _ _ baz-. I'm sure you'll notice some interesting changes.

The self.foo variable appears as unmodified to foo in the property list.

Self._bar behaves the same way-it appears on the class in the form of _ bar. As I said before, in this case, leading underlining is just an agreement. Just give the programmer a hint. For self.__baz, however, the situation looks a little different. When you search the list for _ _ baz, you won't see a variable with that name.

_ _ baz, what happened?

If you look closely, you will see that there is a property called _ Test__baz on this object. This is the name modification done by the Python interpreter. It does this to prevent variables from being overridden in subclasses.

What is the meaning of underlining in Python? have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.