Why does python not have a mechanism for data hiding?

[Russ P.]

On May 25, 2:32 pm, "Joe P. Cool" <joe.p.c... at googlemail.com> wrote:
> On 24 Mai, 15:58, Ben Finney <bignose+hates-s... at benfinney.id.au>
> wrote:
>
> > Sh4wn <luckyluk... at gmail.com> writes:
> > > first, python is one of my fav languages, and i'll definitely keep
> > > developing with it. But, there's 1 one thing what I -really- miss:
> > > data hiding. I know member vars are private when you prefix them with
> > > 2 underscores, but I hate prefixing my vars, I'd rather add a keyword
> > > before it.
>
> > From whom are you trying to hide your attributes?
>
> I saw this "don't need it" pattern in discussions about the ternary
> "if..else" expression and about "except/finally on the same block
> level".
> Now Python has both. Actually it is very useful to be able to
> distinguish
> between inside and outside. This is obvious for real world things e.g.
> your
> TV. Nobody likes to open the rear cover to switch the channel. Similar
> arguments apply to software objects. "data hiding" is a harsh name, I
> would
> call it "telling what matters". The need for this becomes
> indispensable in
> really big software packages like the Eclipse framework with approx.
> 100000
> classes. If you cannot tell the difference between inside and outside
> you
> are lost.
>
> > In Python, the philosophy "we're all consenting adults here" applies.
>
> Please don't sell a missing feature as a philosophy. Say you don't
> need/want
> it. But don't call it philosophy.
>
> > You shouldn't pretend to know, at the time you write it, all the uses
> > to which your code will be put.
>
> It's *your* *decision* which uses will be available. Your explanation
> appears
> to me as a fear to decide.
>
> > If you want the users of your code to know that an attribute should
> > not be used as a public API for the code, use the convention of naming
> > the attribute with a single leading underscore.
>
> Littering your class definition with dozens of underscores is exactly
> the
> line noise we love to criticize in Perl.
>
> > > Python advertises himself as a full OOP language, but why does it
> > > miss one of the basic principles of OOP?
>
> > Who taught you that enforced restrictions on attribute access was a
> > "basic principle" of OO?
>
> Nearly every introduction to OOP? Please don't tell me that
> encapsulation
> does not mean "enforced restriction". If the language has no syntactic
> support for encapsulation then it does not have encapsulation. Similar
> argument applies to Java where programmers sometimes claim that Java
> "has"
> properties because of setCrap/getCrap.
>
> __
> Joe


Dear Mr. Cool,

Excellent post. I agree with you entirely.

I've always considered the underscore conventions in Python an ugly
hack in an otherwise elegant language. I often avoid them even when
they technically belong just because I don't like the way they make my
code look.

Your analogy of the TV set is nice. The front control panel should be
clearely distinguished from the covered control panel and certainly
from the guts. It's more than just a matter of keeping the user from
doing something stupid -- it's a matter of design style.

I am also bothered a bit by the seeming inconsistency of the rules for
the single underscore. When used at file scope, they make the variable
or function invisible outside the module, but when used at class
scope, the "underscored" variables or functions are still fully
visible. For those who claim that the client should be left to decide
what to use, why is the client prohibited from using underscored
variables at file scope?

I may be full of beans here, but I would like to make a suggestion.
Why not add a keyword such as "private," and let it be the equivalent
of "protected" in C++? That would make member variables and functions
visible in inherited classes. The encapsulation wouldn't be as
airtight as "private" in C++, so clients could still get access if
they really need it in a pinch, but they would know they are bending
the rules slightly. I realize that single underscores do that already,
but they are just unsightly.