Why does python not have a mechanism for data hiding?

[Joe P. Cool]

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