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

[Steve Holden]

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/