Why does python not have a mechanism for data hiding?

[Paul Boddie]

So much to respond to here, so let's get it over with in one post...

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

Well, there was no need to exclude try...except...finally in the first
place - Guido doubted the semantics of such a thing until he saw it in
Java, apparently. This is arguably one of the few features that has
incurred little cost with its addition, in contrast to many other
changes made to Python these days. Which brings us to the ternary
expression - something which will presumably see unprecedented usage
by those who jump on every new piece of syntax and "wear it out" in
short order.

Interestingly, Python did have an "access" keyword at some point
(before 1.4, I believe), so it isn't as if no-one had thought about
this before.

[...]

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

But is "enforced restriction" essential in OOP? Note that languages
like C++ provide such features in order to satisfy constraints which
are not directly relevant to Python.

[...]

On May 26, 6:49 am, "Russ P." <Russ.Paie... at gmail.com> wrote:
>
> 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.

To be honest, I don't really like putting double underscores before
names just to make sure that instances of subclasses won't start
trashing attributes of a class I've written. (I actually don't care
about people accessing attributes directly from outside instances
because I've seen enough "if only they hadn't made that private/
protected, I could do my work" situations in languages like Java.)
Indeed, I experienced a situation only yesterday where I found that I
had been using an instance attribute defined in a superclass (which
was arguably designed for subclassing), but was the author really
expected to prefix everything with double underscores? Of course, by
not enforcing the private nature of attributes, Python does permit
things like mix-in classes very easily, however.

If anything, Python lacks convenient facilities (besides informal
documentation) for describing the instance attributes provided by the
code of a class and of superclasses. Of course, the dynamic
possibilities in Python makes trivial implementations of such
facilities difficult, but having access to such details would make
errors like those described above less likely. I imagine that pylint
probably helps out in this regard, too.

[...]

> 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 don't remember why this is. I'll leave you to track down the
rationale for this particular behaviour. ;-)

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

If anything, I'd prefer having private attributes than some kind of
protected attributes which don't actually offer useful protection
(from accidental naming collisions).

Paul