[Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications) (original) (raw)

Tim Peters tim.peters at gmail.com
Mon Dec 12 03🔞04 CET 2005

[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.

More information about the Python-Dev mailing list