Many languages have a notion of 'private' variables that can't be accessed from outside an object. For example, if we were sending someone sensitive information, we might not want to give people direct access to it.
Instead, we usually have 'public' accessor "get" and mutator "set" methods, which negotiate getting or changing private variables, for example checking the variable isn't in use or asking for a password.
a = object.getVariableA()
object.setVariableA(20)
Indeed, accessor and mutator methods are generally regarded as good practice whatever the data: it's generally bad practice to access variables directly as you have no idea what else is using them.
Application Programming Interfaces
Infact, it is usual to hide any variables and methods that outside code doesn't need access, limiting interactions to a clean and clear set of public methods.
These public methods are the Application Programming Interface (API) of the code; the bits for connecting to it.
These are often the bits described in the API documentation, often called the API or docs for short.
This is part of Design by Contract: the idea that you design the public connections between code as the main program structure achieving a goal, allowing implementations within the code to be background detail.
Private
In Python the security aspects of access control are less key, as the code is distributed as open text.
Nevertheless, you can informally hide variables if there's no reason for outside code to interact with it.
A function/method or variable name begun with an _underscore will informally be hidden when public descriptions of the code are made (for example, by dir(object) )
Private
In addition, there is a chance that you want to make variables such that they can't be overridden by subclasses.
If I make a variable in the sub and super classes, the subclass one will replace the superclass one, potentially causing issues if superclass methods are run.
This is usually dealt with by making variables private, but in the absence of that option python engages in name mangling. Any label starting with at least two leading __underscores and at most one trailing underscore is replaced with _ClassName__name. This prevents subclasses accidentally overriding it.