Name mangling has been the answer to the protection of private instance variables so far. However, is it still the best, the only way and the future to protect the private instance variables? I have backgrounds on many languages. Given the dynamic language nature of Python, it is understood that name mangling provide the protection needed. It is weird that from time to time, name mangling still stir something in my mind as it is more of the convention than the actual abstractions that exist in Python. Examples of the excellent abstraction are annotation, decorator, map, reduce, filter, polymorphism via magic method and more. Name mangling looks more like hacking to get things to work and this hacking is fragile with no true privacy protection like c++, java and c#. Why can’t the syntax or the dynamic part of python be enhanced so that the compiler or JIT compiler at run-time would be able to provide the true privacy protection via some abstract approach? The private instance variable needs the private marker. As long as the private marker may be calculated statically or dynamically from the mathematic perspective, the true protection may be achieved like other languages. What exactly stops Python from having such a thing?
Name mangling isn’t a way for private attributes to begin with. It’s a way to make it less likely for a subclass to override the name, which is desirable in some cases. The attribute is still accessible just like all other attributes.
Python does not have a concept of attribute visibility. It does have a convention with certain names, but nothing beyond that.
It’s worth noting that privacy protection can be bypassed fairly easily in C++. Even with compiler support, it’s still important to keep in mind that “private” and “public” are a courtesy between module authors, not a legal limitation; broadly speaking, it’s a promise that “if you only use the public attributes, I won’t break your code in an update”. As such, a single leading underscore represents this contract just as well as a declaration “private: int x” on the attributes.
The python devs don’t see a need for private variables. Name mangelings motivation isn’t actually encapsulation, but preventing conflicts with subclasses. So if you want a different feature to somehow actually enforce private variables, you first have to argue that this is actually a desirable property.
In C++, there is the cost of a few lines of code to “fairly easily” bypass the privacy protection. You have to do it on purpose. Same is true to java and c#. I have been a software architect for years and have observed that developers don’t conform to the rules, conventions and best practices due to a variety of reasons such as oversight, typo and so on. You name it. This causes the slowdown of the productivity. More often, bugs are introduced and the cost to fix the bug are dollars and time. Trust me. I read all the comments before. What drives me to write this topic is to see if the community truly believes what has been said in the real world. 
Yes, and in Python, you have to put a ._ in the attribute access. It’s not hard to recognize when it’s being done. Do you peer review code? Best practices can be enforced at the organizational level, but never at the language level.
The inconvenience from name mangling is the thing to make ya think twice before using the thing you’re trying to to use.
I think as a result it has a very similar effect as private things in other languages.
Trying to go further makes me think of security by obscurity.
Yes, I think that the current name mangling is not the best. It is not so uncommon to have a subclass having the same name as a class, but in different module. Name conflicts are possible. I think that it would be better to use more sofisticate name mangling, including the fully qualified name of the class. But it is perhaps not the problem that needs to be solved right now.
On other hand, private attributes are not widely used, neither in the stdlib, nor in the third-party code. Perhaps because how inconvenient they are if you want to break abstractions (and you need to do this all the time for debugging, testing, and “temporary” fixes).