Why does python not have a mechanism for data hiding?

[Benjamin Kaplan]

On Sat, May 24, 2008 at 10:14 AM, Fuzzyman <fuzzyman at gmail.com> wrote:

> On May 24, 2:58 pm, Ben Finney <bignose+hates-s... at benfinney.id.au<bignose%2Bhates-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?
>
> Actually, 'data hiding', although vastly overused by the static crowd
> can be a reasonable thing to want.
>
> For example, at Resolver Systems we expose the spreadsheet object
> model to our users. It hasa public, documented, API - plus a host of
> undocumented internally used methods.
>
> We would really *much* rather hide these, because anything our
> customers start using (whether documented or not) we will probably
> have to continue supporting and maintaining.
>
> The 'we told you not to use that' approach, when applied to paying
> customers doesn't really work... all they see is that you broke their
> spreadsheet code by changing your API.
>

It apparently works for Sun Microsystems. They do that with a whole bunch of
packages in Java, and Java does allow data hiding.

http://java.sun.com/products/jdk/faq/faq-sun-packages.html


>
> You can make members truly private by proxying, but it is a bit
> ungainly.
>
> Michael Foord
> http://www.ironpythoninaction.com/
>
>
> >
> > In Python, the philosophy "we're all consenting adults here" applies.
> > You shouldn't pretend to know, at the time you write it, all the uses
> > to which your code will be put. Barriers such as enforced "private"
> > attributes will only cause resentment when people, despite your
> > anticipations, *need* to access them and are then forced to hack their
> > way around them.
> >
> > 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. This is a string
> > signal that the attribute is part of the implementation, not the
> > interface. The reader is then on notice that they should not rely on
> > that attribute; but they are not *prohibited* from using it if
> > necessary to their ends.
> >
> > > 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?
> >
> > Perhaps you're confusing the "encapsulation" and "abstraction"
> > principles for enforced access restrictions; they're not.
> >
> > > Will it ever be added to python?
> >
> > I hope not.
> >
> > --
> >  \            "Why was I with her? She reminds me of you. In fact, she |
> >   `\             reminds me more of you than you do!"  -- Groucho Marx |
> > _o__)                                                                  |
> > Ben Finney
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20080524/81771d51/attachment-0001.html>