Why does python not have a mechanism for data hiding?

Lie Lie.1296 at gmail.com
Tue Jun 3 08:55:57 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.

The problem is you're not hard enough, you let yourself to be enslaved
by your customer.  If they have a problem because they used a private
interface, that's their problem, they have to fix it at their side or
go away and use a competing product[1]. Even if they're paying
customers they're not your master or your God, even if they're a
larger company than yours.

Python has an extremely good design because the BDFL doesn't just
listen to everyone and create a product that tries to please
everybody, no, he listens to those that have good ideas and tells the
stupid ideas to go away and he applies a subjective decision which
more often than not leads to a better python.

[1] In most cases, they would become silent at this point and fix
their code, because they know there is nothing they can do to change
your decision. It's often more expensive to move to competing products
so they'd either use old versions or fix those places where they've
used private interface, and avoid using private interface in the
future.

> You can make members truly private by proxying, but it is a bit
> ungainly.
>
> Michael Foordhttp://www.ironpythoninaction.com/
>
>
(snip)



More information about the Python-list mailing list