Why does python not have a mechanism for data hiding?

Lie Lie.1296 at gmail.com
Tue Jun 3 06:52:15 EDT 2008


On May 24, 9:14 pm, Fuzzyman <fuzzy... at gmail.com> wrote:
> On May 24, 2:58 pm, 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?
>
> 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.
>
> You can make members truly private by proxying, but it is a bit
> ungainly.

Then don't document it, or separate internal documentation (which is
never to pass through the wall) and public documentation (which your
users use). Nobody would (apart from your dev team and anyone told by
your dev team, which means you may fire the person for "lack of
discipline") know that there is such a thing and in consequence
wouldn't use it.

Don't tell your user not to use something, just don't tell them that
it exists and they won't use it.



More information about the Python-list mailing list