The part of the article about an issue with name mangling of private fields is somehow misleading.

The feature is just some syntactic sugar.

When within a class, private fields such as:

    class Foo:
        def __init__(self):
            self.__bar

are accessible from within other methods of class Foo as `self.__bar`. But that's just syntactic sugar, the real name of `self.__bar` is `self._Foo__bar`.

So from the outside "world", including `hasattr()`, you can still access `self.__bar` as `Foo()._Foo__bar`.

    >>> class Foo():
    ...   def __init__(self):
    ...     self.__bar = 'hello'
    ...   def show(self):
    ...     print(1, self.__bar)
    ...     print(2, getattr(self, '__bar'))
    ... 
    >>> foo = Foo()
    >>> foo._Foo__bar
    True
    >>> foo.show()
    1 hello
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 6, in show
    AttributeError: 'Foo' object has no attribute '__bar'
    >>> foo.__bar = 'world'
    >>> foo.show()
    1 hello
    2 world

In the end, when `x.__private` is setup outside of the class definition, obviously, it's a new member as its name differs from the internal name `__private` (which really is `_X__private`).

From within the code doing `getattr('X', '__private')` will return the `__private` setup from outside the class, and `getattr('X', '_X__private')` the one defined from within the class.

The whole point of that feature is to ensure that members defined within a class that are not part of the public API are left untouched when that class get subclassed, to avoid unexpected behaviours.

Here's an example of why this has been designed:

  >>> class A:
  ...   def __init__(self):
  ...     self.__internal = "this is a"
  ...   def show(self):
  ...     print(1, "A", self.__internal)
  ... 
  >>> class B(A):
  ...   def __init__(self):
  ...     super(B, self).__init__()
  ...     self.__internal = "this is b"
  ...   def show(self):
  ...     super(B, self).show()
  ...     print(2, "B", self._A__internal)
  ...     print(3, "B", self.__internal)
  ... 
  >>> B().show()
  1 A this is a
  2 B this is a
  3 B this is b
  >>> 

There's nothing that should be surprising or asymmetrical to anybody who've read the python documentation, and use that feature appropriately. It's maybe a weird feature, but it's still a coherent and homogeneous behaviour and actually adding more safety to codes.

Documentation references:

  * https://docs.python.org/3/faq/programming.html#i-try-to-use-spam-and-i-get-an-error-about-someclassname-spam
  * https://docs.python.org/3/reference/expressions.html#atom-identifiers