Why does python not have a mechanism for data hiding?

Russ P. Russ.Paielli at gmail.com
Fri Jun 6 20:48:58 CEST 2008

On Jun 6, 8:25 am, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:

> >>> I also realize, by the way, that Python allows a client of a class to
> >>> define a new class member from completely outside the class
> >>> definition. Obviously, that cannot be declared private.
> >> Why so ?
> > Why should the client of a class not be able to declare a *private*
> > member of the class? You're kidding, right?
> I'm dead serious. I often add implementation attributes to either a
> class or an instance. These *are* implementation parts, not API.

If a client accesses a data member of a class, then by definition that
member is not really private, so letting the client create a new data
member and declare it as private seems a bit silly to me. Actually,
just letting the client create the new data member, private or not,
seems like a bit of a stretch to me, but I'll leave that be.

> > For the record, I have made it abundantly clear that I don't think
> > Python should not have as rigorous an encapsulation regime as C++ or
> > Java. The worst that could happen with my proposition is that you
> > would need to use a "mangled" name to access private data or methods.
> That's already the case - when you use __name_mangling. And if there's
> no effective access restriction, then what the point of having this
> 'priv' keyword ?
> > But you will be using the name many times, you can reassign your own
> > name, of course, so the mangled name need not appear more than once
> > where it is needed.
> Once again, I just don't see the point. Either you want effective access
> restriction in Python, or you don't. And if you don't, what would this
> 'priv' keyword be useful to ?

In the end, I suppose it boils down to aesthetics and personal

The leading-underscore convention bothers me for two reasons: (1) like
the OP, I don't like the way it makes my code look, and (2) it is a
signal to a person reading the code, but it has no actual effect in
the interpreter.

I think the concept of private data and methods is important enough to
be implemented with more than just a tacky naming convention. That is
why I suggested the "priv" keyword. At the same time, I realize that
people will occasionally be frustrated if they are rigorously denied
access to all private data, which is why I suggested an "indirect"
method of access through mangled names.

You can argue that such indirect access defeats the whole idea of
private data, but at least it alerts the client to the fact that he
(or she or it) is accessing private data -- and it does so without
using Hungarian notation.

I would let the "priv" keyword also be used for data or functions at
file scope. It just seems logical to me. Again, some name mangling
convention could be concocted for those who think they really need

Actually, the whole objection to denied access baffles me a bit. Does
anyone object to not having access from outside a function to local
variables within the function? I doubt it. The other thing is that the
vast majority of Python software, I would guess, is provided with
source code. How many Python applications or libraries are provided
without source code? If you have the source code, you can obviously
just delete the "priv" keyword anywhere or everywhere it appears. And
if you have a major client who insists on access to all the internals,
just delete all occurrences of "priv" before you ship the code (or
don't use it to start with).

More information about the Python-list mailing list