Why less emphasis on private data?

[Steven D'Aprano]

On Sun, 07 Jan 2007 04:09:13 -0800, Paul Rubin wrote:

> "Felipe Almeida Lessa" <felipe.lessa at gmail.com> writes:
>> What is the chance of having to inherit from two classes from
>> different modules but with exactly the same name *and* the same
>> instance variable name?
>> 
>> Of course you're being very pessimistic or extremely unlucky.
> 
> If you want to write bug-free code, pessimism is the name of the game.

I wonder whether Paul uses snow chains all year round, even in the blazing
summer? After all, "if you want to drive safely, pessimism is the name of
the game".

In the last couple of weeks comp.lang.python has had (at least) two
practical examples of the pros and cons of private attributes.

The pro: there was discussion about replacing the optparse module's
implementation with argparse, leaving the interface the same. This was
complicated by the fact that optparse exposes its internal variables,
making the job of duplicating the interface significantly harder. However
this was surely a design choice, not an accident. Having private
attributes won't save you if you choose not to make your attributes
private.

The con: there was a fellow who (for some reason) actually needed to
access a class' private attributes. To the best of my knowledge, he was
over 18 and, while new to Python, an experienced programmer, so I believe
him when he said he had eliminated all other alternatives. (And if he
were wrong, if he was incompetent -- Not My Problem. It isn't for me to
take a hammer off him so he doesn't hit his thumb with it.) In his case,
Python's name mangling of private attributes was an inconvenience, not a
help.

Compared to all the "what-ifs" and "maybes" and hypotheticals in this
thread, there were two practical cases that revolved around private
variables. In one, we see that they aren't a panacea: data hiding doesn't
help when the data isn't hidden. In the other, we see that one developer's
private attribute is just what another developer needs to solve a problem.


-- 
Steven.