Access to **private** variables of a class in Python - variables

Question

I understand that Python does not explicitly support private variables in a class. However, please consider the following program:
class AClass(object):
def __init__(self, x):
self.__x = x
class BClass(object):
def __init__(self, x):
self.__x = x
# _____________________________________________________________________________
aClass = AClass(10)
bClass = BClass(10)
aClass.__x = 15
print (aClass.__x)
##bClass.__x = 20
print (bClass.__x)
The program above, will produce following error:
AttributeError: 'BClass' object has no attribute '__x'
But, if the second last line of code is uncommented, it will execute without an error.
If someone can please clarify what appears to be an inconsistency and if there is a PEP that explains this behaviour, I would appreciate a pointer to it.
Best regards.
BD

Answer 1

It's because variables starting with a dunder are name mangled to "protect" them. If you examine the dictionary of bClass, you'll see:
>>> print(bClass.__dict__)
{'_BClass__x': 10, '__x': 20}
The _BClass__x (I'll call this the object variable) was created by the object itself, hence its mangled name. The __x was created outside of the class(a) which is why it has a non-mangled name, and therefore why you can access it with just __x.
To access the object variable for both types, you can use:
print (aClass._AClass__x)
print (bClass._BClass__x)
But I'm not sure how reliable that is. I am sure that it's something you probably shouldn't be doing however, since it breaks encapsulation :-)
In fact, though I said the mangling was done by the object, I want to make sure you understand it's not done when an object is instantiated. The actual mangling happens when the code is compiled, which you can see if you disassemble:
>>> import dis
>>> dis.dis(AClass)
Disassembly of __init__:
3 0 LOAD_FAST 1 (x)
2 LOAD_FAST 0 (self)
4 STORE_ATTR 0 (_AClass__x)
6 LOAD_CONST 0 (None)
8 RETURN_VALUE
The STORE_ATTR bytecode actually knows to use a mangled name.
(a) And it is very much distinct from the object variable, as you'll find to your distress when you later try to use __x within a member function and find it hasn't been changed by your code outside :-)