Enforced by the Python interpreter. Double Leading and Trailing Underscore( __var__ ): Indicates special methods defined by the Python language. Avoid this naming scheme for your own attributes. Single Underscore( _ ): Sometimes used as a name for temporary or insignificant variables (“don't care”).
Double underscores are used for fully private variables. If your class is intended to be subclassed, and you have attributes that you do not want subclasses to use, consider naming them with double leading underscores and no trailing underscores.
A double underscore prefix causes the Python interpreter to rewrite the attribute name in order to avoid naming conflicts in subclasses. This is also called name mangling—the interpreter changes the name of the variable in a way that makes it harder to create collisions when the class is extended later.
Double Pre And Post Underscores. In Python, you will find different names which start and end with the double underscore. They are called as magic methods or dunder methods. This will lead to the clashes if you use these methods as your variable names.
From PEP 8:
_single_leading_underscore
: weak "internal use" indicator. E.g.
from M import *
does not import objects whose name starts with an underscore.
single_trailing_underscore_
: used by convention to avoid conflicts with Python keyword, e.g.
Tkinter.Toplevel(master, class_='ClassName')
__double_leading_underscore
: when naming a class attribute, invokes name mangling (inside classFooBar
,__boo
becomes_FooBar__boo
; see below).__double_leading_and_trailing_underscore__
: "magic" objects or attributes that live in user-controlled namespaces. E.g.__init__
,__import__
or__file__
. Never invent such names; only use them as documented.
Also, from David Goodger's Code Like a Pythonista:
Attributes:
interface
,_internal
,__private
But try to avoid the
__private
form. I never use it. Trust me. If you use it, you WILL regret it later.Explanation:
People coming from a C++/Java background are especially prone to overusing/misusing this "feature". But
__private
names don't work the same way as in Java or C++. They just trigger a name mangling whose purpose is to prevent accidental namespace collisions in subclasses:MyClass.__private
just becomesMyClass._MyClass__private
. (Note that even this breaks down for subclasses with the same name as the superclass, e.g. subclasses in different modules.) It is possible to access__private
names from outside their class, just inconvenient and fragile (it adds a dependency on the exact name of the superclass).The problem is that the author of a class may legitimately think "this attribute/method name should be private, only accessible from within this class definition" and use the
__private
convention. But later on, a user of that class may make a subclass that legitimately needs access to that name. So either the superclass has to be modified (which may be difficult or impossible), or the subclass code has to use manually mangled names (which is ugly and fragile at best).There's a concept in Python: "we're all consenting adults here". If you use the
__private
form, who are you protecting the attribute from? It's the responsibility of subclasses to use attributes from superclasses properly, and it's the responsibility of superclasses to document their attributes properly.It's better to use the single-leading-underscore convention,
_internal
. "This isn't name mangled at all; it just indicates to others to "be careful with this, it's an internal implementation detail; don't touch it if you don't fully understand it". It's only a convention though.
A single leading underscore is simply a convention that means, "You probably shouldn't use this." It doesn't do anything to stop someone from using the attribute.
A double leading underscore actually changes the name of the attribute so that two classes in an inheritance hierarchy can use the same attribute name, and they will not collide.
There is no access control in Python. You can access all attributes of a class, and that includes mangled names (as _class__variable
). Concentrate on your code and API instead of trying to protect developers from themselves.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With