Who Can Access My Data?

Most object-oriented programming languages have a concept of access control. This is related to abstraction. Some attributes and methods on an object are marked private, meaning only that object can access them. Others are marked protected, meaning only that class and any subclasses have access. The rest are public, meaning any other object is allowed to access them.

Access of data in Python

Python doesn’t do this. Python doesn’t really believe in enforcing laws that might someday get in our way. Instead, it provides unenforced guidelines and best practices. Technically, all methods and attributes on a class are publicly available. If we want to suggest that a method should not be used publicly, we can put a note in docstrings indicating that the method is meant for internal use only (preferably, with an explanation of how the public-facing API works).

Internal data members

We often remind each other of this by saying, “We’re all adults here.” There’s no need to declare a variable as private when we can all see the source code. By convention, we generally prefix an internal attribute or method with an underscore character, _. Python programmers will understand a leading underscore name to mean this is an internal variable, think three times before accessing it directly. But there is nothing inside the interpreter to stop them from accessing it if they think it is in their best interest to do so. Because, if they think so, why should we stop them? We may not have any idea what future uses our classes might be put to, and it may be removed in a future release. It’s a pretty clear warning sign to avoid using it.

Name mangling

There’s another thing we can do to strongly suggest that outside objects don’t access a property or method: prefix it with a double underscore, __. This will perform name mangling on the attribute in question. In essence, name mangling means that outside objects can still call the method if they really want to do so, but it requires extra work and is a strong indicator that we demand that our attribute remains private.

When we use a double underscore, the property is prefixed with _<classname>. When methods in the class internally access the variable, they are automatically unmangled. When external classes wish to access it, they have to do the name mangling themselves. So, name mangling does not guarantee privacy; it only strongly recommends it. This is very rarely used, and often a source of confusion when it is used.

Tip: Don’t create new double-underscore names in your own code, it will only cause grief and heartache. Consider this reserved for Python’s internally defined special names.

Encapsulation

What’s important is that encapsulation—as a design principle—assures that the methods of a class encapsulate the state changes for the attributes. Whether or not attributes (or methods) are private doesn’t change the essential good design that flows from encapsulation.