Why does python not have a mechanism for data hiding?

[Russ P.]

On Jun 2, 10:23 pm, alex23 <wuwe... at gmail.com> wrote:
> On Jun 3, 2:11 pm, "Russ P." <Russ.Paie... at gmail.com> wrote:
>
> > Yes, that looks interesting, but I think it has a couple of drawbacks.
> > First, it requires another completely separate class for the
> > "implementation" (although perhaps that could be a nested class).
>
> That's hardly an enormous overhead, and it does clearly separate the
> interface you want your "users" to have from the implementation. Even
> better, since you seem so concerned with others meddling with your
> implementation directly, they could provide their own quite easily if
> they so choose.
>
> > Secondly, I think it essentially just adds a sort of inner namespace
> > through which the "private" data is accessed. That might be a good
> > idea, but I don't think it's quite the same as encapsulation.
>
> It's a clear separation of concerns, check. It removes the underscored
> methods you find so aesthetically offensive, check. I have absolutely
> no idea what _you_ mean by "encapsulation".
>
> Then again, I have no issue with the current convention and personally
> find the idea of adding a "private" keyword makes as much sense as
> being able to syntactically define "model", "view" and "controller"
> methods.

I'm not saying your bridge pattern is no good. It is a form of
encapsulation, I suppose, but it is cumbersome. With my suggested
"priv" keyword, you just use it once (per data member or function) and
you never need to use it again. With your approach, not only do you
need twice the number of classes, you need to use the longer names
every time you access the data.