[Neal Norwitz] > I recently asked Guido about name mangling wrt Py3k. He definitely > wanted to keep it in. Unless he changed his mind, I doubt he would > deprecate it. His rationale was that there needs to be a way to > handle name collision with multiple inheritance.
That wasn't quite it. The original motivation was to help avoid name collisions under inheritance period, and especially when writing a base class intended for subclassing by other parties, such as most mix-in classes. For example, if your utility or mixin base class `A` has a data member named `n`, nobody deriving from `A` dare name one of their data members `n` too, and it's unreasonable to expect everyone deriving from `A` to learn and avoid all the names `A` uses internally. It's even more unreasonable for A's author to have to promise, after A's first release, never to change the name of, or introduce any new, attribute (A's author dare not, lest the new name conflict with a name someone else's subclass used). If A's author names the attribute `__n` instead, all those problems go away, provided only that some subclass doesn't also name itself `A`. That was the only point to `__` name-mangling. People who think it's trying to, e.g., emulate C++'s `private` gimmick are enjoying a semi-private fantasy ;-) It works fine for its intended use. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
