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

Steve Holden steve at holdenweb.com
Mon Dec 12 09:36:37 CET 2005

Tim Peters wrote:

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

In that case it would seem to make even more sense, theoretically, to replace the class name in mangled names with a GUID, hence avoiding collisions in similarly-named subclasses.

Then it would work even finer (though the mangled names would be longer, and less meaningful in debugging).

mangling-things-by-typing-them-since-1967-ly y'rs - steve

Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/

More information about the Python-Dev mailing list