Why does python not have a mechanism for data hiding?

[Lie]

On Jun 3, 5:07 pm, "BJörn Lindqvist" <bjou... at gmail.com> wrote:
> On Mon, Jun 2, 2008 at 10:50 PM, Russ P. <Russ.Paie... at gmail.com> wrote:
> > On Jun 2, 6:41 am, Carl Banks <pavlovevide... at gmail.com> wrote:
>
> >> You are not realizing that only useful(**) thing about data hiding is
> >> that some code has access to the data, other code does not.  If you
> >> "hide" data equally from everyone it's just a useless spelling change.
>
> > I think you're missing the point.
>
> > As I see it, the primary value of data hiding is that it provides
> > useful information on which data and methods are intended for the
> > client and which are intended for internal use. It's like putting a
> > front panel on a TV set with the main controls intended for the
> > viewer.
>
> Here's my two cents. First of all, a TV is a bad analogy compared to
> reusable software libraries. Really bad analogy. A TV is a horribly
> complicated device which has to be dumbed down because otherwise it
> would be to hard to use for ordinary people.

I think it's actually quite a good analogy, a class may get quite
complicated and it may do completely different things that the public
interface seems to imply. Anyway, an analogy is an analogy, don't
expect it to be exactly the same as the case itself, expect it to
illustrate the point well enough and ignore the differences not being
illustrated.

TV is a good analogy since it illustrated the point quite well, that
there are some things user may freely interact, some that users should
not mess with, and things that is strictly not for you. Nevertheless,
with the proper knowledge and proper tools, any users could open the
case and get the special screwdriver to open the TV, if all else
fails, he could always get a hammer to break the casing and gone his
way through.

Python does not enforce data-hiding because it expect people that gone
his way to ignore the warning and get the special screwdriver to be
knowledgeable enough to mess with it. C/C++ expects people to use
hammer to break through their casings, and in the end, since the
casings has already been broken, the device may never look as
beautiful as before. In python, the device may appear to look just as
beautiful.

> A software developers relation to a third party library is more
> similar to a TV repair man trying to repair a TV than to a random
> person watching TV. For a repair man, the front panel is just useless
> and in the way.

No, for a knowledgable man (a TV repairman), he'd try first to fix the
TV without opening the case (such as seeing whether the power cable is
actually plugged), and if those attempts fails (or if he already know
where the damage is from the beginning), he'd then open the screws.
The public interface isn't "useless and in the way".

> Oh, and to continue on the TV analogy, one of the reason why a TV is
> complicated is because its interface is totally different from its
> implementation. Channels are just a bad abstraction for tuning the
> receiver to different frequencies and for switching inputs. Merely
> using a TV doesn't teach you anything about how it actually works.

Why couldn't a class have interface that's completely different thing
than the implementation.

> KISS: Keep It Simple Stupid. And it is always simpler to not implement
> the gunk needed for data hiding than to do it. By keeping things
> simple you keep your code easy to implement, easy to understand and
> easy to reuse.
>
> Data hiding sacrifices implementation simplicity supposedly to make
> the interface simpler and to keep backwards compatibility. It allows
> you to change implementation details without affecting the
> interface. But do you really want to do that? Consider this silly Java
> example:
>
>     class Foo {
>         private int bar;
>         public int getBar() {
>             return bar;
>         }
>     };
>
> Then for some reason you decide that hm, "bar" is not a good attribute
> name so you change it to "babar". And you can do that without changing
> the public interface! Woho! So now you have a public getter named
> "getBar" that returns an attribute named "babar". That's in reality
> just bad and whoever is maintaining the implementation is going to be
> annoyed that the getters name doesn't match the attribute name.
>
> What would have happened without data hiding? Renaming the public
> attribute "bar" to "babar" probably cause some grief for someone
> reusing your library, but you would keep your implementation pure.
>
> What about semantic changes? Data hiding doesn't protect you against
> that, so you'll have to change your interface anyway. The interface
> for a car hasn't changed much in the last 100 years, but the
> implementation has. How easy is it to repair a car nowadays compared
> to 30 years ago?
>
> And data hiding as a documentation aid is just a sham. "These methods
> are public so you can call them, these aren't so hands off!" A reuser
> of your library *will* want to know what happens on the inside, by
> trying to make stuff impossible to reach you are just making that kind
> of information much harder to come by.

And we expect those people is ready that the car may blow off right in
their face since they have violated the lines. If they broke the lines
and still think that we're guilty for his burnt face, that's their
problem.

> The better method is to just write proper docstrings that tell the
> user what the methods do and when they can be called.
>
> Another good way to see how useless data hiding is, is to try and unit
> test a very encapsulated library. You'll see that it is almost
> impossible to write good unit tests unless you publicly export
> almost everything in the code. At which point you come to realize that
> all the data hiding was for naught.
>
> --
> mvh Björn