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

Tim Peters tim.peters at gmail.com
Mon Dec 12 03:18: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