Why does python not have a mechanism for data hiding?

Bruno Desthuilliers bruno.42.desthuilliers at websiteburo.invalid
Mon Jun 9 11:22:12 CEST 2008


Russ P. a écrit :
> 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,

Please stop thinking in C++. This is Python, and all you have are 
attributes. Whether they're callable of not doesn't change much here.

> then by definition that
> member is not really private,

Who cares about it being "private" ? The important point is that it's 
*implementation*, not *interface*.

> so letting the client create a new data
> member and declare it as private seems a bit silly to me. 

There are two ways to decorate a class or instance object (nb: Python's 
classes are objects too): the "static" way where you wrap the object in 
a decorator class or instance and use delegation, and the "dynamic" way 
where you just modify the original class or object at runtime. The fact 
that an attribute is added (or replaced) outside the class statement 
doesn't mean it has to be part of the interface. You sometime have 
pretty legitimate reason to modify the implementation at runtime.

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

You're way too much in the Java/C++ way of thinking.

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

Indeed. The target of the signal is definitively the person reading the 
code.

> I think the concept of private data and methods is important enough to
> be implemented with more than just a tacky naming convention.

The concept of "private" attributes is not important. What's important 
is the concept of implementation attributes.

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

We already have all this. Either you want language-enforced access 
restriction - then you might be happier with another language - or you 
just want to have a clear way to know whether an attribute is part of 
the API or not - in which case a naming convention is not only enough, 
but even better.

> 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

So does the naming convention, with much less work.

> -- and it does so without
> using Hungarian notation.

I wouldn't label this "hungarian notation" - or at least, not the way 
"hungarian notation" is now commonly understood.

> 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
> access.
> 
> Actually, the whole objection to denied access baffles me a bit.

Free your mind from the very peculiar, restricted and IMHO braindead 
conception of "OO" they taught you with Java and C++. Python is older 
than Java, it's by now a very very commonly used language on all major 
platforms, and experience prooves that you just don't need anything more 
than a simple naming convention.

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

Yes, fine. And then have to maintain a fork of the source code, and 
distribute it with the application. Honking great idea. doh :-(

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

Or don't even bother about this useless access restriction stuff. Which 
will save you quite a lot of valuable time.






More information about the Python-list mailing list