Why less emphasis on private data?

[Steven D'Aprano]

On Sun, 07 Jan 2007 19:30:05 -0800, Paul Rubin wrote:

> Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:
>> > 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".
> 
> No.  I'm willing to accept a 10**-5 chance of hitting a freak
> snowstorm in summer, since I drive in summer at most a few hundred
> times a year, so it will take me 100's of years before I'm likely to
> encounter such a storm.  There are millions of drivers, so if they all
> take a similar chance, then a few times a year we'll see in the paper
> that someone got caught in a storm, which is ok.  Usually there's no
> real consequence beyond some inconvenience of waiting for a tow truck.
> 
> Tow truck or ambulance operators, on the other hand, should keep
> chains available all year around, since they have to service the needs
> of millions of users, have to be ready for freak summer storms.
> 
> As a software developer wanting to deploy code on a wide scale, I'm
> more like a tow truck operator than an individual car driver.
> Alternatively, as a coder I "drive" a lot more often.  If some Python
> misfeature introduces a bug with probability 10**-5 per line of code,
> then a 100 KLoc program is likely to have such a bug somewhere.  It
> doesn't take 100's of years.

That's an irrelevant argument. We're not talking about random bugs in
random places of code, we're talking about one specific type of bug which
can only occur in a handful of very restricted set of circumstances, e.g.
you have to inherit from two classes which not only have exactly the same
name but they also have the same private attribute.

Your argument is that Python's strategy for dealing with private
attributes is insufficiently pessimistic, because it doesn't deal with
those circumstances. Fine. I agree. Python isn't pessimistic. Does it need
to be? Just how often do you inherit from two identically-named classes
both of which use identically-named private attributes?

You suggested that coders (and by extension, Python) should behave with
equal pessimism whether they are subclassing two identically-named
classes or not. That's equivalent to the argument that one should use snow
chains whether it is snowing or not -- it only considers the benefit of
the extra protection, without considering the costs.

Python's private attribute handling balances convenience and protection,
giving more weight to convenience, trading off some protection. And
convenience gives increased productivity, easier debugging, few bugs
overall, and other Good Things. It would probably change the character of
Python unacceptably much to push that balance the other way.

Don't get me wrong, it is a good thing for you to alert people to the
circumstances that Python's strategy breaks down, so that they can "use
snow chains" in those circumstances. And, hey, if somebody reads this
thread and is motivated to find a better strategy that doesn't change the
nature of the language by too much, great. (This happened once before:
multiple inheritance was broken in classic classes, and new classes where
added partly to fix that.)

But chances are, the majority of Pythonistas will think that having to
use snow chains once in a very great while is an acceptable trade-off to
the smooth ride Python gives the rest of the time.


-- 
Steven D'Aprano