On Sun, Feb 1, 2009 at 2:29 PM, Steven D'Aprano
E.g. consider person A who writes a library containing a class
A, and person B who writes an application with a class B that subclasses A. Let's say B needs to add new instance variables, and wants to be "future-proof" against newer versions of A that might add instance variables too. Using name-mangled variables gives B a "namespace" of his own (_B__*), so he doesn't have to worry about clashes between attribute names he chooses now and attribute names that A might choose in the future. Without name-mangling, B would have to worry that A could add private variables with clashing names as well -- in fact, the presence of any private variables in A would have to be documented in order to ensure that subclasses wouldn't accidentally clash with them, defeating the whole purpose of private.
Just for completeness sake, I'll point out that there is still a possible name clash using name-mangling: if you subclass B, and inadvertently name your subclass A (or any other superclass of B), then your __names may clash with A's __names.
Of course. But that's several orders of magnitude easier to avoid, since classes are so much rarer than attributes.
I don't particularly like name-mangling, but I don't see it is a large enough problem that it needs to be removed, particularly in the absence of any viable alternative.
I usually recommend against it (in favor of a single underscore), but there are a few situations where it is really useful. -- --Guido van Rossum (home page: http://www.python.org/~guido/)